(五)Git--分支管理
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 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分支上正常提交:
$ git commit -m "忽略不要的文件"
[dev fae4e76] 忽略不要的文件
2 files changed, 12 insertions(+), 4 deletions(-)
create mode 100644 .gitignore
现在,dev分支的工作完成,我们可以切换回master分支:
$ git checkout master
Switched to branch 'master'
Your branch is up-to-date with 'origin/master'.
切换回master分支后,发现刚才修改的内容不见了!那是因为那个提交是在dev分支上,而master分支此刻的提交点并没有变:
现在我们把dev分支上的工作成果合并到master上:
$ git merge dev
Updating e151f7e..fae4e76
Fast-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 dev
Deleted branch dev (was fae4e76).
删除后,查看branch,就只剩下master分支了:
$ git branch
* master
小结
查看分支:git branch
创建分支:git branch
切换分支:git checkout
创建+切换分支:git checkout -b
合并某分支到当前分支:git merge
删除分支:git branch -d
2. 解决冲突
分支合并的过程往往并不是一帆风顺的,准备新的feature1分支,我们在这个分支上作出我们要修改的内容,然后提交.然后在切换回master分支上时,要将feature1分支上提交的内容合并过来,这时如果其他人已经在master分支上也对相应文件作出了修改,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.
#
# 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.
<<<<<<< HEAD
Creating 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 feature1
Deleted 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时,会销毁失败,Git会提示我们这个分支还没有完成合并,如果删除,将丢失修改,如果强行删除,需要使用命令git branch -D
小结
合并分支时,加上--no-ff参数就可以用普通模式合并,合并后的历史有分支记录,而Fast forward合并就看不出来曾经做过合并.
4.Bug分支
在软件开发过程中,bug是普遍存在的.既然会出现bug,当然就要去修复,在Git中分支系统是什么强大的,所以每个bug都可以通过一个新的临时分支来修复,修复后在删除这个临时分支,当我们接到一个编号110的bug时,想当然我们会创建一个issue-110来修复它,但是等等,当前正在dev分支上进行的工作还没有提交,可是这个时候并不是你不想提交而是工作只进行了一半,还没法提交,预计完成还需要一天时间,但是,bug必须在两个小时内修复,怎么办呢?
不怕,Git还提供了一个stash功能,可以把当前工作现场"储藏起来",等以后恢复现场后继续工作:
git stash
Saved working directory and index state WIP on dev: 6224937 add merge
HEAD is now at 6224937 add merge
现在,用git status查看工作区,就是干净的,因此就可以放开手脚来修复bug了.
假如我们要从master分支上修复bug,就从master创建临时分支:
$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 6 commits.
$ git checkout -b issue-101
Switched 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 master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 2 commits.
$ git merge --no-ff -m "merged bug fix 110" issue-110
Merge made by the 'recursive' strategy.
readme.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
$ git branch -d issue-110
Deleted branch issue-101 (was cc17032).
太棒了,修复完bug后,是时候接着回到dev分支干活了!
$ git checkout dev
Switched to branch 'dev'
$ git status
# On branch dev
nothing to commit (working directory clean)
工作区是干净的,刚才的工作现场存到哪里去了?用git stash list命令查看:
$ git stash list
stash@{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 remote
origin
或者git remote -v显示更详细的信息:
$ git remote -v
origin [email protected]:Alanluochong/strman-java.git (fetch)
origin [email protected]:Alanluochong/strman-java.git (push)
上面显示了可以抓取和推送的origin的地址,如果没有推送权限,就看不到push地址.
推送分支
推送时,要指定本地分支,这样,Git就会把该分支推送到远程仓库所对应的远程分支上:$ git push origin master
抓取分支
$ git clone [email protected]:Alanluochong/strman-java.git
默认情况下,拉取后只能看到本地有一个master分支,如果要在其他分支上开发,就必须创建远程origin的相应分支到本地,于是可以用这个命令创建本地分支:$ git checkout -b dev origin/dev
向远程推送本地的提交,有可能推送失败,因为你的小伙伴的最新提交和你试图推送的提交有冲突,这时需要使用git pull把最新的提交从origin/dev抓下来,然后,在本地合并,解决冲突在推送:
$ git pull
remote: 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/dev
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
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/dev
Branch 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.