廖雪峰Git教程2

转自：https://www.liaoxuefeng.com/wiki/896043488029600

 【远程仓库】

到目前为止，咱们已经掌握了如何在Git仓库里对一个文件进行时光穿梭，你不再用担忧文件备份或者丢失的问题了。

但是有用过集中式版本控制系统SVN的童鞋会站出来讲，这些功能在SVN里早就有了，没看出Git有什么特别的地方。

没错，若是只是在一个仓库里管理文件历史，Git和SVN真没啥区别。为了保证你如今所学的Git物超所值，未来绝对不会后悔，同时为了打击已经不幸学了SVN的童鞋，本章开始介绍Git的杀手级功能之一（注意是之一，也就是后面还有之二，之三……）：远程仓库。

Git是分布式版本控制系统，同一个Git仓库，能够分布到不一样的机器上。怎么分布呢？最先，确定只有一台机器有一个原始版本库，此后，别的机器能够“克隆”这个原始版本库，并且每台机器的版本库其实都是同样的，并无主次之分。

你确定会想，至少须要两台机器才能玩远程库不是？可是我只有一台电脑，怎么玩？

其实一台电脑上也是能够克隆多个版本库的，只要不在同一个目录下。不过，现实生活中是不会有人这么傻的在一台电脑上搞几个远程库玩，由于一台电脑上搞几个远程库彻底没有意义，并且硬盘挂了会致使全部库都挂掉，因此我也不告诉你在一台电脑上怎么克隆多个仓库。

实际状况每每是这样，找一台电脑充当服务器的角色，天天24小时开机，其余每一个人都从这个“服务器”仓库克隆一份到本身的电脑上，而且各自把各自的提交推送到服务器仓库里，也从服务器仓库中拉取别人的提交。

彻底能够本身搭建一台运行Git的服务器，不过现阶段，为了学Git先搭个服务器绝对是小题大做。好在这个世界上有个叫GitHub的神奇的网站，从名字就能够看出，这个网站就是提供Git仓库托管服务的，因此，只要注册一个GitHub帐号，就能够免费得到Git远程仓库。

在继续阅读后续内容前，请自行注册GitHub帐号。因为你的本地Git仓库和GitHub仓库之间的传输是经过SSH加密的，因此，须要一点设置：

第1步：建立SSH Key。在用户主目录下，看看有没有.ssh目录，若是有，再看看这个目录下有没有id_rsa和id_rsa.pub这两个文件，若是已经有了，可直接跳到下一步。若是没有，打开Shell（Windows下打开Git Bash），建立SSH Key：

$ ssh-keygen -t rsa -C "youremail@example.com"

你须要把邮件地址换成你本身的邮件地址，而后一路回车，使用默认值便可，因为这个Key也不是用于军事目的，因此也无需设置密码。

若是一切顺利的话，能够在用户主目录里找到.ssh目录，里面有id_rsa和id_rsa.pub两个文件，这两个就是SSH Key的秘钥对，id_rsa是私钥，不能泄露出去，id_rsa.pub是公钥，能够放心地告诉任何人。

第2步：登录GitHub，打开“Account settings”，“SSH Keys”页面：

而后，点“Add SSH Key”，填上任意Title，在Key文本框里粘贴id_rsa.pub文件的内容：

点“Add Key”，你就应该看到已经添加的Key：

为何GitHub须要SSH Key呢？由于GitHub须要识别出你推送的提交确实是你推送的，而不是别人冒充的，而Git支持SSH协议，因此，GitHub只要知道了你的公钥，就能够确认只有你本身才能推送。

固然，GitHub容许你添加多个Key。假定你有若干电脑，你一下子在公司提交，一下子在家里提交，只要把每台电脑的Key都添加到GitHub，就能够在每台电脑上往GitHub推送了。

最后友情提示，在GitHub上免费托管的Git仓库，任何人均可以看到喔（但只有你本身才能改）。因此，不要把敏感信息放进去。

若是你不想让别人看到Git库，有两个办法，一个是交点保护费，让GitHub把公开的仓库变成私有的，这样别人就看不见了（不可读更不可写）。另外一个办法是本身动手，搭一个Git服务器，由于是你本身的Git服务器，因此别人也是看不见的。这个方法咱们后面会讲到的，至关简单，公司内部开发必备。

确保你拥有一个GitHub帐号后，咱们就即将开始远程仓库的学习。

 

【添加远程库】

如今的情景是，你已经在本地建立了一个Git仓库后，又想在GitHub建立一个Git仓库，而且让这两个仓库进行远程同步，这样，GitHub上的仓库既能够做为备份，又可让其余人经过该仓库来协做，真是一举多得。

首先，登录GitHub，而后，在右上角找到“Create a new repo”按钮，建立一个新的仓库：

在Repository name填入learngit，其余保持默认设置，点击“Create repository”按钮，就成功地建立了一个新的Git仓库：

目前，在GitHub上的这个learngit仓库仍是空的，GitHub告诉咱们，能够从这个仓库克隆出新的仓库，也能够把一个已有的本地仓库与之关联，而后，把本地仓库的内容推送到GitHub仓库。

如今，咱们根据GitHub的提示，在本地的learngit仓库下运行命令：

$ git remote add origin git@github.com:michaelliao/learngit.git 

请千万注意，把上面的michaelliao替换成你本身的GitHub帐户名，不然，你在本地关联的就是个人远程库，关联没有问题，可是你之后推送是推不上去的，由于你的SSH Key公钥不在个人帐户列表中。

添加后，远程库的名字就是origin，这是Git默认的叫法，也能够改为别的，可是origin这个名字一看就知道是远程库。

下一步，就能够把本地库的全部内容推送到远程库上：

$ git push -u origin master
Counting objects: 20, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (15/15), done.
Writing objects: 100% (20/20), 1.64 KiB | 560.00 KiB/s, done.
Total 20 (delta 5), reused 0 (delta 0)
remote: Resolving deltas: 100% (5/5), done.
To github.com:michaelliao/learngit.git
 * [new branch]      master -> master
Branch 'master' set up to track remote branch 'master' from 'origin'. 

把本地库的内容推送到远程，用git push命令，其实是把当前分支master推送到远程。

因为远程库是空的，咱们第一次推送master分支时，加上了-u参数，Git不但会把本地的master分支内容推送的远程新的master分支，还会把本地的master分支和远程的master分支关联起来，在之后的推送或者拉取时就能够简化命令。

推送成功后，能够马上在GitHub页面中看到远程库的内容已经和本地如出一辙：

从如今起，只要本地做了提交，就能够经过命令：

$ git push origin master 

把本地master分支的最新修改推送至GitHub，如今，你就拥有了真正的分布式版本库！

SSH警告

当你第一次使用Git的clone或者push命令链接GitHub时，会获得一个警告：

The authenticity of host 'github.com (xx.xx.xx.xx)' can't be established.
RSA key fingerprint is xx.xx.xx.xx.xx.
Are you sure you want to continue connecting (yes/no)?

这是由于Git使用SSH链接，而SSH链接在第一次验证GitHub服务器的Key时，须要你确认GitHub的Key的指纹信息是否真的来自GitHub的服务器，输入yes回车便可。

Git会输出一个警告，告诉你已经把GitHub的Key添加到本机的一个信任列表里了：

Warning: Permanently added 'github.com' (RSA) to the list of known hosts. 

这个警告只会出现一次，后面的操做就不会有任何警告了。

若是你实在担忧有人冒充GitHub服务器，输入yes前能够对照GitHub的RSA Key的指纹信息是否与SSH链接给出的一致。

小结

要关联一个远程库，使用命令git remote add origin git@server-name:path/repo-name.git；

关联后，使用命令git push -u origin master第一次推送master分支的全部内容；

此后，每次本地提交后，只要有必要，就可使用命令git push origin master推送最新修改；

分布式版本系统的最大好处之一是在本地工做彻底不须要考虑远程库的存在，也就是有没有联网均可以正常工做，而SVN在没有联网的时候是拒绝干活的！当有网络的时候，再把本地提交推送一下就完成了同步，真是太方便了！

 

【从远程库克隆】

上次咱们讲了先有本地库，后有远程库的时候，如何关联远程库。

如今，假设咱们从零开发，那么最好的方式是先建立远程库，而后，从远程库克隆。

首先，登录GitHub，建立一个新的仓库，名字叫gitskills：

咱们勾选Initialize this repository with a README，这样GitHub会自动为咱们建立一个README.md文件。建立完毕后，能够看到README.md文件：

如今，远程库已经准备好了，下一步是用命令git clone克隆一个本地库：

$ git clone git@github.com:michaelliao/gitskills.git Cloning into 'gitskills'... remote: Counting objects: 3, done. remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 3 Receiving objects: 100% (3/3), done. 

注意把Git库的地址换成你本身的，而后进入gitskills目录看看，已经有README.md文件了：

$ cd gitskills $ ls README.md

若是有多我的协做开发，那么每一个人各自从远程克隆一份就能够了。

你也许还注意到，GitHub给出的地址不止一个，还能够用https://github.com/michaelliao/gitskills.git这样的地址。实际上，Git支持多种协议，默认的git://使用ssh，但也可使用https等其余协议。

使用https除了速度慢之外，还有个最大的麻烦是每次推送都必须输入口令，可是在某些只开放http端口的公司内部就没法使用ssh协议而只能用https。

小结

要克隆一个仓库，首先必须知道仓库的地址，而后使用git clone命令克隆。

Git支持多种协议，包括https，但经过ssh支持的原生git协议速度最快。

 

【分支管理】

分支就是科幻电影里面的平行宇宙，当你正在电脑前努力学习Git的时候，另外一个你正在另外一个平行宇宙里努力学习SVN。

若是两个平行宇宙互不干扰，那对如今的你也没啥影响。不过，在某个时间点，两个平行宇宙合并了，结果，你既学会了Git又学会了SVN！

分支在实际中有什么用呢？假设你准备开发一个新功能，可是须要两周才能完成，第一周你写了50%的代码，若是马上提交，因为代码还没写完，不完整的代码库会致使别人不能干活了。若是等代码所有写完再一次提交，又存在丢失天天进度的巨大风险。

如今有了分支，就不用怕了。你建立了一个属于你本身的分支，别人看不到，还继续在原来的分支上正常工做，而你在本身的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工做。

其余版本控制系统如SVN等都有分支管理，可是用过以后你会发现，这些版本控制系统建立和切换分支比蜗牛还慢，简直让人没法忍受，结果分支功能成了摆设，你们都不去用。

但Git的分支是不同凡响的，不管建立、切换和删除分支，Git在1秒钟以内就能完成！不管你的版本库是1个文件仍是1万个文件。

 

【建立与合并分支】

在版本回退里，你已经知道，每次提交，Git都把它们串成一条时间线，这条时间线就是一个分支。截止到目前，只有一条时间线，在Git里，这个分支叫主分支，即master分支。HEAD严格来讲不是指向提交，而是指向master，master才是指向提交的，因此，HEAD指向的就是当前分支。

一开始的时候，master分支是一条线，Git用master指向最新的提交，再用HEAD指向master，就能肯定当前分支，以及当前分支的提交点：

每次提交，master分支都会向前移动一步，这样，随着你不断提交，master分支的线也愈来愈长。

当咱们建立新的分支，例如dev时，Git新建了一个指针叫dev，指向master相同的提交，再把HEAD指向dev，就表示当前分支在dev上：

你看，Git建立一个分支很快，由于除了增长一个dev指针，改改HEAD的指向，工做区的文件都没有任何变化！

不过，从如今开始，对工做区的修改和提交就是针对dev分支了，好比新提交一次后，dev指针往前移动一步，而master指针不变：

假如咱们在dev上的工做完成了，就能够把dev合并到master上。Git怎么合并呢？最简单的方法，就是直接把master指向dev的当前提交，就完成了合并：

因此Git合并分支也很快！就改改指针，工做区内容也不变！

合并完分支后，甚至能够删除dev分支。删除dev分支就是把dev指针给删掉，删掉后，咱们就剩下了一条master分支：

真是太神奇了，你看得出来有些提交是经过分支完成的吗？

下面开始实战。

首先，咱们建立dev分支，而后切换到dev分支：

$ git checkout -b dev Switched to a new branch 'dev' 

git checkout命令加上-b参数表示建立并切换，至关于如下两条命令：

$ git branch dev $ git checkout dev Switched to branch 'dev' 

而后，用git branch命令查看当前分支：

$ git branch * dev master 

git branch命令会列出全部分支，当前分支前面会标一个*号。

而后，咱们就能够在dev分支上正常提交，好比对readme.txt作个修改，加上一行：

Creating a new branch is quick. 

而后提交：

$ git add readme.txt $ git commit -m "branch test" [dev b17d20e] branch test 1 file changed, 1 insertion(+) 

如今，dev分支的工做完成，咱们就能够切换回master分支：

$ git checkout master Switched to branch 'master' 

切换回master分支后，再查看一个readme.txt文件，刚才添加的内容不见了！由于那个提交是在dev分支上，而master分支此刻的提交点并无变：

如今，咱们把dev分支的工做成果合并到master分支上：

$ git merge dev Updating d46f35e..b17d20e Fast-forward readme.txt | 1 + 1 file changed, 1 insertion(+) 

git merge命令用于合并指定分支到当前分支。合并后，再查看readme.txt的内容，就能够看到，和dev分支的最新提交是彻底同样的。

注意到上面的Fast-forward信息，Git告诉咱们，此次合并是“快进模式”，也就是直接把master指向dev的当前提交，因此合并速度很是快。

固然，也不是每次合并都能Fast-forward，咱们后面会讲其余方式的合并。

合并完成后，就能够放心地删除dev分支了：

$ git branch -d dev Deleted branch dev (was b17d20e). 

删除后，查看branch，就只剩下master分支了：

$ git branch * master 

由于建立、合并和删除分支很是快，因此Git鼓励你使用分支完成某个任务，合并后再删掉分支，这和直接在master分支上工做效果是同样的，但过程更安全。

switch

咱们注意到切换分支使用git checkout <branch>，而前面讲过的撤销修改则是git checkout -- <file>，同一个命令，有两种做用，确实有点使人迷惑。

实际上，切换分支这个动做，用switch更科学。所以，最新版本的Git提供了新的git switch命令来切换分支：

建立并切换到新的dev分支，可使用：

$ git switch -c dev 

直接切换到已有的master分支，可使用：

$ git switch master 

使用新的git switch命令，比git checkout要更容易理解。

小结

Git鼓励大量使用分支：

查看分支：git branch

建立分支：git branch <name>

切换分支：git checkout <name>或者git switch <name>

建立+切换分支：git checkout -b <name>或者git switch -c <name>

合并某分支到当前分支：git merge <name>

删除分支：git branch -d <name>

 

【解决冲突】

人生不如意之事十之八九，合并分支每每也不是一路顺风的。

准备新的feature1分支，继续咱们的新分支开发：

$ git checkout -b feature1 Switched to a new branch 'feature1' 

修改readme.txt最后一行，改成：

Creating a new branch is quick AND simple. 

在feature1分支上提交：

$ git add readme.txt

$ git commit -m "AND simple" [feature1 14096d0] AND simple 1 file changed, 1 insertion(+), 1 deletion(-) 

切换到master分支：

$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 1 commit. (use "git push" to publish your local commits) 

Git还会自动提示咱们当前master分支比远程的master分支要超前1个提交。

在master分支上把readme.txt文件的最后一行改成：

Creating a new branch is quick & simple. 

提交：

$ git add readme.txt $ git commit -m "& simple" [master 5dc6824] & simple 1 file changed, 1 insertion(+), 1 deletion(-) 

如今，master分支和feature1分支各自都分别有新的提交，变成了这样：

这种状况下，Git没法执行“快速合并”，只能试图把各自的修改合并起来，但这种合并就可能会有冲突，咱们试试看：

$ git merge feature1 Auto-merging readme.txt CONFLICT (content): Merge conflict in readme.txt Automatic merge failed; fix conflicts and then commit the result. 

果真冲突了！Git告诉咱们，readme.txt文件存在冲突，必须手动解决冲突后再提交。git status也能够告诉咱们冲突的文件：

$ git status
On branch master
Your branch is ahead of 'origin/master' by 2 commits. (use "git push" to publish your local commits) You have unmerged paths. (fix conflicts and run "git commit") (use "git merge --abort" to abort the merge) Unmerged paths: (use "git add <file>..." to mark resolution) both modified: readme.txt no changes added to commit (use "git add" and/or "git commit -a") 

咱们能够直接查看readme.txt的内容：

Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
Git tracks changes of files.
<<<<<<< HEAD Creating a new branch is quick & simple. ======= Creating a new branch is quick AND simple. >>>>>>> feature1 

Git用<<<<<<<，=======，>>>>>>>标记出不一样分支的内容，咱们修改以下后保存：

Creating a new branch is quick and simple. 

再提交：

$ git add readme.txt $ git commit -m "conflict fixed" [master cf810e4] conflict fixed 

如今，master分支和feature1分支变成了下图所示：

用带参数的git log也能够看到分支的合并状况：

$ git log --graph --pretty=oneline --abbrev-commit
*   cf810e4 (HEAD -> master) conflict fixed
|\  
| * 14096d0 (feature1) AND simple * | 5dc6824 & simple |/ * b17d20e branch test * d46f35e (origin/master) remove test.txt * b84166e add test.txt * 519219b git tracks changes * e43a48b understand how stage works * 1094adb append GPL * e475afc add distributed * eaadf4e wrote a readme file 

最后，删除feature1分支：

$ git branch -d feature1 Deleted branch feature1 (was 14096d0). 

工做完成。

 

小结

当Git没法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交，合并完成。

解决冲突就是把Git合并失败的文件手动编辑为咱们但愿的内容，再提交。

用git log --graph命令能够看到分支合并图。

 

【分支管理策略】

一般，合并分支时，若是可能，Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。

若是要强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就能够看出分支信息。

下面咱们实战一下--no-ff方式的git merge：

首先，仍然建立并切换dev分支：

$ git checkout -b dev Switched to a new branch 'dev' 

修改readme.txt文件，并提交一个新的commit：

$ git add readme.txt 
$ git commit -m "add merge" [dev f52c633] add merge 1 file changed, 1 insertion(+) 

如今，咱们切换回master：

$ git checkout master Switched to branch 'master' 

准备合并dev分支，请注意--no-ff参数，表示禁用Fast forward：

$ git merge --no-ff -m "merge with no-ff" dev Merge made by the 'recursive' strategy. readme.txt | 1 + 1 file changed, 1 insertion(+) 

由于本次合并要建立一个新的commit，因此加上-m参数，把commit描述写进去。

合并后，咱们用git log看看分支历史：

$ git log --graph --pretty=oneline --abbrev-commit * e1e9c68 (HEAD -> master) merge with no-ff |\ | * f52c633 (dev) add merge |/ * cf810e4 conflict fixed ... 

能够看到，不使用Fast forward模式，merge后就像这样：

 

分支策略

在实际开发中，咱们应该按照几个基本原则进行分支管理：

首先，master分支应该是很是稳定的，也就是仅用来发布新版本，平时不能在上面干活；

那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，好比1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；

你和你的小伙伴们每一个人都在dev分支上干活，每一个人都有本身的分支，时不时地往dev分支上合并就能够了。

因此，团队合做的分支看起来就像这样：

小结

Git分支十分强大，在团队开发中应该充分应用。

合并分支时，加上--no-ff参数就能够用普通模式合并，合并后的历史有分支，能看出来曾经作过合并，而fast forward合并就看不出来曾经作过合并。

 

【Bug分支】

软件开发中，bug就像屡见不鲜同样。有了bug就须要修复，在Git中，因为分支是如此的强大，因此，每一个bug均可以经过一个新的临时分支来修复，修复后，合并分支，而后将临时分支删除。

当你接到一个修复一个代号101的bug的任务时，很天然地，你想建立一个分支issue-101来修复它，可是，等等，当前正在dev上进行的工做尚未提交：

$ git status
On branch dev
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage) new file: hello.py Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: readme.txt 

并非你不想提交，而是工做只进行到一半，还无法提交，预计完成还需1天时间。可是，必须在两个小时内修复该bug，怎么办？

幸亏，Git还提供了一个stash功能，能够把当前工做现场“储藏”起来，等之后恢复现场后继续工做：

$ git stash Saved working directory and index state WIP on dev: f52c633 add merge 

如今，用git status查看工做区，就是干净的（除非有没有被Git管理的文件），所以能够放心地建立分支来修复bug。

首先肯定要在哪一个分支上修复bug，假定须要在master分支上修复，就从master建立临时分支：

$ git checkout master Switched to branch 'master' Your branch is ahead of 'origin/master' by 6 commits. (use "git push" to publish your local commits) $ git checkout -b issue-101 Switched to a new branch 'issue-101' 

如今修复bug，须要把“Git is free software ...”改成“Git is a free software ...”，而后提交：

$ git add readme.txt $ git commit -m "fix bug 101" [issue-101 4c805e2] fix bug 101 1 file changed, 1 insertion(+), 1 deletion(-) 

修复完成后，切换到master分支，并完成合并，最后删除issue-101分支：

$ git checkout master Switched to branch 'master' Your branch is ahead of 'origin/master' by 6 commits. (use "git push" to publish your local commits) $ git merge --no-ff -m "merged bug fix 101" issue-101 Merge made by the 'recursive' strategy. readme.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 

太棒了，原计划两个小时的bug修复只花了5分钟！如今，是时候接着回到dev分支干活了！

$ git checkout dev Switched to branch 'dev' $ git status On branch dev nothing to commit, working tree clean 

工做区是干净的，刚才的工做现场存到哪去了？用git stash list命令看看：

$ git stash list stash@{0}: WIP on dev: f52c633 add merge 

工做现场还在，Git把stash内容存在某个地方了，可是须要恢复一下，有两个办法：

一是用git stash apply恢复，可是恢复后，stash内容并不删除，你须要用git stash drop来删除；

另外一种方式是用git stash pop，恢复的同时把stash内容也删了：

$ git stash pop
On branch dev
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage) new file: hello.py Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: readme.txt Dropped refs/stash@{0} (5d677e2ee266f39ea296182fb2354265b91b3b2a) 

再用git stash list查看，就看不到任何stash内容了：

$ git stash list 

你能够屡次stash，恢复的时候，先用git stash list查看，而后恢复指定的stash，用命令：

$ git stash apply stash@{0}

在master分支上修复了bug后，咱们要想想，dev分支是早期从master分支分出来的，因此，这个bug其实在当前dev分支上也存在。

那怎么在dev分支上修复一样的bug？重复操做一次，提交不就好了？

有木有更简单的方法？

有！

一样的bug，要在dev上修复，咱们只须要把4c805e2 fix bug 101这个提交所作的修改“复制”到dev分支。注意：咱们只想复制4c805e2 fix bug 101这个提交所作的修改，并非把整个master分支merge过来。

为了方便操做，Git专门提供了一个cherry-pick命令，让咱们能复制一个特定的提交到当前分支：

$ git branch * dev master $ git cherry-pick 4c805e2 [master 1d4b803] fix bug 101 1 file changed, 1 insertion(+), 1 deletion(-) 

Git自动给dev分支作了一次提交，注意此次提交的commit是1d4b803，它并不一样于master的4c805e2，由于这两个commit只是改动相同，但确实是两个不一样的commit。用git cherry-pick，咱们就不须要在dev分支上手动再把修bug的过程重复一遍。

有些聪明的童鞋会想了，既然能够在master分支上修复bug后，在dev分支上能够“重放”这个修复过程，那么直接在dev分支上修复bug，而后在master分支上“重放”行不行？固然能够，不过你仍然须要git stash命令保存现场，才能从dev分支切换到master分支。

小结

修复bug时，咱们会经过建立新的bug分支进行修复，而后合并，最后删除；

当手头工做没有完成时，先把工做现场git stash一下，而后去修复bug，修复后，再git stash pop，回到工做现场；

在master分支上修复的bug，想要合并到当前dev分支，能够用git cherry-pick <commit>命令，把bug提交的修改“复制”到当前分支，避免重复劳动。

 

【Feature分支】

软件开发中，总有无穷无尽的新的功能要不断添加进来。

添加一个新功能时，你确定不但愿由于一些实验性质的代码，把主分支搞乱了，因此，每添加一个新功能，最好新建一个feature分支，在上面开发，完成后，合并，最后，删除该feature分支。

如今，你终于接到了一个新任务：开发代号为Vulcan的新功能，该功能计划用于下一代星际飞船。

因而准备开发：

$ git checkout -b feature-vulcan Switched to a new branch 'feature-vulcan' 

5分钟后，开发完毕：

$ git add vulcan.py $ git status On branch feature-vulcan Changes to be committed: (use "git reset HEAD <file>..." to unstage) new file: vulcan.py $ git commit -m "add feature vulcan" [feature-vulcan 287773e] add feature vulcan 1 file changed, 2 insertions(+) create mode 100644 vulcan.py 

切回dev，准备合并：

$ git checkout dev 

一切顺利的话，feature分支和bug分支是相似的，合并，而后删除。

可是！

就在此时，接到上级命令，因经费不足，新功能必须取消！

虽然白干了，可是这个包含机密资料的分支仍是必须就地销毁：

$ git branch -d feature-vulcan error: The branch 'feature-vulcan' is not fully merged. If you are sure you want to delete it, run 'git branch -D feature-vulcan'. 

销毁失败。Git友情提醒，feature-vulcan分支尚未被合并，若是删除，将丢失掉修改，若是要强行删除，须要使用大写的-D参数。。

如今咱们强行删除：

$ git branch -D feature-vulcan Deleted branch feature-vulcan (was 287773e). 

终于删除成功！

 

小结

开发一个新feature，最好新建一个分支；

若是要丢弃一个没有被合并过的分支，能够经过git branch -D <name>强行删除。

 

【多人协做】

当你从远程仓库克隆时，实际上Git自动把本地的master分支和远程的master分支对应起来了，而且，远程仓库的默认名称是origin。

要查看远程库的信息，用git remote：

$ git remote origin 

或者，用git remote -v显示更详细的信息：

$ git remote -v origin git@github.com:michaelliao/learngit.git (fetch) origin git@github.com:michaelliao/learngit.git (push) 

上面显示了能够抓取和推送的origin的地址。若是没有推送权限，就看不到push的地址。

推送分支

推送分支，就是把该分支上的全部本地提交推送到远程库。推送时，要指定本地分支，这样，Git就会把该分支推送到远程库对应的远程分支上：

$ git push origin master 

若是要推送其余分支，好比dev，就改为：

$ git push origin dev 

可是，并非必定要把本地分支往远程推送，那么，哪些分支须要推送，哪些不须要呢？

• master分支是主分支，所以要时刻与远程同步；

• dev分支是开发分支，团队全部成员都须要在上面工做，因此也须要与远程同步；

• bug分支只用于在本地修复bug，就不必推到远程了，除非老板要看看你每周到底修复了几个bug；

• feature分支是否推到远程，取决于你是否和你的小伙伴合做在上面开发。

总之，就是在Git中，分支彻底能够在本地本身藏着玩，是否推送，视你的心情而定！

 

抓取分支

多人协做时，你们都会往master和dev分支上推送各自的修改。

如今，模拟一个你的小伙伴，能够在另外一台电脑（注意要把SSH Key添加到GitHub）或者同一台电脑的另外一个目录下克隆：

$ git clone git@github.com:michaelliao/learngit.git Cloning into 'learngit'... remote: Counting objects: 40, done. remote: Compressing objects: 100% (21/21), done. remote: Total 40 (delta 14), reused 40 (delta 14), pack-reused 0 Receiving objects: 100% (40/40), done. Resolving deltas: 100% (14/14), done. 

当你的小伙伴从远程库clone时，默认状况下，你的小伙伴只能看到本地的master分支。不信能够用git branch命令看看：

$ git branch * master 

如今，你的小伙伴要在dev分支上开发，就必须建立远程origin的dev分支到本地，因而他用这个命令建立本地dev分支：

$ git checkout -b dev origin/dev 

如今，他就能够在dev上继续修改，而后，时不时地把dev分支push到远程：

$ git add env.txt

$ git commit -m "add env" [dev 7a5e5dd] add env 1 file changed, 1 insertion(+) create mode 100644 env.txt $ git push origin dev Counting objects: 3, done. Delta compression using up to 4 threads. Compressing objects: 100% (2/2), done. Writing objects: 100% (3/3), 308 bytes | 308.00 KiB/s, done. Total 3 (delta 0), reused 0 (delta 0) To github.com:michaelliao/learngit.git f52c633..7a5e5dd dev -> dev 

 

你的小伙伴已经向origin/dev分支推送了他的提交，而碰巧你也对一样的文件做了修改，并试图推送：

$ cat env.txt
env

$ git add env.txt

$ git commit -m "add new env" [dev 7bd91f1] add new env 1 file changed, 1 insertion(+) create mode 100644 env.txt $ git push origin dev To github.com:michaelliao/learngit.git ! [rejected] dev -> dev (non-fast-forward) error: failed to push some refs to 'git@github.com:michaelliao/learngit.git' hint: Updates were rejected because the tip of your current branch is behind hint: its remote counterpart. Integrate the remote changes (e.g. hint: 'git pull ...') before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details. 

推送失败，由于你的小伙伴的最新提交和你试图推送的提交有冲突，解决办法也很简单，Git已经提示咱们，先用git pull把最新的提交从origin/dev抓下来，而后，在本地合并，解决冲突，再推送：

$ git pull
There is no tracking information for the current branch. Please specify which branch you want to merge with. See git-pull(1) for details. git pull <remote> <branch> If you wish to set tracking information for this branch you can do so with: git branch --set-upstream-to=origin/<branch> dev 

git pull也失败了，缘由是没有指定本地dev分支与远程origin/dev分支的连接，根据提示，设置dev和origin/dev的连接：

$ git branch --set-upstream-to=origin/dev dev Branch 'dev' set up to track remote branch 'dev' from 'origin'. 

再pull：

$ git pull Auto-merging env.txt CONFLICT (add/add): Merge conflict in env.txt Automatic merge failed; fix conflicts and then commit the result. 

这回git pull成功，可是合并有冲突，须要手动解决，解决的方法和分支管理中的解决冲突彻底同样。解决后，提交，再push：

$ git commit -m "fix env conflict" [dev 57c53ab] fix env conflict $ git push origin dev Counting objects: 6, done. Delta compression using up to 4 threads. Compressing objects: 100% (4/4), done. Writing objects: 100% (6/6), 621 bytes | 621.00 KiB/s, done. Total 6 (delta 0), reused 0 (delta 0) To github.com:michaelliao/learngit.git 7a5e5dd..57c53ab dev -> dev 

 

所以，多人协做的工做模式一般是这样：

1. 首先，能够试图用git push origin <branch-name>推送本身的修改；

2. 若是推送失败，则由于远程分支比你的本地更新，须要先用git pull试图合并；

3. 若是合并有冲突，则解决冲突，并在本地提交；

4. 没有冲突或者解决掉冲突后，再用git push origin <branch-name>推送就能成功！

若是git pull提示no tracking information，则说明本地分支和远程分支的连接关系没有建立，用命令git branch --set-upstream-to <branch-name> origin/<branch-name>。

这就是多人协做的工做模式，一旦熟悉了，就很是简单。

小结

• 查看远程库信息，使用git remote -v；

• 本地新建的分支若是不推送到远程，对其余人就是不可见的；

• 从本地推送分支，使用git push origin branch-name，若是推送失败，先用git pull抓取远程的新提交；

• 在本地建立和远程分支对应的分支，使用git checkout -b branch-name origin/branch-name，本地和远程分支的名称最好一致；

• 创建本地分支和远程分支的关联，使用git branch --set-upstream branch-name origin/branch-name；

• 从远程抓取分支，使用git pull，若是有冲突，要先处理冲突。

 

【Rebase】

在上一节咱们看到了，多人在同一个分支上协做时，很容易出现冲突。即便没有冲突，后push的童鞋不得不先pull，在本地合并，而后才能push成功。

每次合并再push后，分支变成了这样：

$ git log --graph --pretty=oneline --abbrev-commit
* d1be385 (HEAD -> master, origin/master) init hello
*   e5e69f1 Merge branch 'dev' |\ | * 57c53ab (origin/dev, dev) fix env conflict | |\ | | * 7a5e5dd add env | * | 7bd91f1 add new env | |/ * | 12a631b merged bug fix 101 |\ \ | * | 4c805e2 fix bug 101 |/ / * | e1e9c68 merge with no-ff |\ \ | |/ | * f52c633 add merge |/ * cf810e4 conflict fixed 

总之看上去很乱，有强迫症的童鞋会问：为何Git的提交历史不能是一条干净的直线？

实际上是能够作到的！

Git有一种称为rebase的操做，有人把它翻译成“变基”。

 

先不要随意展开想象。咱们仍是从实际问题出发，看看怎么把分叉的提交变成直线。

在和远程分支同步后，咱们对hello.py这个文件作了两次提交。用git log命令看看：

$ git log --graph --pretty=oneline --abbrev-commit * 582d922 (HEAD -> master) add author * 8875536 add comment * d1be385 (origin/master) init hello * e5e69f1 Merge branch 'dev' |\ | * 57c53ab (origin/dev, dev) fix env conflict | |\ | | * 7a5e5dd add env | * | 7bd91f1 add new env ... 

注意到Git用(HEAD -> master)和(origin/master)标识出当前分支的HEAD和远程origin的位置分别是582d922 add author和d1be385 init hello，本地分支比远程分支快两个提交。

如今咱们尝试推送本地分支：

$ git push origin master
To github.com:michaelliao/learngit.git
 ! [rejected]        master -> master (fetch first)
error: failed to push some refs to 'git@github.com:michaelliao/learngit.git'
hint: Updates were rejected because the remote contains work that you do hint: not have locally. This is usually caused by another repository pushing hint: to the same ref. You may want to first integrate the remote changes hint: (e.g., 'git pull ...') before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details. 

很不幸，失败了，这说明有人先于咱们推送了远程分支。按照经验，先pull一下：

$ git pull remote: Counting objects: 3, done. remote: Compressing objects: 100% (1/1), done. remote: Total 3 (delta 1), reused 3 (delta 1), pack-reused 0 Unpacking objects: 100% (3/3), done. From github.com:michaelliao/learngit d1be385..f005ed4 master -> origin/master * [new tag] v1.0 -> v1.0 Auto-merging hello.py Merge made by the 'recursive' strategy. hello.py | 1 + 1 file changed, 1 insertion(+) 

再用git status看看状态：

$ git status
On branch master
Your branch is ahead of 'origin/master' by 3 commits.
  (use "git push" to publish your local commits)

nothing to commit, working tree clean 

加上刚才合并的提交，如今咱们本地分支比远程分支超前3个提交。

用git log看看：

$ git log --graph --pretty=oneline --abbrev-commit * e0ea545 (HEAD -> master) Merge branch 'master' of github.com:michaelliao/learngit |\ | * f005ed4 (origin/master) set exit=1 * | 582d922 add author * | 8875536 add comment |/ * d1be385 init hello ... 

对强迫症童鞋来讲，如今事情有点不对头，提交历史分叉了。若是如今把本地分支push到远程，有没有问题？

有！

什么问题？

很差看！

有没有解决方法？

有！

这个时候，rebase就派上了用场。咱们输入命令git rebase试试：

$ git rebase First, rewinding head to replay your work on top of it... Applying: add comment Using index info to reconstruct a base tree... M hello.py Falling back to patching base and 3-way merge... Auto-merging hello.py Applying: add author Using index info to reconstruct a base tree... M hello.py Falling back to patching base and 3-way merge... Auto-merging hello.py 

输出了一大堆操做，究竟是啥效果？再用git log看看：

$ git log --graph --pretty=oneline --abbrev-commit * 7e61ed4 (HEAD -> master) add author * 3611cfe add comment * f005ed4 (origin/master) set exit=1 * d1be385 init hello ... 

本来分叉的提交如今变成一条直线了！这种神奇的操做是怎么实现的？其实原理很是简单。咱们注意观察，发现Git把咱们本地的提交“挪动”了位置，放到了f005ed4 (origin/master) set exit=1以后，这样，整个提交历史就成了一条直线。rebase操做先后，最终的提交内容是一致的，可是，咱们本地的commit修改内容已经变化了，它们的修改再也不基于d1be385 init hello，而是基于f005ed4 (origin/master) set exit=1，但最后的提交7e61ed4内容是一致的。

这就是rebase操做的特色：把分叉的提交历史“整理”成一条直线，看上去更直观。缺点是本地的分叉提交已经被修改过了。

最后，经过push操做把本地分支推送到远程：

Mac:~/learngit michael$ git push origin master Counting objects: 6, done. Delta compression using up to 4 threads. Compressing objects: 100% (5/5), done. Writing objects: 100% (6/6), 576 bytes | 576.00 KiB/s, done. Total 6 (delta 2), reused 0 (delta 0) remote: Resolving deltas: 100% (2/2), completed with 1 local object. To github.com:michaelliao/learngit.git f005ed4..7e61ed4 master -> master 

再用git log看看效果：

$ git log --graph --pretty=oneline --abbrev-commit * 7e61ed4 (HEAD -> master, origin/master) add author * 3611cfe add comment * f005ed4 set exit=1 * d1be385 init hello ... 

远程分支的提交历史也是一条直线。

 

小结

• rebase操做能够把本地未push的分叉提交历史整理成直线；

• rebase的目的是使得咱们在查看历史提交的变化时更容易，由于分叉的提交须要三方对比。