赞
踩
开始介绍Git的杀⼿级功能之⼀(注意是之⼀,也就是后⾯还有之⼆,之三……):分⽀。分⽀就是科幻电影⾥⾯的平⾏宇宙,当你正在电脑前努⼒学习C++的时候,另⼀个你正在另⼀个平⾏宇宙⾥努⼒学习JAVA。
如果两个平⾏宇宙互不⼲扰,那对现在的你也没啥影响。不过,在某个时间点,两个平⾏宇宙合并了,结果,你既学会了C++⼜学会了JAVA!
在版本回退⾥,你已经知道,每次提交,Git都把它们串成⼀条时间线,这条时间线就可以理解为是⼀个分⽀。截⽌到⽬前,只有⼀条时间线,在Git⾥,这个分⽀叫主分⽀,即master分⽀。
再来理解⼀下HEAD,HEAD严格来说不是指向提交,⽽是指向master,master才是指向提交的,所以,HEAD指向的就是当前分⽀。
每次提交,master分⽀都会向前移动⼀步,这样,随着你不断提交,master分⽀的线也越来越⻓,⽽HEAD只要⼀直指向master分⽀即可指向当前分⽀。
[zl@VM-16-2-centos lesson]$ cat .git/HEAD
ref: refs/heads/master
[zl@VM-16-2-centos lesson]$ cat .git/refs/heads/master
b879e4f12400129cedabecb18f4f15238558f539
Git⽀持我们查看或创建其他分⽀,在这⾥我们来创建第⼀个⾃⼰的分⽀dev ,对应的命令为:
[zl@VM-16-2-centos lesson]$ git branch
* master
[zl@VM-16-2-centos lesson]$ git branch dev
[zl@VM-16-2-centos lesson]$ git branch
dev
* master
当我们创建新的分⽀后,Git新建了⼀个指针叫dev, * 表⽰当前 HEAD 指向的分⽀是 master 分⽀。另外,可以通过⽬录结构发现,新的 dev 分⽀:
[zl@VM-16-2-centos lesson]$ cat .git/refs/heads/master
b879e4f12400129cedabecb18f4f15238558f539
[zl@VM-16-2-centos lesson]$ cat .git/refs/heads/dev
b879e4f12400129cedabecb18f4f15238558f539
发现⽬前dev和master指向同⼀个修改。并且也可以验证下HEAD⽬前是指向 master 的。
git checkout – (撤销工作区内容)
git checkout 切换分支
那如何切换到dev分⽀下进⾏开发呢?使⽤git checkout命令即可完成切换,⽰例如下:
[zl@VM-16-2-centos lesson]$ git checkout dev
Switched to branch 'dev'
[zl@VM-16-2-centos lesson]$ git branch
* dev
master
[zl@VM-16-2-centos lesson]$ cat .git/HEAD
ref: refs/heads/dev
我们发现HEAD已经指向了dev,就表⽰我们已经成功的切换到了dev上!
接下来,在 dev 分⽀下修改readme⽂件,新增⼀⾏内容,并进⾏⼀次提交操作:
[zl@VM-16-2-centos lesson]$ ls
file1 file2 file3 readme
[zl@VM-16-2-centos lesson]$ vim readme
[zl@VM-16-2-centos lesson]$ vim readme
[zl@VM-16-2-centos lesson]$ git add readme
[zl@VM-16-2-centos lesson]$ git commit -m "me readme"
[dev f679d41] me readme
1 file changed, 2 insertions(+)
[zl@VM-16-2-centos lesson]$ cat readme
hello world
aaa on dev branch
现在,dev分⽀的⼯作完成,我们就可以切换回master分⽀:
[zl@VM-16-2-centos lesson]$ git checkout master
Switched to branch 'master'
[zl@VM-16-2-centos lesson]$ git branch
dev
* master
[zl@VM-16-2-centos lesson]$ ls
file1 file2 file3 readme
[zl@VM-16-2-centos lesson]$ cat readme
hello world
切换回master分⽀后,发现ReadMe⽂件中新增的内容不⻅了!!!赶紧再切回dev看看:
[zl@VM-16-2-centos lesson]$ git checkout dev
Switched to branch 'dev'
[zl@VM-16-2-centos lesson]$ cat readme
hello world
aaa on dev branch
在dev分⽀上,内容还在。为什么会出现这个现象呢?我们来看看dev分⽀和master分⽀指向,发现两者指向的提交是不⼀样的:
[zl@VM-16-2-centos lesson]$ cat .git/refs/heads/dev
f679d4133a8bd022b86f65de3c311db3f9c3745b
[zl@VM-16-2-centos lesson]$ cat .git/refs/heads/master
b879e4f12400129cedabecb18f4f15238558f539
[zl@VM-16-2-centos lesson]$ git cat-file -p f679d4133a8bd022b86f65de3c311db3f9c3745b
tree b7b88491390cec3c832a0998e6d71a47429488ce
parent b879e4f12400129cedabecb18f4f15238558f539
author sushangzl <939712250@qq.com> 1713668297 +0800
committer sushangzl <939712250@qq.com> 1713668297 +0800
me readme
看到这⾥就能明⽩了,因为我们是在dev分⽀上提交的,⽽master分⽀此刻的提交点并没有变,此时的状态如图如下所⽰。
当切换到master分⽀之时,HEAD就指向了master,当然看不到提交了!
为了在master主分⽀上能看到新的提交,就需要将dev分⽀合并到master分⽀
[zl@VM-16-2-centos lesson]$ git checkout master
Switched to branch 'master'
[zl@VM-16-2-centos lesson]$ git merge dev
Updating b879e4f..f679d41
Fast-forward
readme | 2 ++
1 file changed, 2 insertions(+)
[zl@VM-16-2-centos lesson]$ cat readme
hello world
aaa on dev branch
[zl@VM-16-2-centos lesson]$ cat .git/refs/heads/master
f679d4133a8bd022b86f65de3c311db3f9c3745b
git merge 命令⽤于合并指定分⽀到当前分⽀。合并后,master就能看到dev分⽀提交的内容了。此时的状态如图如下所⽰。
Fast-forward代表“快进模式”,也就是直接把master指向dev的当前提交,所以合并速度⾮常快。当然,也不是每次合并都能Fast-forward。
合并完成后,dev分⽀对于我们来说就没⽤了,那么dev分⽀就可以被删除掉,注意如果当前正处于某分⽀下,就不能删除当前分⽀。
⽽可以在其他分⽀下删除当前分⽀
[zl@VM-16-2-centos lesson]$ git checkout master
Already on 'master'
[zl@VM-16-2-centos lesson]$ git branch -d dev
Deleted branch dev (was f679d41).
此时的状态如图如下所⽰。
因为创建、合并和删除分⽀⾮常快,所以Git⿎励你使⽤分⽀完成某个任务,合并后再删掉分⽀,这和直接在master分⽀上⼯作效果是⼀样的,但过程更安全。
可是,在实际分⽀合并的时候,并不是想合并就能合并成功的,有时候可能会遇到代码冲突的问题。为了演⽰这问题,创建⼀个新的分⽀dev1 ,并切换⾄⽬标分⽀,我们可以使⽤git checkout -b dev1 ⼀步完成创建并切换的动作,⽰例如下:
[zl@VM-16-2-centos lesson]$ git checkout -b dev1
Switched to a new branch 'dev1'
[zl@VM-16-2-centos lesson]$ git branch
* dev1
master
在 dev1 分⽀下修改 readme ⽂件,更改⽂件内容如下,并进⾏⼀次提交
[zl@VM-16-2-centos lesson]$ vim readme [zl@VM-16-2-centos lesson]$ ls file1 file2 file3 readme [zl@VM-16-2-centos lesson]$ git add . [zl@VM-16-2-centos lesson]$ git status # On branch dev1 # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # modified: readme # [zl@VM-16-2-centos lesson]$ git commit -m "md readme: bbb" [dev1 3dc0539] md readme: bbb 1 files changed, 1 insertion(+), 1 deletion(-) [zl@VM-16-2-centos lesson]$ cat readme hello world bbb on dev branch
切换⾄ master 分⽀,观察 ReadMe ⽂件内容:
[zl@VM-16-2-centos lesson]$ git checkout master
Switched to branch 'master'
结果还是aaa on dev branch
我们发现,切回来之后,⽂件内容又变成了⽼的版本,这种现象很正常,我们现在也完全能理解。此时在master分⽀上,我们对readme⽂件再进⾏⼀次修改,并进⾏提交,如下:
[zl@VM-16-2-centos lesson]$ vim readme
[zl@VM-16-2-centos lesson]$ git add .
[zl@VM-16-2-centos lesson]$ git commit -m "md readme: ccc"
[master 9c88ce4] md readme: ccc
1 file changed, 1 insertion(+), 1 deletion(-)
[zl@VM-16-2-centos lesson]$ git branch
dev1
* master
现在, master 分⽀和 dev1 分⽀各⾃都分别有新的提交,变成了这样:
这种情况下,Git只能试图把各⾃的修改合并起来,但这种合并就可能会有冲突,如下所⽰:
[zl@VM-16-2-centos lesson]$ git merge dev1
Auto-merging readme
CONFLICT (content): Merge conflict in readme
Automatic merge failed; fix conflicts and then commit the result.
发现readme⽂件有冲突后,可以直接查看⽂件内容,要说的是Git会⽤<<<,===,>>>
来标记出不同分⽀的冲突内容,如下所⽰:
<<<<<<< HEAD
ccc on dev branch
=======
bbb on dev branch
>>>>>>> dev1
此时我们必须要⼿动调整冲突代码,并需要再次提交修正后的结果!!(再次提交很重要,切勿忘记)
[zl@VM-16-2-centos lesson]$ vim readme [zl@VM-16-2-centos lesson]$ git status # On branch master # You have unmerged paths. # (fix conflicts and run "git commit") # # Unmerged paths: # (use "git add <file>..." to mark resolution) # # both modified: readme # [zl@VM-16-2-centos lesson]$ git add . [zl@VM-16-2-centos lesson]$ git commit -m "merge dev1" [master c54f7be] merge dev1 [zl@VM-16-2-centos lesson]$ git status # On branch master nothing to commit, working directory clean [zl@VM-16-2-centos lesson]$ cat readme hello world bbb on dev branch
到这⾥冲突就解决完成,此时的状态变成了
⽤带参数的git log也可以看到分⽀的合并情况,具体⼤家可以⾃⾏搜索 git log 的⽤法:
git log --graph --pretty=oneline --abbrev-commit
prapgh:表示使用图示的方式展示
abbrev:表示将长的commit id变成短的commit id
通常合并分⽀时,如果可能,Git会采⽤ Fast forward 模式。还记得如果我们采⽤ Fast forward 模式之后,形成的合并结果是什么呢
在这种 Fast forward 模式下,删除分⽀后,查看分⽀历史时,会丢掉分⽀信息,看不出来最新提交到底是merge进来的还是正常提交的。
但在合并冲突部分,我们也看到通过解决冲突问题,会再进⾏⼀次新的提交,得到的最终状态为:
那么这就不是 Fast forward 模式了,这样的好处是,从分⽀历史上就可以看出分⽀信息。例如我们现在已经删除了在合并冲突部分创建的 dev1 分⽀,但依旧能看到master其实是由其他分⽀合并得到:
Git⽀持我们强制禁⽤Fast forward 模式,那么就会在merge时⽣成⼀个新的commit ,这样,从分⽀历史上就可以看出分⽀信息。下⾯我们实战⼀下 --no-ff ⽅式的git merge 。⾸先,创建新的分⽀ dev2 ,并切换⾄新的分⽀:
[zl@VM-16-2-centos lesson]$ git checkout dev2
Switched to branch 'dev2'
修改readme⽂件,并提交⼀个新的 commit :
[zl@VM-16-2-centos lesson]$ git add .
[zl@VM-16-2-centos lesson]$ git commit -m "md readme"
[dev2 930c91c] md readme
1 file changed, 1 insertion(+)
切回 master 分⽀,开始合并:
zl@VM-16-2-centos lesson]$ git checkout master
Switched to branch 'master'
[zl@VM-16-2-centos lesson]$ git merge --no-ff -m "merge dev2" dev2
Merge made by the 'recursive' strategy.
readme | 1 +
1 file changed, 1 insertion(+)
请注意 --no-ff 参数,表⽰禁⽤Fast forward 模式。禁⽤ Fast forward 模式后合并会创建⼀个新的 commit ,所以加上 -m 参数,把描述写进去。
可以看到,不使⽤ Fast forward 模式,merge后就像这样:
所以在合并分⽀时,加上 --no-ff 参数就可以⽤普通模式合并,合并后的历史有分⽀,能看出来曾经做过合并,⽽ fast forward 合并就看不出来曾经做过合并。
在实际开发中,我们应该按照⼏个基本原则进⾏分⽀管理:
⾸先,master分⽀应该是⾮常稳定的,也就是仅⽤来发布新版本,平时不能在上⾯⼲活;
那在哪⼲活呢?⼲活都在dev分⽀上,也就是说,dev分⽀是不稳定的,到某个时候,⽐如1.0版本发布时,再把dev分⽀合并到master上,在master分⽀发布1.0版本;
你和你的⼩伙伴们每个⼈都在dev分⽀上⼲活,每个⼈都有⾃⼰的分⽀,时不时地往dev分⽀上合并就可以了。
假如我们现在正在dev2 分⽀上进⾏开发,开发到⼀半,突然发现 master 分⽀上⾯有bug,需要解决。在Git中,每个bug都可以通过⼀个新的临时分⽀来修复,修复后,合并分⽀,然后将临时分⽀删除。
可现在dev2的代码在⼯作区中开发了⼀半,还⽆法提交,怎么办?
[zl@VM-16-2-centos lesson]$ git branch -d dev1 Deleted branch dev1 (was 3dc0539). [zl@VM-16-2-centos lesson]$ git checkout dev2 Switched to branch 'dev2' [zl@VM-16-2-centos lesson]$ vim readme [zl@VM-16-2-centos lesson]$ git checkout master M readme Switched to branch 'master' [zl@VM-16-2-centos lesson]$ cat readme hello world bbb on dev branch abcde abc i am coding [zl@VM-16-2-centos lesson]$ git status # On branch master # 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 # no changes added to commit (use "git add" and/or "git commit -a")
Git提供了 git stash 命令,可以将当前的⼯作区信息进⾏储藏,被储藏的内容可以在将来某个时间恢复出来。
[zl@VM-16-2-centos lesson]$ git checkout dev2
M readme
Switched to branch 'dev2'
[zl@VM-16-2-centos lesson]$ git stash
Saved working directory and index state WIP on dev2: 930c91c md readme
HEAD is now at 930c91c md readme
⽤ git status 查看⼯作区,就是⼲净的(除⾮有没有被Git管理的⽂件),因此可以放⼼地创建分⽀来修复bug。
储藏 dev2 ⼯作区之后,由于我们要基于master分⽀修复bug,所以需要切回 master 分⽀,再新建临时分⽀来修复bug,⽰例如下:
[zl@VM-16-2-centos lesson]$ git checkout master
Switched to branch 'master'
[zl@VM-16-2-centos lesson]$ git checkout -b fix_bug
Switched to a new branch 'fix_bug'
[zl@VM-16-2-centos lesson]$ vim readme
[zl@VM-16-2-centos lesson]$ git add .
[zl@VM-16-2-centos lesson]$ git commits -m "fix bug:f"
git: 'commits' is not a git command. See 'git --help'.
Did you mean this?
commit
[zl@VM-16-2-centos lesson]$ git commit -m "fix bug:f"
[fix_bug 94c04ee] fix bug:f
1 file changed, 1 insertion(+), 1 deletion(-)
修复完成后,切换到 master 分⽀,并完成合并,最后删除 fix_bug 分⽀:
[zl@VM-16-2-centos lesson]$ git checkout master
Switched to branch 'master'
[zl@VM-16-2-centos lesson]$ git merge --no-ff -m "merge fix_bug" fix_bug
Merge made by the 'recursive' strategy.
readme | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
[zl@VM-16-2-centos lesson]$ git status
# On branch master
nothing to commit, working directory clean
[zl@VM-16-2-centos lesson]$ cat readme
hello world
bbb on dev branch
abcde
abcdef
⾄此,bug的修复⼯作已经做完了,我们还要继续回到dev2分⽀进⾏开发。切换回 dev2 分⽀:
[zl@VM-16-2-centos lesson]$ git checkout dev2
Switched to branch 'dev2'
⼯作区是⼲净的,刚才的⼯作现场存到哪去了?⽤ git stash list 命令看看:
[zl@VM-16-2-centos lesson]$ git stash list
stash@{0}: WIP on dev2: 930c91c md readme
⼯作现场还在,Git把stash内容存在某个地⽅了,但是需要恢复⼀下,如何恢复现场呢?我们可以使⽤ git stash pop 命令,恢复的同时会把stash也删了,⽰例如下:
[zl@VM-16-2-centos lesson]$ git stash pop
# On branch dev2
# 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
#
no changes added to commit (use "git add" and/or "git commit -a")
Dropped refs/stash@{0} (258adcb6cbf0227607699fa772e6c37cf78c1900)
再次查看的时候,我们已经发现已经没有现场可以恢复了
另外,恢复现场也可以采⽤ git stash apply 恢复,但是恢复后,stash内容并不删除,你需要⽤ git stash drop 来删除;
你可以多次stash,恢复的时候,先⽤ git stash list 查看,然后恢复指定的stash,⽤命令git stash apply stash@{0} ,这部分请同学们⾃⾏使⽤。
恢复完代码之后我们便可以继续完成开发,开发完成后便可以进⾏提交,例如:
[zl@VM-16-2-centos lesson]$ cat readme hello world bbb on dev branch abcde abc i am coding [zl@VM-16-2-centos lesson]$ vim readme [zl@VM-16-2-centos lesson]$ git add . [zl@VM-16-2-centos lesson]$ git commit -m "md readme:done" [dev2 2cdac41] md readme:done 1 file changed, 1 insertion(+) [zl@VM-16-2-centos lesson]$ git branch * dev2 fix_bug master [zl@VM-16-2-centos lesson]$ git merge --no-ff -m "merge master" master Auto-merging readme CONFLICT (content): Merge conflict in readme Automatic merge failed; fix conflicts and then commit the result.
但我们注意到了,修复bug的内容,并没有在dev2 上显⽰。此时的状态图为:
Master 分⽀⽬前最新的提交,是要领先于新建 dev2 时基于的 master 分⽀的提交的,所以我们在 dev2 中当然看不⻅修复bug的相关代码。
我们的最终⽬的是要让 master 合并 dev2 分⽀的,那么正常情况下我们切回 master 分⽀直接合并即可,但这样其实是有⼀定⻛险的。
是因为在合并分⽀时可能会有冲突,⽽代码冲突需要我们⼿动解决(在 master 上解决)。我们⽆法保证对于冲突问题可以正确地⼀次性解决掉,因为在实际的项⽬中,代码冲突不只⼀两⾏那么简单,有可能⼏⼗上百⾏,甚⾄更多,解决的过程中难免⼿误出错,导致错误的代码被合并到 master 上。此时的状态为:
解决这个问题的⼀个好的建议就是:最好在⾃⼰的分⽀上合并下 master ,再让 master 去合并dev ,这样做的⽬的是有冲突可以在本地分⽀解决并进⾏测试,⽽不影响 master 。此时的状态为:
对应的实操演⽰如下,要说明的是,以下演⽰的merge操作,没有使⽤ --no-ff ,但上述的图⽰是禁⽤ Fast forward了模式后得出的,主要是为了⽅便解释问题。
[zl@VM-16-2-centos lesson]$ vim readme [zl@VM-16-2-centos lesson]$ git add . [zl@VM-16-2-centos lesson]$ git commit -m "merge master fix" [dev2 0cea538] merge master fix [zl@VM-16-2-centos lesson]$ git checkout master Switched to branch 'master' [zl@VM-16-2-centos lesson]$ git merge --no-ff -m "merge dev2" dev2 Merge made by the 'recursive' strategy. readme | 2 ++ 1 file changed, 2 insertions(+) [zl@VM-16-2-centos lesson]$ cat readme hello world bbb on dev branch abcde i am coding...done abcdef [zl@VM-16-2-centos lesson]$ git branch dev2 fix_bug * master [zl@VM-16-2-centos lesson]$ git branch -d fix_bug Deleted branch fix_bug (was 94c04ee). [zl@VM-16-2-centos lesson]$ git branch -d dev2 Deleted branch dev2 (was 0cea538).
添加⼀个新功能时,你肯定不希望因为⼀些实验性质的代码,把主分⽀搞乱了,所以,每添加⼀个新功能,最好新建⼀个分⽀,我们可以将其称之为feature分⽀,在上⾯开发,完成后,合并,最后,删除该feature 分⽀。
可是,如果我们今天正在某个feature分⽀上开发了⼀半,被产品经理突然叫停,说是要停⽌新功能的开发。虽然⽩⼲了,但是这个 feature分⽀还是必须就地销毁,留着⽆⽤了。这时使⽤传统的 git branch -d 命令删除分⽀的⽅法是不⾏的。
[zl@VM-16-2-centos lesson]$ git checkout -b dev3
Switched to a new branch 'dev3'
[zl@VM-16-2-centos lesson]$ vim readme
[zl@VM-16-2-centos lesson]$ git add .
[zl@VM-16-2-centos lesson]$ git commit -m "md readme"
[dev3 bb0c00c] md readme
1 file changed, 1 insertion(+)
[zl@VM-16-2-centos lesson]$ git checkout master
Switched to branch 'master'
[zl@VM-16-2-centos lesson]$ git branch -d dev3
error: The branch 'dev3' is not fully merged.
If you are sure you want to delete it, run 'git branch -D dev3'.
直接使⽤传统的删除分⽀的⽅法不⾏,按照提⽰,有了如下⽅式:
[zl@VM-16-2-centos lesson]$ git branch -D dev3
Deleted branch dev3 (was bb0c00c).
[zl@VM-16-2-centos lesson]$ git branch
* master
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。