devkuma – Git

Git

kc@example.com (kc kim) — Sun, 13 Aug 2017 19:04:43 +0900

Git

Git Overview

kc@example.com (kc kim) — Sun, 13 Aug 2017 19:04:43 +0900

This section explains Git.

Introduction to Git

kc@example.com (kc kim) — Sun, 13 Aug 2017 19:04:43 +0900

What is Git?

Git is a file version control tool that takes a different approach from traditional version control tools.

Traditional version control tools use a centralized model. Because users do not have their own repositories, they must connect to an internal server to save or update their work. This made it difficult to assign separate versions to work done during long business trips or on a laptop.

With tools like Git, however, you can create a repository on your own hard drive and conveniently add, update, and modify your work in an internal or project-wide repository.

Useful reference sites

An Introduction to Git That Anyone Can Understand

Basic Git Commands

kc@example.com (kc kim) — Sun, 13 Aug 2017 19:04:43 +0900

git push

Applies local commits to a remote repository.

git checkout

Restores modified files in the working tree to the versions in the index.

git checkout [file]

Restores modified files in the working tree to the versions in HEAD.

git checkout HEAD (file name: optional)

Restores modified files in the working tree to the versions in FETCH_HEAD.

git checkout FETCH_HEAD (file name: optional)

git commit

Registers the changes currently in the index area into the commit area.

git commit -m "comment"

Registers all changes that have not been added to the index into the commit area as well.

git commit -a -m "comment"

Git Basics

kc@example.com (kc kim) — Sun, 13 Aug 2017 19:04:43 +0900

This Git basics tutorial briefly explains the major Git commands. The section on setting up a repository for the first time describes the commands you need when starting version control for a new project. The remaining sections introduce Git commands used in everyday work.

After completing this tutorial, you will be able to create a Git repository, safely save project snapshots, and browse project history.

Git Practice: Basics

Git Basics | git init

kc@example.com (kc kim) — Sun, 13 Aug 2017 19:04:43 +0900

The git init command

git init is the command for creating a new Git repository. Use this command to convert an existing project that is not under version control into a Git repository, or to create and initialize a new empty repository. Because almost every other Git command can only be used inside an initialized repository, this is usually the first command you run when starting a new project.

Running git init creates a .git subdirectory at the project root containing all repository-related metadata. Aside from creating this .git directory, it does not change the existing project. Unlike SVN, Git does not create a .git folder in each subdirectory.

Usage

git init

Converts the current directory into a Git repository. Running this command creates a .git folder in the current directory and lets you start version control for the project.

git init <directory>

Creates an empty Git repository in the specified directory. Running this command creates a new folder named <directory> that includes a .git subdirectory.

git init --bare <directory>

Creates and initializes a Git repository without a working directory. Shared repositories should be created with the --bare flag. See the note below. When the --bare flag is specified, .git is automatically appended to the repository directory name. For example, the bare version of a repository named my-project is stored in a folder named my-project.git.

Notes

Compared with SVN, git init provides a very simple way to create a new version-controlled project. With Git, you do not need to manually create repository folders, import files, or check out a working copy. Running git init in the project folder is enough to create a fully functional Git repository.

However, in most projects, git init is used only once when creating the central repository. Individual developers usually do not use git init when creating a local repository, which is the working copy of the central repository. Developers generally use git clone to create a copy of an existing repository on their local machine.

Bare repository

Specifying the --bare flag creates a repository without a working directory, so files cannot be edited or changes applied in that repository. If you push a branch to a non-bare repository, changes may be recorded incorrectly, so a central repository should always be created as a bare repository. You can think of --bare as a way to mark the repository as storage space rather than a development environment. In practice, central repositories are bare repositories in almost all Git workflows, while developers’ local repositories are not bare.

Git Tutorial: Bare Repositories

Example

Because git clone is more convenient for creating a working copy of a central repository, the usual use case for git init is mainly creating the first central repository:

ssh @
cd path / above / repo
git init --bare my-project.git

First, log in to the server where you want to create the central repository using SSH.
Next, move to the directory where the project will be stored.
Finally, create the central repository with the --bare flag.
Developers can then use the clone my-project.git command to create a working copy on their development machines.

Undoing Git Changes

kc@example.com (kc kim) — Sun, 13 Aug 2017 19:04:43 +0900

This tutorial covers the skills needed when working with earlier versions of a software development project. It first shows how to find commits in past history, then explains the difference between undoing commits that have been published to a public repository and undoing commits that exist only on your local machine.

Git Tutorial: Undoing Changes

Git Branches

kc@example.com (kc kim) — Sun, 13 Aug 2017 19:04:43 +0900

This tutorial provides a comprehensive introduction to Git branches. It begins with an overview of creating branches, which can be thought of as new lines of development in a project history. Next, it explains how to use the git checkout command when selecting a branch. Finally, you will learn how to use the git merge command to integrate the histories of independent branches.

As you read, you should see that Git branches are different from SVN branches. While SVN branches are often used to organize work products in large batches from time to time, Git branches are an essential part of everyday workflows.

Git Tutorial: Branching and Merging

Git Basics | git clone

kc@example.com (kc kim) — Sun, 13 Aug 2017 19:04:43 +0900

The git clone command

git clone is the command for making a copy of an existing Git repository. It is similar to svn checkout, but differs in that the working copy itself forms a complete Git repository, maintains its own change history, manages its own files, and provides an environment that is completely independent from the original repository.

For convenience, cloning automatically creates a remote connection named origin that points to the original repository. This makes it very easy to communicate with the central repository.

Usage

git clone <repo>

Clones the repository at <repo> to the local machine. The repository at <repo> may exist on the same local machine or on a remote machine accessed over HTTP or SSH.

git clone <repo> <directory>

Clones the repository at <repo> to a folder named <directory> on the local machine.

Notes

When a central repository already exists, git clone is the most common command for creating a developer’s working copy. Like git init, cloning is usually a one-time operation. After a developer creates a working copy, or local repository, all version control and collaboration happens through that local repository.

Repository-to-repository collaboration

It is important to understand that a Git “working copy” is very different from the working copy obtained by checking out code from an SVN repository. Unlike SVN, Git has no substantial difference between a working copy and a central repository. Both are complete Git repositories.

Because of this, Git collaboration and SVN collaboration are fundamentally different. In SVN, the relationship between the central repository and working copy plays an important role. In Git, the collaboration model is interaction between repositories. SVN checks a working copy into the central repository, while Git pushes or pulls commits from one repository to another.

Git Tutorial: Collaboration Between Repositories

Of course, you can assign special meaning to a Git repository you own. For example, by designating one Git repository as the “central” repository, you can follow a centralized workflow in Git as well. The important point is that this is not determined by the version control system or physical connection state; in Git, it is simply a convention.

Example

The following example shows how to create a working copy of a central repository stored on a server when the address is example.com and the SSH user name is john:

git clone ssh://john@example.com/path/to/my-project.git
cd my-project
# Start working on the project

The first line creates and initializes a new Git repository in the my-project folder on the local machine, then fetches the files from the central repository.
After this completes, move into the project directory and start editing, committing snapshots, communicating with other repositories, and so on.
Also, the cloned repository does not have the .git extension added. This means the local copy is not a bare repository.

Rewriting Git History

kc@example.com (kc kim) — Sun, 13 Aug 2017 19:04:43 +0900

Git’s main purpose is to keep a record without losing committed changes. However, Git also provides features that can reshape and improve a development workflow. These features include the ability to explicitly rewrite project history, but using them can also introduce the risk of losing commit information. Git provides history-rewriting commands together with warnings about the possibility of losing project contents.

This chapter explains common reasons why you may need to rewrite committed snapshots and shows how to avoid mistakes when doing so.

Remote Git Repositories

kc@example.com (kc kim) — Sun, 13 Aug 2017 19:04:43 +0900

In SVN, a single central repository is used as the communication hub between developers, and collaboration means transferring changes between each developer’s working copy and the central repository. Git’s collaboration model is different. Each developer has a repository copy that contains the complete local history and branch structure. Developers do not need to share individual changes one by one with other developers; in general, they share a series of work together. When changing a central repository, Git does not commit individual working-copy changes to that repository, but instead shares entire branches between repositories.

The commands shown below let you manage connections to other repositories, publish branches by pushing them to another repository, and check other developers’ progress by pulling branches into your local repository.

GitHub

kc@example.com (kc kim) — Thu, 25 Aug 2022 18:24:00 +0900

This section explains ways to use GitHub.

Using Git

kc@example.com (kc kim) — Thu, 25 Aug 2022 18:24:00 +0900

This section explains ways to use Git.

Git Troubleshooting

kc@example.com (kc kim) — Thu, 22 Dec 2022 08:15:00 +0900

devkuma – Git

Git

Git Overview

Introduction to Git

What is Git?

Git-related sites

Useful reference sites

Basic Git Commands

git push

git checkout

git commit

Git Basics

Git Basics | git init

The git init command

Usage

Notes

Bare repository

Example

Undoing Git Changes

Git Branches

Git Basics | git clone

The git clone command

Usage

Notes

Repository-to-repository collaboration

Example

Rewriting Git History

Remote Git Repositories

GitHub

Using Git

Git Troubleshooting