SVN の場合は、単一の中央リポジトリを開発者間のコミュニケーションハブとして使用し、コラボレーションとは開発者の作業コピーと中央リポジトリ間で変更を受け渡しするプロセスを意味します。Git のコラボレーションモデルはこれとは異なり、開発者各々にリポジトリのコピーがあり、ローカルの履歴やブランチ構造を完全な形で保有しています。開発者は、他の開発者と個々の変更を共有する必要はなく、通常は一連のコミットをまとめて共有します。中央リポジトリを変更する場合、Git では作業コピー内の個々の変更項目を中央リポジトリにコミットするのではなく、ブランチ全体をリポジトリ間で共有します。

The commands presented below let you manage connections with other repositories, publish local history by "pushing" branches to other repositories, and see what others have contributed by "pulling" branches into your local repository.

git remote

The git remote command lets you create, view, and delete connections to other repositories. Remote connections are more like bookmarks rather than direct links into other repositories. Instead of providing real-time access to another repository, they serve as convenient names that can be used to reference a not-so-convenient URL.

例えば、次の図はローカルリポジトリと中央リポジトリとの間およびローカルリポジトリと他の開発者のリポジトリとの間の 2 つのリモート接続を示したものです。それらをフル URL を用いて参照するのではなく、他の Git コマンドに “origin” および “john” という名称のショートカットを引き渡すことが可能になります。

Git チュートリアル: git remote

使用法

git remote

他のリポジトリへのリモート接続の一覧を表示するコマンドです。

git remote -v

上のコマンドと同様ですが、ただし各々の接続のURLが表示されます。

git remote add <name> <url>

Create a new connection to a remote repository. After adding a remote, you’ll be able to use <name> as a convenient shortcut for <url> in other Git commands.

git remote rm <name>

Remove the connection to the remote repository called <name>.

git remote rename <old-name> <new-name>

Rename a remote connection from <old-name> to <new-name>.

ディスカッション

Git is designed to give each developer an entirely isolated development environment. This means that information is not automatically passed back and forth between repositories. Instead, developers need to manually pull upstream commits into their local repository or manually push their local commits back up to the central repository. The git remote command is really just an easier way to pass URLs to these "sharing" commands.

origin リモート

When you clone a repository with git clone, it automatically creates a remote connection called origin pointing back to the cloned repository. This is useful for developers creating a local copy of a central repository, since it provides an easy way to pull upstream changes or publish local commits. This behavior is also why most Git-based projects call their central repository origin.

リポジトリ URL

Git ではリモートリポジトリを参照する多くの手段がサポートされています。即ち、リモートリポジトリにアクセスする極めて簡便な手段として、HTTP プロトコルと SSL プロトコルが用意されています。HTTP はリポジトリに対して匿名のリードオンリーアクセスを行う簡便な方法です。次はその例です:

http://host/path/to/repo.git

ただし、通常は HTTP アドレスに対してプッシュを行うことはできません (他の開発者からローカルリポジトリに対して匿名のプッシュがあったとしても常に拒否するはずです)。リードライトアクセスを行う場合は SSH を使用しなければなりません:

ssh://user@host/path/to/repo.git

この場合ホストマシーンにおいて有効な SSH アカウントが必要ですが、それを除けば Git ではデフォルトで認証を要するアクセスをサポートしています。

In addition to origin, it’s often convenient to have a connection to your teammates’ repositories. For example, if your co-worker, John, maintained a publicly accessible repository on dev.example.com/john.git, you could add a connection as follows:

git remote add john http://dev.example.com/john.git

個々の開発者のリポジトリに対してこのようなアクセスをすることにより、中央リポジトリを介さずにコラボレーションが可能になります。この機能は特に、大規模プロジェクト内で作業する小規模チームの場合に有用です。

git fetch

The git fetch command imports commits from a remote repository into your local repo. The resulting commits are stored as remote branches instead of the normal local branches that we’ve been working with. This gives you a chance to review changes before integrating them into your copy of the project.

使用法

git fetch <remote>

リポジトリからすべてのブランチをフェッチするコマンドです。このコマンドを実行すると、付随するすべてのコミットおよびファイルもそのリポジトリからダウンロードされます。

git fetch <remote> <branch>

上のコマンドと同様の機能を有するコマンドですが、ただしフェッチする対象は指定したブランチのみです。

ディスカッション

フェッチとは、他の開発者の作業内容を確認する場合に行う操作です。フェッチされたブランチはリモートブランチとして表現されるため、ローカルな開発作業には全く何の影響も与えません。フェッチしたブランチをローカルリポジトリに統合する前にその内容を確認することが可能であり、このためフェッチは安全な操作と言えます。このコマンドは、中央リポジトリの進行状況を確認できるという意味では SVN における svn update コマンドと似ていますが、しかしこのコマンドでは実際にブランチのローカルリポジトリへの統合は行いません。

リモート ブランチ

Remote branches are just like local branches, except they represent commits from somebody else’s repository. You can check out a remote branch just like a local one, but this puts you in a detached HEAD state (just like checking out an old commit). You can think of them as read-only branches. To view your remote branches, simply pass the -r flag to the git branch command. Remote branches are prefixed by the remote they belong to so that you don’t mix them up with local branches. For example, the next code snippet shows the branches you might see after fetching from the origin remote:

git branch -r
# origin/master
# origin/develop
# origin/some-feature

Again, you can inspect these branches with the usual git checkout and git log commands. If you approve the changes a remote branch contains, you can merge it into a local branch with a normal git merge. So, unlike SVN, synchronizing your local repository with a remote repository is actually a two-step process: fetch, then merge. The git pull command is a convenient shortcut for this process.

This example walks through the typical workflow for synchronizing your local repository with the central repository's master branch.

git fetch origin

このコマンドを実行すると、ダウンロードされたブランチが表示されます:

a1e8fb5..45e66a4 master -> origin/master
a1e8fb5..9e8ab1c develop -> origin/develop
* [new branch] some-feature -> origin/some-feature

The commits from these new remote branches are shown as squares instead of circles in the diagram below. As you can see, git fetch gives you access to the entire branch structure of another repository.

Git チュートリアル: git fetch

To see what commits have been added to the upstream master, you can run a git log using origin/master as a filter

git log --oneline master..origin/master

To approve the changes and merge them into your local master branch with the following commands:

git checkout master
git log origin/master

Then we can use git merge origin/master

git merge origin/master

The origin/master and master branches now point to the same commit, and you are synchronized with the upstream developments.

git pull

Merging upstream changes into your local repository is a common task in Git-based collaboration workflows. We already know how to do this with git fetch followed by git merge, but git pull rolls this into a single command.

使用法

git pull <remote>

Fetch the specified remote’s copy of the current branch and immediately merge it into the local copy. This is the same as git fetch <remote> followed by git merge origin/<current-branch>.

git pull --rebase <remote>

Same as the above command, but instead of using git merge to integrate the remote branch with the local one, use git rebase.

ディスカッション

You can think of git pull as Git's version of svn update. It’s an easy way to synchronize your local repository with upstream changes. The following diagram explains each step of the pulling process.

Git チュートリアル: git pull

You start out thinking your repository is synchronized, but then git fetch reveals that origin's version of master has progressed since you last checked it. Then git merge immediately integrates the remote master into the local one:

リベースを用いたプル

The --rebase option can be used to ensure a linear history by preventing unnecessary merge commits. Many developers prefer rebasing over merging, since it’s like saying, "I want to put my changes on top of what everybody else has done." In this sense, using git pull with the --rebase flag is even more like svn update than a plain git pull.

In fact, pulling with --rebase is such a common workflow that there is a dedicated configuration option for it:

git config --global branch.autosetuprebase always

After running that command, all git pull commands will integrate via git rebase instead of git merge.

The following example demonstrates how to synchronize with the central repository's master branch:

git checkout master
git pull --rebase origin

このコマンドを実行すると、他の開発者の作業成果がすべて反映されたものの上にローカルの変更が加えられるようになります。

Git のプッシュ

Pushing is how you transfer commits from your local repository to a remote repo. It's the counterpart to git fetch, but whereas fetching imports commits to local branches, pushing exports commits to remote branches. This has the potential to overwrite changes, so you need to be careful how you use it. These issues are discussed below.

使用法

git push <remote> <branch>

Push the specified branch to <remote>, along with all of the necessary commits and internal objects. This creates a local branch in the destination repository. To prevent you from overwriting commits, Git won’t let you push when it results in a non-fast-forward merge in the destination repository.

git push <remote> --force

Same as the above command, but force the push even if it results in a non-fast-forward merge. Do not use the --force flag unless you’re absolutely sure you know what you’re doing.

git push <remote> --all

すべてのローカルブランチを指定したリモートリポジトリにプッシュするコマンドです。

git push <remote> --tags

Tags are not automatically pushed when you push a branch or use the --all option. The --tags flag sends all of your local tags to the remote repository.

ディスカッション

The most common use case for git push is to publish your local changes to a central repository. After you’ve accumulated several local commits and are ready to share them with the rest of the team, you (optionally) clean them up with an interactive rebase, then push them to the central repository.

Git チュートリアル: git push

The above diagram shows what happens when your local master has progressed past the central repository’s master and you publish changes by running git push origin master. Notice how git push is essentially the same as running git merge master from inside the remote repository.

強制プッシュ

Git prevents you from overwriting the central repository’s history by refusing push requests when they result in a non-fast-forward merge. So, if the remote history has diverged from your history, you need to pull the remote branch and merge it into your local one, then try pushing again. This is similar to how SVN makes you synchronize with the central repository via svn update before committing a changeset.

The --force flag overrides this behavior and makes the remote repository’s branch match your local one, deleting any upstream changes that may have occurred since you last pulled. The only time you should ever need to force push is when you realize that the commits you just shared were not quite right and you fixed them with a git commit --amend or an interactive rebase. However, you must be absolutely certain that none of your teammates have pulled those commits before using the --force option.

プッシュ先はベアリポジトリに限定

In addition, you should only push to repositories that have been created with the --bare flag. Since pushing messes with the remote branch structure, it’s important to never push to another developer’s repository. But because bare repos don’t have a working directory, it’s impossible to interrupt anybody’s developments.

The following example describes one of the standard methods for publishing local contributions to the central repository. First, it makes sure your local master is up-to-date by fetching the central repository’s copy and rebasing your changes on top of them. The interactive rebase is also a good opportunity to clean up your commits before sharing them. Then, the git push command sends all of the commits on your local master to the central repository.

git checkout master
git fetch origin master
git rebase -i origin/master
# Squash commits, fix up commit messages etc.
git push origin master

Since we already made sure the local master was up-to-date, this should result in a fast-forward merge, and git push should not complain about any of the non-fast-forward issues discussed above.