@(139 - Environment Settings | 环境配置)
一、Why?
分支在实际中有什么用呢?假设你准备开发一个新功能,但是需要两周才能完成,第一周你写了50%的代码,如果立刻提交,由于代码还没写完,不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交,又存在丢失每天进度的巨大风险。
现在有了分支,就不用怕了。你创建了一个属于你自己的分支,别人看不到,还继续在原来的分支上正常工作,而你在自己的分支上干活,想提交就提交,直到开发完毕后,再一次性合并到原来的分支上,这样,既安全,又不影响别人工作。
二、创建与合并分支
2.1 Why? - Git高效原因 - 指针操作
Git高效原因:指针操作
HEAD
指向的就是当前分支。 Git创建一个分支很快,因为除了增加一个dev指针,改改HEAD的指向,工作区的文件都没有任何变化!
2.2 分支操作代码
Git鼓励大量使用分支:
查看所有分支:git branch
创建分支:git branch <branch_name>
切换分支:git checkout <branch_name>
创建+切换分支:git checkout -b <new_branch_name>
合并某分支到当前分支:git merge <name>
删除分支:git branch -d <name>
2.3 Demo
1.我们把dev
分支的工作成果合并到master
分支上:
$ git merge devUpdating d17efd8..fec145aFast-forward readme.txt | 1 + 1 file changed, 1 insertion(+)
2.合并完成后,就可以放心地删除dev分支了:
$ git branch -d devDeleted branch dev (was fec145a).
3.删除后,查看branch,就只剩下master分支了:
$ git branch* master
因为创建、合并和删除分支非常快,所以Git鼓励你
1.使用分支完成某个任务 2.合并后再删掉分支这和直接在master分支上工作效果是一样的,但过程更安全。
三、解决冲突
P.S. Git Bash
1.查看文本内容cat <name>
2.修改文件内容vi <name>
3.vim 保存并退出:wq
当Git无法自动合并分支时,就必须首先解决冲突。解决冲突后,再提交,合并完成。
用git log --graph
命令可以看到分支合并图。
四、分支管理策略
4.1 默认 :fast forward模式
通常合并分支时,如果可能,Git会默认用Fast forward
模式,但这种模式下,删除分支后,会丢掉分支信息。
不使用Fast forward模式,merge后就像这样:
4.2 实际分支策略
如果要强制禁用Fast forward
模式,Git就会在merge时生成一个新的commit,这样,从分支历史上就可以看出分支信息。
准备合并dev
分支,请注意--no-ff
参数,表示禁用Fast forward
:
$ git merge --no-ff -m "merge with no-ff" devMerge made by the 'recursive' strategy. readme.txt | 1 + 1 file changed, 1 insertion(+)
在实际开发中,我们应该按照几个基本原则进行分支管理:
首先,master分支应该是非常稳定的,也就是仅用来发布新版本,平时不能在上面干活;
那在哪干活呢?干活都在dev分支上,也就是说,dev分支是不稳定的,到某个时候,比如1.0版本发布时,再把dev分支合并到master上,在master分支发布1.0版本;
你和你的小伙伴们每个人都在dev分支上干活,每个人都有自己的分支,时不时地往dev分支上合并就可以了。
所以,团队合作的分支看起来就像这样:
4.3 分支管理小结
Git分支十分强大,在团队开发中应该充分应用。
合并分支时,加上--no-ff
参数就可以用普通模式合并,合并后的历史有分支,能看出来曾经做过合并,而fast forward合并就看不出来曾经做过合并。
五、Bug分支
软件开发中,bug就像家常便饭一样。有了bug就需要修复,在Git中,由于分支是如此的强大,
修复bug时,我们会通过创建新的临时 bug分支进行修复,然后合并,最后删除;
- 保存工作现场 :
git stash
- 查看stash:
git stash list
- 恢复现场Method1(stash内容并不删除)
$git stash apply$git stash drop;删除
4.恢复现场Method2(恢复+删除):git stash pop
小结:
当手头工作没有完成时,先把工作现场git stash
一下,然后去修复bug,修复后,再git stash pop
,回到工作现场。 六、多人协作
6.1 推送分支
并不是一定要把本地分支往远程推送,那么,哪些分支需要推送,哪些不需要呢?
master
分支是主分支,因此要时刻与远程同步;
dev
分支是开发分支,团队所有成员都需要在上面工作,所以也需要与远程同步;
bug
分支只用于在本地修复bug,就没必要推到远程了,除非老板要看看你每周到底修复了几个bug;
feature
分支是否推到远程,取决于你是否和你的小伙伴合作在上面开发。
总之,就是在Git中,分支完全可以在本地自己藏着玩,是否推送,视你的心情而定!
6.2 多人协作的工作模式
1.首先,可以试图用git push origin branch-name
推送自己的修改;
2.如果推送失败,则因为远程分支比你的本地更新,需要先用git pull
试图合并;
3.如果合并有冲突,则解决冲突,并在本地提交;
4.没有冲突或者解决掉冲突后,再用git push origin branch-name
推送就能成功!
5.如果git pull
提示“no tracking information”
,则说明本地分支和远程分支的链接关系没有创建,用命令git branch --set-upstream branch-name origin/branch-name
。
这就是多人协作的工作模式,一旦熟悉了,就非常简单。
6.3 多人协作小结
查看远程库信息,使用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
,如果有冲突,要先处理冲突。
- 整理转载自 廖雪峰博客 https://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000