Git是目前最流行的版本管理系统，学会Git几乎成了开发者的必备技能。
Git有很多优势，其中之一就是远程操作非常简便。本文详细介绍5个Git命令，它们的概念和用法，理解了这些内容，你就会完全掌握Git远程操作。
git clone
git remote
git fetch
git pull
git push
本文针对初级用户，从最简单的讲起，但是需要读者对Git的基本用法有所了解。同时，本文覆盖了上面5个命令的几乎所有的常用用法，所以对于熟练用户也有参考价值。
git
一、git clone
远程操作的第一步，通常是从远程主机克隆一个版本库，这时就要用到git clone命令。
$ git clone <版本库的网址>
比如，克隆jQuery的版本库。
$ git clone https://github.com/jquery/jquery.git
该命令会在本地主机生成一个目录，与远程主机的版本库同名。如果要指定不同的目录名，可以将目录名作为git clone命令的第二个参数。
$ git clone <版本库的网址> <本地目录名>
git clone支持多种协议，除了HTTP(s)以外，还支持SSH、Git、本地文件协议等，下面是一些例子。
$ git clone http▼显示??/example.com/path/to/repo.git/
$ git clone ssh://example.com/path/to/repo.git/
$ git clone git://example.com/path/to/repo.git/
$ git clone /opt/git/project.git
$ git clone file:///opt/git/project.git
$ git clone ftp▼显示??/example.com/path/to/repo.git/
$ git clone rsync://example.com/path/to/repo.git/
SSH协议还有另一种写法。
$ git clone [user@]example.com:path/to/repo.git/
通常来说，Git协议下载速度最快，SSH协议用于需要用户认证的场合。各种协议优劣的详细讨论请参考官方文档。
二、git remote
为了便于管理，Git要求每个远程主机都必须指定一个主机名。git remote命令就用于管理主机名。
不带选项的时候，git remote命令列出所有远程主机。
$ git remote
origin
使用-v选项，可以参看远程主机的网址。
$ git remote -v
origin [email protected]:jquery/jquery.git (fetch)
origin [email protected]:jquery/jquery.git (push)
上面命令表示，当前只有一台远程主机，叫做origin，以及它的网址。
克隆版本库的时候，所使用的远程主机自动被Git命名为origin。如果想用其他的主机名，需要用git clone命令的-o选项指定。
$ git clone -o jQuery https://github.com/jquery/jquery.git
$ git remote
jQuery
上面命令表示，克隆的时候，指定远程主机叫做jQuery。
git remote show命令加上主机名，可以查看该主机的详细信息。
$ git remote show <主机名>
git remote add命令用于添加远程主机。
$ git remote add <主机名> <网址>
git remote rm命令用于删除远程主机。
$ git remote rm <主机名>
git remote rename命令用于远程主机的改名。
$ git remote rename <原主机名> <新主机名>
三、git fetch
一旦远程主机的版本库有了更新（Git术语叫做commit），需要将这些更新取回本地，这时就要用到git fetch命令。
$ git fetch <远程主机名>
上面命令将某个远程主机的更新，全部取回本地。
git fetch命令通常用来查看其他人的进程，因为它取回的代码对你本地的开发代码没有影响。
默认情况下，git fetch取回所有分支（branch）的更新。如果只想取回特定分支的更新，可以指定分支名。
$ git fetch <远程主机名> <分支名>
比如，取回origin主机的master分支。
$ git fetch origin master
所取回的更新，在本地主机上要用"远程主机名/分支名"的形式读取。比如origin主机的master，就要用origin/master读取。
git branch命令的-r选项，可以用来查看远程分支，-a选项查看所有分支。
$ git branch -r
origin/master
$ git branch -a
- master
remotes/origin/master
上面命令表示，本地主机的当前分支是master，远程分支是origin/master。
取回远程主机的更新以后，可以在它的基础上，使用git checkout命令创建一个新的分支。
$ git checkout -b newBrach origin/master
上面命令表示，在origin/master的基础上，创建一个新分支。
此外，也可以使用git merge命令或者git rebase命令，在本地分支上合并远程分支。
$ git merge origin/master
或者
$ git rebase origin/master
上面命令表示在当前分支上，合并origin/master。
四、git pull
git pull命令的作用是，取回远程主机某个分支的更新，再与本地的指定分支合并。它的完整格式稍稍有点复杂。
$ git pull <远程主机名> <远程分支名>:<本地分支名>
比如，取回origin主机的next分支，与本地的master分支合并，需要写成下面这样。
$ git pull origin next:master
如果远程分支是与当前分支合并，则冒号后面的部分可以省略。
$ git pull origin next
上面命令表示，取回origin/next分支，再与当前分支合并。实质上，这等同于先做git fetch，再做git merge。
$ git fetch origin
$ git merge origin/next
在某些场合，Git会自动在本地分支与远程分支之间，建立一种追踪关系（tracking）。比如，在git clone的时候，所有本地分支默认与远程主机的同名分支，建立追踪关系，也就是说，本地的master分支自动"追踪"origin/master分支。
Git也允许手动建立追踪关系。
git branch --set-upstream master origin/next
上面命令指定master分支追踪origin/next分支。
如果当前分支与远程分支存在追踪关系，git pull就可以省略远程分支名。
$ git pull origin
上面命令表示，本地的当前分支自动与对应的origin主机"追踪分支"（remote-tracking branch）进行合并。
如果当前分支只有一个追踪分支，连远程主机名都可以省略。
$ git pull
上面命令表示，当前分支自动与唯一一个追踪分支进行合并。
如果合并需要采用rebase模式，可以使用–rebase选项。
$ git pull --rebase <远程主机名> <远程分支名>:<本地分支名>
如果远程主机删除了某个分支，默认情况下，git pull 不会在拉取远程分支的时候，删除对应的本地分支。这是为了防止，由于其他人操作了远程主机，导致git pull不知不觉删除了本地分支。
但是，你可以改变这个行为，加上参数 -p 就会在本地删除远程已经删除的分支。
$ git pull -p
等同于下面的命令
$ git fetch --prune origin
$ git fetch -p
五、git push
git push命令用于将本地分支的更新，推送到远程主机。它的格式与git pull命令相仿。
$ git push <远程主机名> <本地分支名>:<远程分支名>
注意，分支推送顺序的写法是<来源地>:<目的地>，所以git pull是<远程分支>:<本地分支>，而git push是<本地分支>:<远程分支>。
如果省略远程分支名，则表示将本地分支推送与之存在"追踪关系"的远程分支（通常两者同名），如果该远程分支不存在，则会被新建。
$ git push origin master
上面命令表示，将本地的master分支推送到origin主机的master分支。如果后者不存在，则会被新建。
如果省略本地分支名，则表示删除指定的远程分支，因为这等同于推送一个空的本地分支到远程分支。
$ git push origin :master
等同于
$ git push origin --delete master
上面命令表示删除origin主机的master分支。
如果当前分支与远程分支之间存在追踪关系，则本地分支和远程分支都可以省略。
$ git push origin
上面命令表示，将当前分支推送到origin主机的对应分支。
如果当前分支只有一个追踪分支，那么主机名都可以省略。
$ git push
如果当前分支与多个主机存在追踪关系，则可以使用-u选项指定一个默认主机，这样后面就可以不加任何参数使用git push。
$ git push -u origin master
上面命令将本地的master分支推送到origin主机，同时指定origin为默认主机，后面就可以不加任何参数使用git push了。
不带任何参数的git push，默认只推送当前分支，这叫做simple方式。此外，还有一种matching方式，会推送所有有对应的远程分支的本地分支。Git 2.0版本之前，默认采用matching方法，现在改为默认采用simple方式。如果要修改这个设置，可以采用git config命令。
$ git config --global push.default matching
或者
$ git config --global push.default simple
还有一种情况，就是不管是否存在对应的远程分支，将本地的所有分支都推送到远程主机，这时需要使用–all选项。
$ git push --all origin
上面命令表示，将所有本地分支都推送到origin主机。
如果远程主机的版本比本地版本更新，推送时Git会报错，要求先在本地做git pull合并差异，然后再推送到远程主机。这时，如果你一定要推送，可以使用–force选项。
$ git push --force origin
上面命令使用–force选项，结果导致远程主机上更新的版本被覆盖。除非你很确定要这样做，否则应该尽量避免使用–force选项。
最后，git push不会推送标签（tag），除非使用–tags选项。
$ git push origin --tags
原文地址：http://gitref.org/remotes/
原文内容：
Git doesn’t have a central server like Subversion. All of the commands so far have been done locally, just updating a local database. To collaborate with other developers in Git, you have to put all that data on a server that the other developers have access to. The way Git does this is to synchronize your data with another repository. There is no real difference between a server and a client - a Git repository is a Git repository and you can synchronize between any two easily.
Once you have a Git repository, either one that you set up on your own server, or one hosted someplace like GitHub, you can tell Git to either push any data that you have that is not in the remote repository up, or you can ask Git to fetch differences down from the other repo.
You can do this any time you are online, it does not have to correspond with a commit or anything else. Generally you will do a number of commits locally, then fetch data from the online shared repository you cloned the project from to get up to date, merge any new work into the stuff you did, then push your changes back up.
In a nutshell you can update your project with git fetch and share your changes with git push. You can manage your remote repositories with git remote.
docs bookgit remote list, add and delete remote repository aliases
Unlike centralized version control systems that have a client that is very different from a server, Git repositories are all basically equal and you simply synchronize between them. This makes it easy to have more than one remote repository - you can have some that you have read-only access to and others that you can write to as well.
So that you don’t have to use the full URL of a remote repository every time you want to synchronize with it, Git stores an alias or nickname for each remote repository URL you are interested in. You use the git remote command to manage this list of remote repos that you care about.
git remote list your remote aliases
Without any arguments, Git will simply show you the remote repository aliases that it has stored. By default, if you cloned the project (as opposed to creating a new one locally), Git will automatically add the URL of the repository that you cloned from under the name ‘origin’. If you run the command with the -v option, you can see the actual URL for each alias.
$ git remote
origin
$ git remote -v
origin [email protected]:github/git-reference.git (fetch)
origin [email protected]:github/git-reference.git (push)
You see the URL there twice because Git allows you to have different push and fetch URLs for each remote in case you want to use different protocols for reads and writes.
git remote add add a new remote repository of your project
If you want to share a locally created repository, or you want to take contributions from someone else’s repository - if you want to interact in any way with a new repository, it’s generally easiest to add it as a remote. You do that by running git remote add [alias] [url]. That adds [url] under a local remote named [alias].
For example, if we want to share our Hello World program with the world, we can create a new repository on a server (Using GitHub as an example), which should give you a URL, in this case “[email protected]:schacon/hw.git”. To add that to our project so we can push to it and fetch updates from it we would do this:
$ git remote
$ git remote add github [email protected]:schacon/hw.git
$ git remote -v
github [email protected]:schacon/hw.git (fetch)
github [email protected]:schacon/hw.git (push)
Like the branch naming, remote alias names are arbitrary - just as ‘master’ has no special meaning but is widely used because git init sets it up by default, ‘origin’ is often used as a remote name because git clone sets it up by default as the cloned-from URL. In this case we’ll name the remote ‘github’, but you could name it just about anything.
git remote rm removing an existing remote alias
Git addeth and Git taketh away. If you need to remove a remote - you are not using it anymore, the project is gone, etc - you can remove it with git remote rm [alias].
$ git remote -v
github [email protected]:schacon/hw.git (fetch)
github [email protected]:schacon/hw.git (push)
$ git remote add origin git://github.com/pjhyett/hw.git
$ git remote -v
github [email protected]:schacon/hw.git (fetch)
github [email protected]:schacon/hw.git (push)
origin git://github.com/pjhyett/hw.git (fetch)
origin git://github.com/pjhyett/hw.git (push)
$ git remote rm origin
$ git remote -v
github [email protected]:schacon/hw.git (fetch)
github [email protected]:schacon/hw.git (push)
git remote rename [old-alias] [new-alias] rename remote aliases
If you want to rename remote aliases without having to delete them and add them again you can do that by running git remote rename [old-alias] [new-alias]. This will allow you to modify the current name of the remote.
$ git remote add github [email protected]:schacon/hw.git
$ git remote -v
github [email protected]:schacon/hw.git (fetch)
github [email protected]:schacon/hw.git (push)
$ git remote rename github origin
$ git remote -v
origin [email protected]:schacon/hw.git (fetch)
origin [email protected]:schacon/hw.git (push)
In a nutshell with git remote you can list our remote repositories and whatever URL that repository is using. You can use git remote add to add new remotes, git remote rm to delete existing ones or git remote rename [old-alias] [new-alias] to rename them.
git remote set-url update an existing remote URL
Should you ever need to update a remote’s URL, you can do so with the git remote set-url command.
$ git remote -v
github [email protected]:schacon/hw.git (fetch)
github [email protected]:schacon/hw.git (push)
origin git://github.com/pjhyett/hw.git (fetch)
origin git://github.com/pjhyett/hw.git (push)
$ git remote set-url origin git://github.com/github/git-reference.git
$ git remote -v
github [email protected]:schacon/hw.git (fetch)
github [email protected]:schacon/hw.git (push)
origin git://github.com/github/git-reference.git (fetch)
origin git://github.com/github/git-reference.git (push)
In addition to this, you can set a different push URL when you include the --push flag. This allows you to fetch from one repo while pushing to another and yet both use the same remote alias.
$ git remote -v
github [email protected]:schacon/hw.git (fetch)
github [email protected]:schacon/hw.git (push)
origin git://github.com/github/git-reference.git (fetch)
origin git://github.com/github/git-reference.git (push)
$ git remote set-url --push origin git://github.com/pjhyett/hw.git
$ git remote -v
github [email protected]:schacon/hw.git (fetch)
github [email protected]:schacon/hw.git (push)
origin git://github.com/github/git-reference.git (fetch)
origin git://github.com/pjhyett/hw.git (push)
Internally, the git remote set-url command calls git config remote, but has the added benefit of reporting back any errors. git config remote on the other hand, will silently fail if you mistype an argument or option and not actually set anything.
For example, we’ll update the github remote but instead reference it as guhflub in both invocations.
$ git remote -v
github [email protected]:schacon/hw.git (fetch)
github [email protected]:schacon/hw.git (push)
origin git://github.com/github/git-reference.git (fetch)
origin git://github.com/github/git-reference.git (push)
$ git config remote.guhflub git://github.com/mojombo/hw.git
$ git remote -v
github [email protected]:schacon/hw.git (fetch)
github [email protected]:schacon/hw.git (push)
origin git://github.com/github/git-reference.git (fetch)
origin git://github.com/github/git-reference.git (push)
$ git remote set-url guhflub git://github.com/mojombo/hw.git
fatal: No such remote ‘guhflub’
In a nutshell, you can update the locations of your remotes with git remote set-url. You can also set different push and fetch URLs under the same remote alias.
docs bookgit fetch download new branches and data from a remote repository
docs bookgit pull fetch from a remote repo and try to merge into the current branch
Git has two commands to update itself from a remote repository. git fetch will synchronize you with another repo, pulling down any data that you do not have locally and giving you bookmarks to where each branch on that remote was when you synchronized. These are called “remote branches” and are identical to local branches except that Git will not allow you to check them out - however, you can merge from them, diff them to other branches, run history logs on them, etc. You do all of that stuff locally after you synchronize.
The second command that will fetch down new data from a remote server is git pull. This command will basically run a git fetch immediately followed by a git merge of the branch on that remote that is tracked by whatever branch you are currently in. Running the fetch and merge commands separately involves less magic and less problems, but if you like the idea of pull, you can read about it in more detail in the official docs.
Assuming you have a remote all set up and you want to pull in updates, you would first run git fetch [alias] to tell Git to fetch down all the data it has that you do not, then you would run git merge [alias]/[branch] to merge into your current branch anything new you see on the server (like if someone else has pushed in the meantime). So, if you were working on a Hello World project with several other people and wanted to bring in any changes that had been pushed since we last connected, we would do something like this:
$ git fetch github
remote: Counting objects: 4006, done.
remote: Compressing objects: 100% (1322/1322), done.
remote: Total 2783 (delta 1526), reused 2587 (delta 1387)
Receiving objects: 100% (2783/2783), 1.23 MiB | 10 KiB/s, done.
Resolving deltas: 100% (1526/1526), completed with 387 local objects.
From github.com:schacon/hw
8e29b09…c7c5a10 master -> github/master
0709fdc…d4ccf73 c-langs -> github/c-langs
6684f82…ae06d2b java -> github/java
- [new branch] ada -> github/ada
- [new branch] lisp -> github/lisp
Here we can see that since we last synchronized with this remote, five branches have been added or updated. The ‘ada’ and ‘lisp’ branches are new, where the ‘master’, ‘c-langs’ and ‘java’ branches have been updated. In our example case, other developers are pushing proposed updates to remote branches for review before they’re merged into ‘master’.
You can see the mapping that Git makes. The ‘master’ branch on the remote repository becomes a branch named ‘github/master’ locally. That way you can merge the ‘master’ branch on that remote into the local ‘master’ branch by running git merge github/master. Or, you can see what new commits are on that branch by running git log github/master ^master. If your remote is named ‘origin’ it would be origin/master instead. Almost any command you would run using local branches you can use remote branches with too.
If you have more than one remote repository, you can either fetch from specific ones by running git fetch [alias] or you can tell Git to synchronize with all of your remotes by running git fetch --all.
In a nutshell you run git fetch [alias] to synchronize your repository with a remote repository, fetching all the data it has that you do not into branch references locally for merging and whatnot.
docs bookgit push push your new branches and data to a remote repository
To share the cool commits you’ve done with others, you need to push your changes to the remote repository. To do this, you run git push [alias] [branch] which will attempt to make your [branch] the new [branch] on the [alias] remote. Let’s try it by initially pushing our ‘master’ branch to the new ‘github’ remote we created earlier.
$ git push github master
Counting objects: 25, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (25/25), done.
Writing objects: 100% (25/25), 2.43 KiB, done.
Total 25 (delta 4), reused 0 (delta 0)
To [email protected]:schacon/hw.git
- [new branch] master -> master
Pretty easy. Now if someone clones that repository they will get exactly what we have committed and all of its history.
What if you have a topic branch like the ‘erlang’ branch created earlier and want to share just that? You can just push that branch instead.
$ git push github erlang
Counting objects: 7, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (6/6), 652 bytes, done.
Total 6 (delta 1), reused 0 (delta 0)
To [email protected]:schacon/hw.git
- [new branch] erlang -> erlang
Now when people clone or fetch from that repository, they’ll get an ‘erlang’ branch they can look at and merge from. You can push any branch to any remote repository that you have write access to in this way. If your branch is already on the server, it will try to update it, if it is not, Git will add it.
The last major issue you run into with pushing to remote branches is the case of someone pushing in the meantime. If you and another developer clone at the same time, you both do commits, then she pushes and then you try to push, Git will by default not allow you to overwrite her changes. Instead, it basically runs git log on the branch you’re trying to push and makes sure it can see the current tip of the server’s branch in your push’s history. If it can’t see what is on the server in your history, it concludes that you are out of date and will reject your push. You will rightly have to fetch, merge then push again - which makes sure you take her changes into account.
This is what happens when you try to push a branch to a remote branch that has been updated in the meantime:
$ git push github master
To [email protected]:schacon/hw.git
! [rejected] master -> master (non-fast-forward)
error: failed to push some refs to ‘[email protected]:schacon/hw.git’
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes before pushing again. See the ‘Note about
fast-forwards’ section of ‘git push --help’ for details.
You can fix this by running git fetch github; git merge github/master and then pushing again.
In a nutshell you run git push [alias] [branch] to update a remote repository with the changes you’ve made locally. It will take what your [branch] looks like and push it to be [branch] on the remote, if possible. If someone else has pushed since you last fetched and merged, the Git server will deny your push until you are up to date.