(五)Git--分支管理-白红宇

(五)Git--分支管理

阅读量：4186 次

发布时间：2019-05-26

本文共 7995 字，大约阅读时间需要 26 分钟。

1. 创建与合并分支

在Git里每次提交会被串成一条时间线,这条时间线就是一个分支.而HEAD是指向当前分支,当前分支在指向最新一次提交;

例如:一开始的时候,master分支是一条线,Git用master指向最新提交,在用HEAD指向master分支,就能确定当前分支,以及当前分支的提交点;

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

这时,我们可以发现.Git创建一个分支很快,因为除了增加了一个dev指针,改改HEAD的指向,工作区的文件都没有任何变化!

不过,从现在开始,对工作区的修改就是针对dev分支的了,比如再次进行提交后,dev指针就会继续向前移动指向最新一次的提交.而master指针不变;

接下来我们看看合并操作,假如我们在dev上的工作完成了,就可以把dev合并到master上,Git怎么进行合并呢?最简单的方法,就是直接把master指向dev的当前提交,就完成了合并:

所以Git合并分支也很快!就改变了指针指向,工作区内容也不变!

合并完分支后,也可以删除分支,删除dev分支想必你已经可以想到,对的,就是把dev指针给删掉,删掉后我们就剩下了一条master分支:

接下来我们开始进行操练:

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

git checkout命令加上-b参数表示创建并切换,相当于下面两条命令:

$ git branch dev$ git checkout devSwitched to branch 'dev'

然后使用git branch命令查看当前分支:

$ git branch* dev  master

git branch命令会列出所有分支,当前分支前面会标一个*号.

然后,我们可以在dev分支上正常提交:

$ git commit -m "忽略不要的文件"[dev fae4e76] 忽略不要的文件 2 files changed, 12 insertions(+), 4 deletions(-) create mode 100644 .gitignore

现在,dev分支的工作完成,我们可以切换回master分支:

$ git checkout masterSwitched to branch 'master'Your branch is up-to-date with 'origin/master'.

切换回master分支后,发现刚才修改的内容不见了!那是因为那个提交是在dev分支上,而master分支此刻的提交点并没有变:

现在我们把dev分支上的工作成果合并到master上:

$ git merge devUpdating e151f7e..fae4e76Fast-forward .gitignore          | 8 ++++++++ .idea/workspace.xml | 8 ++++---- 2 files changed, 12 insertions(+), 4 deletions(-) create mode 100644 .gitignore

git merge命令用于合并指定分支到当前分支.合并后在查看刚才修改的内容,就可以看到,和dev分支最新提交的内容是完全一样的.

注意到上面的Fast-forward信息,Git告诉我们,这次合并是"快进模式",也就是直接把master指向dev当前的提交,所以合并速度非常快.

当然,也有意外发生,不是每次合并都能Fast-forward的;

合并完成后,就可以放心地删除dev分支了:

$ git branch -d devDeleted branch dev (was fae4e76).

删除后,查看branch,就只剩下master分支了:

$ git branch* master

小结

查看分支:git branch

创建分支:git branch <name>

切换分支:git checkout <name>

创建+切换分支:git checkout -b <name>

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

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

2. 解决冲突

分支合并的过程往往并不是一帆风顺的,准备新的feature1分支,我们在这个分支上作出我们要修改的内容,然后提交.然后在切换回master分支上时,要将feature1分支上提交的内容合并过来,这时如果其他人已经在master分支上也对相应文件作出了修改,master和feature1分支各自有了新的提交,变成了如下这个样子:

这种情况下,Git无法执行"快速合并",只能把各自的修改合并起来,但这种合并就可能会有冲突,如下所示:

$ git merge feature1Auto-merging readme.txtCONFLICT (content): Merge conflict in readme.txtAutomatic 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.## Unmerged paths:#   (use "git add/rm 
   
    ..." as appropriate 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.<<<<<<< HEADCreating a new branch is quick & simple.=======Creating a new branch is quick AND simple.>>>>>>> feature

Git用<<<<<<<,=======,>>>>>>>标记不同分支的内容,其中HEAD表示当前分支的内容.

解决冲突后,在提交,现在master和feature1分支变成了下图所示:

用git log --graph命令可以看到分支合并图:

$ git log --graph --pretty*   commit b95bbf0ac897b2d88fa4bcf0308913f624d566c7|\  Merge: c2e47c0 89cdc59| | Author: alan7c 
   
    | | Date:   Fri Mar 17 17:48:28 2017 +0800| || |     conflict fixed| || * commit 89cdc59631411c217e99b8c0b1a6c1ceee63d677| | Author: alan7c 
    
     | | Date:   Fri Mar 17 17:40:45 2017 +0800| || |     AND simple| |* | commit c2e47c06db550e03b2c19ee5247b03d949a10541|/  Author: alan7c 
     
      |   Date:   Fri Mar 17 17:42:44 2017 +0800||       & simple|* commit fae4e76e7b00741fd3894ebdfcf46cb5712b2db2| Author: alan7c 
      
       | Date:   Fri Mar 17 15:34:00 2017 +0800||     忽略不要的文件|* commit e151f7e1a74ca3eb4a466568dbac5de922b3e596| Author: alan7c 
       
        | Date:   Mon Mar 13 21:19:10 2017 +0800||     add README.md|* commit 3fafa4a18f01733d1347da2248775db29421ffaa| Author: alan7c 
        
         | Date: Mon Mar 13 11:32:54 2017 +0800

最后,我们可以删除feature1分支:

$ git branch -d feature1Deleted branch feature1 (was 89cdc59).

3.分支管理策略

通常合并分支时,如果可能,Git会用Fast forward模式,但这种模式下,删除分支后,会丢掉分支信息.如果强制禁用Fast forward模式,Git就会在merge时生成一个新的commit,这样,从分支历史上就可以看出分支信息.

那么如何禁用Fast forward模式呢,就要使用--no-ff参数:

git merge --no-ff -m "merge with no-ff" dev

因为本次合并要创建一个新的commit,所以加上-m参数,把commit描述写进去.

不使用Fast forward模式,merge后就像这样:

分支策略

在实际开发中,我们应该按照几个基本原则进行分支管理:

首先要保证master分支应该是非常稳定的,也就是仅用来分布新版本,平时不能在上面干活;

干活都在dev分支,也就是说dev分支是不稳定的,到某个时候如版本发布时,在把dev分支合并到master上,用master分支发布新版本.
我们可以和小伙伴们每个人都在dev分支上干活,每个人都有自己的分支,时不时的往dev分支上合并就可以了.
所以团队合作的分支看起来就像这样:

如果我们一个临时分支上完成了开发任务,可是突然产品经理说不要这个功能了,所以我们没有合并这个分支而且需要删除它,使用git branch -d <name>时,会销毁失败,Git会提示我们这个分支还没有完成合并,如果删除,将丢失修改,如果强行删除,需要使用命令git branch -D <name>

小结

合并分支时,加上--no-ff参数就可以用普通模式合并,合并后的历史有分支记录,而Fast forward合并就看不出来曾经做过合并.

4.Bug分支

在软件开发过程中,bug是普遍存在的.既然会出现bug,当然就要去修复,在Git中分支系统是什么强大的,所以每个bug都可以通过一个新的临时分支来修复,修复后在删除这个临时分支,当我们接到一个编号110的bug时,想当然我们会创建一个issue-110来修复它,但是等等,当前正在dev分支上进行的工作还没有提交,可是这个时候并不是你不想提交而是工作只进行了一半,还没法提交,预计完成还需要一天时间,但是,bug必须在两个小时内修复,怎么办呢?

不怕,Git还提供了一个stash功能,可以把当前工作现场"储藏起来",等以后恢复现场后继续工作:

git stashSaved working directory and index state WIP on dev: 6224937 add mergeHEAD is now at 6224937 add merge

现在,用git status查看工作区,就是干净的,因此就可以放开手脚来修复bug了.

假如我们要从master分支上修复bug,就从master创建临时分支:

$ git checkout masterSwitched to branch 'master'Your branch is ahead of 'origin/master' by 6 commits.$ git checkout -b issue-101Switched to a new branch 'issue-110'

等到bug修复后,然后提交:

git add .git commit -m "fix bug 110"[issue-110 cc17032] fix bug 110 1 file changed, 1 insertion(+), 1 deletion(-)

修复完成后,切换到master分支,并完成合并,最后删除issue-110分支:

$ git checkout masterSwitched to branch 'master'Your branch is ahead of 'origin/master' by 2 commits.$ git merge --no-ff -m "merged bug fix 110" issue-110Merge made by the 'recursive' strategy. readme.txt |    2 +- 1 file changed, 1 insertion(+), 1 deletion(-)$ git branch -d issue-110Deleted branch issue-101 (was cc17032).

太棒了,修复完bug后,是时候接着回到dev分支干活了!

$ git checkout devSwitched to branch 'dev'$ git status# On branch devnothing to commit (working directory clean)

工作区是干净的,刚才的工作现场存到哪里去了?用git stash list命令查看:

$ git stash liststash@{0}: WIP on dev: 6224937 add merge

工作现场显然还在,这时需要使用恢复命令来恢复现场:

一是用git stash apply恢复,但是恢复后,stash内容并不删除,你需要用git stash drop来删除;

二是用git stash pop,恢复的同时把stash内容也删了;

小贴士:

你可以多次stash,恢复的时候,先用git stash list查看,然后恢复指定的stash,用命令:

git stash apply stash@{0}

5.多人协作

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

要查看远程库的信息,用git remote:

$ git remoteorigin

或者git remote -v显示更详细的信息:

$ git remote -vorigin  git@github.com:Alanluochong/strman-java.git (fetch)origin  git@github.com:Alanluochong/strman-java.git (push)

上面显示了可以抓取和推送的origin的地址,如果没有推送权限,就看不到push地址.

推送分支

推送时,要指定本地分支,这样,Git就会把该分支推送到远程仓库所对应的远程分支上:

$ git push origin master

抓取分支

$ git clone git@github.com:Alanluochong/strman-java.git

默认情况下,拉取后只能看到本地有一个master分支,如果要在其他分支上开发,就必须创建远程origin的相应分支到本地,于是可以用这个命令创建本地分支:

$ git checkout -b dev origin/dev

向远程推送本地的提交,有可能推送失败,因为你的小伙伴的最新提交和你试图推送的提交有冲突,这时需要使用git pull把最新的提交从origin/dev抓下来,然后,在本地合并,解决冲突在推送:

$ git pullremote: Counting objects: 5, done.remote: Compressing objects: 100% (2/2), done.remote: Total 3 (delta 0), reused 3 (delta 0)Unpacking objects: 100% (3/3), done.From github.com:alanluochong/Java   fc38031..291bea8  dev        -> origin/devThere 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 
    
    
     If you wish to set tracking information for this branch you can do so with:    git branch --set-upstream dev origin/

git pull也失败了,原因是没有指定本地dev分支与远程origin/dev分支的连接,根据提示,设置dev与远程origin/dev的连接:

$ git branch --set-upstream dev origin/devBranch dev set up to track remote branch dev from origin.

小结

多人协作的工作模式通常是这样:

首先,在本地创建和远程对应的分支,使用git branch -b branch-name origin/branch-name,本地分支最好与远程名称一致;

完成开发后,可以试图使用git push origin branch-name推送自己的修改;

如果推送失败,则因为远程分支比你的本地有新的提交,需要使用git pull试图合并;

如果合并有冲突,则解决冲突,并在本地提交;

没有冲突或者解决冲突后,再用git push origin branch-name推送就能成功!
如果git pull提示"no tracking information",则说明本地分支和远程分支的连接关系没有创建,用命令git branch --set-upstream branch-name origin/branch-name.