分支管理
概念:分支好比两条互不干扰的时间线,合并相当于两条时间线重叠了。
场景:在自己的分支干活,不影响其他分支。自己代码写的咋样没点B数吗。
创建与合并分支
在Git里,有一个主分支被叫做master
,有一个指针被叫做HEAD
。
-
一开始,只有
master
这一条分支,HEAD
指向当前分支即master
,master
指向提交。
-
使用命令
git branch
查看当前分支
-
创建新分支
dev
,和master
一样指向提交,再把HEAD
指向dev
就代表切换到dev
分支了。
-
使用命令
git branch dev
创建dev
分支 -
使用命令
git checkout dev
或git switch dev
切换到dev
分支
-
dev
分支新提交一次后,dev
指针向前移动一步,而master
指针不变,可以通过把master
指向dev
的当前提交来完成分支的合并。 -
在
dev
分支修改并提交readme.md
文件
-
切换回
master
分支,无法查看到在dev
分支添加的内容,因为那个提交是在dev
分支的,master
分支的提交点并没有改变。
-
使用命令
git merge dev
将dev
分支合并到master
分支上
-
合并分支以后,可以删除
dev
分支,即将dev
指针给删除掉。
-
使用命令
git branch -d dev
删除dev
分支
解决冲突
常见场景:
在某个分支节点对文件a的内容进行修改并commit
,在master
节点对文件a的内容做了不一样的修改并commit
,此时执行git merge
会报错,git只能试图将各自修改的内容合并起来,如果修改的是同一个内容就会产生冲突。
解决方案:
当git无法自动合并分支时,就必须手动编辑合并失败的文件,将其改为我们希望的内容,再提交,合并才能完成。
-
创建并切换到测试分支
test
,修改readme.md
的内容并提交。
-
切换回
master
分支,修改readme.md
的内容并提交。
-
此时git的各分支都有了各自的新的提交。
-
执行
git merge
报错,无法快速合并,在多个分支对readme.md
做了修改并提交了。
-
使用
vim
命令,手动将冲突的地方修改成我们希望的内容。
-
解决冲突后,再次提交。
-
使用命令
git log --graph
可以产看到分支的合并图。
分支管理策略
常见场景:
Git默认使用Fast forward
模式,在这种模式下,合并分支,并删除分支后,会丢失分支的信息,导致合并后的历史没有分支,看不出曾经合并过。
解决方案:
在合并分支的时候强制禁用Fast forward
模式,添加--no-ff
参数。
在实际开发中,
master
分支应该是非常稳定的,仅用来发布新版本,平时都在dev
分支上干活,到了上线的时候,再把dev
分支合并到master
分支。
团队成员之间,每个人都有自己的分支,时不时地往dev
分支合并你自己的分支即可。
所以,实际上团队合作的分支看起来就像下面这样:
- 创建并切换至
mx
分支。
- 新建一个mx.txt文件,并提交。
- 切换回
master
分支,强制禁用Fast forward
模式合并mx
分支。
- 查看分支合并历史。
临时分支(bug分支)
常见场景:
在软件开发的流程中,发现一个bug急需修复,这个时候可以直接创建一个新的临时分支来修复bug,修复后,合并分支,再删除临时分支。但是你当前分支的工作只做到一半,还不能直接commit
到版本库,至少还要2小时,上司又要求你这个bug必须30分钟内解决。
解决方案:
可以通过git stash
命令将当前的工作现场保存起来,等bug修复以后再恢复工作现场,接着干活。
- 修改FirstTest.txt文件,模拟当前工作现场,并保存工作现场
- 确定是在哪个分支修复bug,假设在
master
分支上修复,就从master
分支创建临时分支bugfix-22
。
- 切换回
master
分支,合并临时分支,再删除临时分支。
- 切换回
mx
分支,使用git stash applay
命令来恢复现场,接着干活。
注:
master
分支bug已经修复了,但是早期从master
分支分出来的dev
分支其实存在这个bug,那我是不是要再重新再dev
分支修复一遍呢?
我们可以使用git cherry-pick <commmit id>
命令,将指定提交所做的修改复制到dev
分支。
feature分支
常见场景:
单独创建一个新功能的分支来开发新功能,开发完成以后,合并,删除,一气呵成。but,你开发到一半,客户说这个功能不要了,虽然白干了,但是对应的分支还是要销毁。but,Git这个时候会提示你该分支还未被合并,无法直接删除。
解决方案:
使用git branch -D <branch name>
命令,强行删除。
- 创建一个新分支
feature-music
,模拟完成开发。
- 强制删除
feature
分支。
多人协作
概念:远程仓库默认名称为origin
,从远程仓库克隆时,Git自动把本地的master
分支和远程的master
分支对应起来了。推送分支就是把该分支上所有本地提交都推送到远程仓库,但是并不是一定要把本地分支都推送到远程仓库,一般情况下:
master
分支是主分支,要保证时刻与远程同步dev
分支是开发分支,团队成员都在上面工作,也需要与远程保持同步bug
分支只用于本地修复bug,一般不会推送到远程feature
分支是否推送到远程,取决于是否和其他成员联合开发
- 首先,查看当前关联的远程库信息,使用命令
git remote -v
- 使用
git push origin branch-name
推送自己的修改,如果推送失败,则表示远程分支比本地更新,需要先用git pull
试图合并。如果git push
提示no tracking information
表示本地分支与远程分支之间没有建立链接关系,使用命令git branch --set-upstream-to <branch-name> origin/<branch-name>
建立链接。继续使用git pull
,如果有冲突,则解决冲突后再推送。