目录
一、分支概念
在版本回退里,每次提交,git都把它们串成一条时间线,这条时间线可以理解为是一个分支。默认git创建仓库以后,只有一个分支,叫做主分支master。
分支的命名和设计,完全可以由团队创作者自己来管理。
HEAD指针,严格来说不是指向提交,而是指向master,master才是指向提交的。而HEAD指向的分支就是当前分支。
每次提交,master分支都会向前移动一步,这样,随着不断的提交,master分支 线也会越来越长,而HEAD只要一直指向master分支即可指向当前分支。
通过查看版本库,也能发现一些关联:
cpp
1 hyb@139-159-150-152:~/gitcode$ cat .git/HEAD
2 ref: refs/heads/master
3 hyb@139-159-150-152:~/gitcode$ cat .git/refs/heads/master
4 5476bdeb12510f7cd72ac4766db7988925ebd302
二、创建分支
创建新的分支的命名,完全由使用者决定,这里创建新的分支dev。
cpp
1 hyb@139-159-150-152:~/gitcode$ git branch //查看当前本地所有分⽀
2 * master
3 hyb@139-159-150-152:~/gitcode$ git branch dev //新建分⽀dev
4 hyb@139-159-150-152:~/gitcode$ git branch
5 dev
6 * master
当创建新的分支dev后,git新建了一个dev指针,*表示当前HEAD 指向的分支是master分支。
cpp
1 hyb@139-159-150-152:~/gitcode$ ls .git/refs/heads/
2 dev master
3 hyb@139-159-150-152:~/gitcode$ cat .git/refs/heads/*
4 5476bdeb12510f7cd72ac4766db7988925ebd302
5 5476bdeb12510f7cd72ac4766db7988925ebd302
打印结果显示master和dev指向同一个修改提交。
三、切换分支
使用命令git checkout完成分支切换。
cpp
1 hyb@139-159-150-152:~/gitcode$ git checkout dev
2 Switched to branch 'dev'
3 hyb@139-159-150-152:~/gitcode$ git branch
4 * dev
5 master
6 hyb@139-159-150-152:~/gitcode$ cat .git/HEAD
7 ref: refs/heads/dev
当HEAD指向dev分支,表明当前分支已经是dev分支了。
在dev分支下修改ReadMe文件,新增一行内容,并完成提交操作。
cpp
1 hyb@139-159-150-152:~/gitcode$ vim ReadMe
2 hyb@139-159-150-152:~/gitcode$ cat ReadMe
3 hello bit
4 hello git
5 hello world
6 hello version1
7 hello version2
8 hello version3
9 write aaa for new branch//这一行是新增的一行
10 hyb@139-159-150-152:~/gitcode$ git add .
11 hyb@139-159-150-152:~/gitcode$ git commit -m"modify ReadMe"
12 [dev 3740dce] modify ReadMe
13 1 file changed, 1 insertion(+)
现在再切换到master分支,原来在dev分支的提交并不会影响master分支。
cpp
1 hyb@139-159-150-152:~/gitcode$ git checkout master
2 Switched to branch 'master'
3 hyb@139-159-150-152:~/gitcode$ cat ReadMe
4 hello bit
5 hello git
6 hello world
7 hello version1
8 hello version2
9 hello version3
现在来观察一下两个分支最新的提交。
cpp
1 hyb@139-159-150-152:~/gitcode$ cat .git/refs/heads/dev
2 bdaf528ffbb8e05aee34d37685408f0e315e31a4
3 hyb@139-159-150-152:~/gitcode$ cat .git/refs/heads/master
4 5476bdeb12510f7cd72ac4766db7988925ebd302
如果用图来表示,它是下面这个样子的:
四、合并分支
为了在master分支上面能看到新的提交,需要将dev分支的内容合并到master分支上面。git merge命令用于将指定分支合并到当前分支。
cpp
1 hyb@139-159-150-152:~/gitcode$ git branch
2 * dev
3 master
4 hyb@139-159-150-152:~/gitcode$ git checkout master //切换到 master 上进⾏合并
5 Switched to branch 'master'
6 hyb@139-159-150-152:~/gitcode$ git merge dev //合并 dev 分⽀
7 Updating 16623e1..3740dce
8 Fast-forward
9 ReadMe | 1 +
10 1 file changed, 1 insertion(+)
11 hyb@139-159-150-152:~/gitcode$ cat ReadMe
12 hello bit
13 hello git
14 hello world
15 hello version1
16 hello version2
17 hello version3
18 write aaa for new branch
如果用图来表示,它是下面这个样子的:
在执行git merge命令后,显示结果出现了字符串**"Fast-forward",表示快进模式**,实际发生的是直接将master指向当前dev的最新提交,所以合并速度非常快,当然除了Fast-forward模式,还有其他合并模式。
五、删除分支
合并分支完成后,临时创建的dev分支就没有用了,需要删除dev分支,但是,在当前分支下,是不能删除当前分支的,因此,要删除dev 分支,就需要切换到master分支。
cpp
1 hyb@139-159-150-152:~/gitcode$ git checkout master
2 Switched to branch 'master'
3 hyb@139-159-150-152:~/gitcode$ git branch -d dev
4 Deleted branch dev (was bdaf528).
5 hyb@139-159-150-152:~/gitcode$ git branch
6 * master
7
如果用图来表示,它是下面这个样子的:
因为创建、合并、删除分支的速度非常快,因此git提倡使用分支来完成某一个任务,结束后再删掉分支,这和直接在master分支上面开发是一样的,但是过程更安全。
六、合并冲突
在实际合并分支的时候,可能会遇到代码冲突的问题。
为了演示这一问题,现在创建新的分支dev1,并切换到dev1分支下面,可以使用git checkout -b dev1一步完成创建和切换分支的动作。
cpp
1 hyb@139-159-150-152:~/gitcode$ git checkout -b dev1
2 Switched to a new branch 'dev1'
3 hyb@139-159-150-152:~/gitcode$ git branch
4 * dev1
5 master
在dev1分支下面修改ReadMe文件,并进行一次提交。
cpp
1 hyb@139-159-150-152:~/gitcode$ cat ReadMe
2 hello bit
3 hello git
4 hello world
5 hello version1
6 hello version2
7 hello version3
8 write bbb for new branch //将 aaa 该为 bbb,视为dev1对ReadMe的修改
9 hyb@139-159-150-152:~/gitcode$ git add .
10 hyb@139-159-150-152:~/gitcode$ git commit -m"modify ReadMe"
11 [dev1 0854245] modify ReadMe
12 1 file changed, 1 insertion(+), 1 deletion(-)
现在切换到master分支,观察ReadMe文件的内容,由于并没有合并操作,因此master分支下面的ReadMe文件没有发生变化。
cpp
1 hyb@139-159-150-152:~/gitcode$ git checkout master
2 Switched to branch 'master'
3 hyb@139-159-150-152:~/gitcode$ cat ReadMe
4 hello bit
5 hello git
6 hello world
7 hello version1
8 hello version2
9 hello version3
10 write aaa for new branch//master分支下面还是aaa
此时,在master分支下面,对ReadMe文件再做一次修改,并完成提交操作。
cpp
1 hyb@139-159-150-152:~/gitcode$ git branch
2 dev1
3 * master
4 hyb@139-159-150-152:~/gitcode$ vim ReadMe
5 hyb@139-159-150-152:~/gitcode$ cat ReadMe
6 hello bit
7 hello git
8 hello world
9 hello version1
10 hello version2
11 hello version3
12 write ccc for new branch //master分支将aaa修改为ccc
13 hyb@139-159-150-152:~/gitcode$ git add .
14 hyb@139-159-150-152:~/gitcode$ git commit -m"modify ReadMe"
15 [master c10f6d0] modify ReadMe
16 1 file changed, 1 insertion(+), 1 deletion(-)
现在,master分支和dev1分支都有了新的提交,如果用图来表示,它是下面这个样子的:
这种情况下,git会试图将每个分支的修改合并起来,但是可能造成合并冲突。
cpp
1 hyb@139-159-150-152:~/gitcode$ git merge dev1
2 Auto-merging ReadMe
3 CONFLICT (content): Merge conflict in ReadMe
4 Automatic merge failed; fix conflicts and then commit the result.
5 hyb@139-159-150-152:~/gitcode$ git status
6 On branch master
7 You have unmerged paths.
8 (fix conflicts and run "git commit")
9 (use "git merge --abort" to abort the merge)
10
11 Unmerged paths:
12 (use "git add <file>..." to mark resolution)
13 both modified: ReadMe
14
15 no changes added to commit (use "git add" and/or "git commit -a")
合并的结果告诉我们,ReadMe文件存在冲突,此时打印ReadMe文件,git会使用<<<<<<<<<、==========、>>>>>>>>>>来标记出不同分支的冲突内容。
cpp
1 hyb@139-159-150-152:~/gitcode$ cat ReadMe
2 hello bit
3 hello git
4 hello world
5 hello version1
6 hello version2
7 hello version3
8 <<<<<<< HEAD
9 write ccc for new branch
10 =======
11 write bbb for new branch
12 >>>>>>> dev1
此时,我们必须要手动修改冲突的代码,并且再次完成提交操作,一定要再次提交!!!
cpp
1 hyb@139-159-150-152:~/gitcode$ cat ReadMe
2 hello bit
3 hello git
4 hello world
5 hello version1
6 hello version2
7 hello version3
8 write bbb for new branch
9 hyb@139-159-150-152:~/gitcode$ git add .
10 hyb@139-159-150-152:~/gitcode$ git commit -m"merge ReadMe"
11 [master 2976afc] merge ReadMe
如果用图来表示,它是下面这个样子的:
执行带特定参数的git log也可以看到合并冲突的情况。
cpp
1 hyb@139-159-150-152:~/gitcode$ git log --graph --pretty=oneline --abbrev-commit
2 * 2976afc (HEAD -> master) merge ReadMe
3 |\
4 | * c594fd1 (dev1) modify ReadMe
5 * | c10f6d0 modify ReadMe
6 |/
七、分支管理策略
合并分支时,git默认使用Fast-forward模式,使用Fast-forward模式合并的结果如下图所示:
这种合并模式下,master分支不会有新的提交,仅仅是将master指向dev的最新提交,因此速度也比较快,但是如果在当前这种情况删除dev分支,再查看分支历史时,会丢掉分支信息,看不出来最新的提交是merge进来的还是分支提交进来的。
在之前解决合并冲突时,master分支多了一次提交,如果用图来表示,就是下面这个样子:
可以看到,这种合并模式下,master多了一次提交,并不是直接指向dev 的最新提交,那么这就不是Fast-forward模式了,这种合并模式有一个优点,就是即使在删除dev分支后,也能通过查看分支历史看出来最新一次提交是合并而来,而不是master直接提交而来。
cpp
1 hyb@139-159-150-152:~/gitcode$ git log --graph --pretty=oneline --abbrev-commit
2 * 2976afc (HEAD -> master) merge ReadMe
3 |\
4 | * c594fd1 modify ReadMe
5 * | c10f6d0 modify ReadMe
6 |/
7
因此,git也支持我们禁用Fast-forward模式。在非Fast-forward合并模式下,合并时会多一次提交commit,这样就可以在分支历史上看出提交信息。
下面,对这种合并模式作演示。首先,创建新的分支dev2并切换到该分支。
cpp
1 hyb@139-159-150-152:~/gitcode$ git checkout -b dev2
2 Switched to a new branch 'dev2'
修改ReadMe文件,并做一次提交。
cpp
1 hyb@139-159-150-152:~/gitcode$ cat ReadMe
2 hello bit
3 hello git
4 hello world
5 hello version1
6 hello version2
7 hello version3
8 write bbb for new branch
9 a,b,c,d//这一行是修改的内容
10 hyb@139-159-150-152:~/gitcode$ git add .
11 hyb@139-159-150-152:~/gitcode$ git commit -m"modify ReadMe"
12 [dev2 41b082f] modify ReadMe
13 1 file changed, 1 insertion(+)
切回master分支,并且合并dev2分支的提交。
cpp
1 hyb@139-159-150-152:~/gitcode$ git checkout master
2 Switched to branch 'master'
3 hyb@139-159-150-152:~/gitcode$ git merge --no-ff -m "merge with no-ff" dev2
4 Merge made by the 'recursive' strategy.
5 ReadMe | 1 +
6 1 file changed, 1 insertion(+)
7 hyb@139-159-150-152:~/gitcode$ cat ReadMe
8 hello bit
9 hello git
10 hello world
11 hello version1
12 hello version2
13 hello version3
14 write bbb for new branch
15 a,b,c,d
16
请注意,参数--no-ff,表示禁用Fast-forward模式,禁用Fast-forward表示会做一次新的提交,因此,使用**-m参数**作提交描述。
合并后,查看分支历史。
cpp
1 hyb@139-159-150-152:~/gitcode$ git log --graph --pretty=oneline --abbrev-commit
2 * 5bd16b4 (HEAD -> master) merge with no-ff
3 |\
4 | * 41b082f (dev2) modify ReadMe
5 |/
如果用图来表示,它是下面这个样子的:
所以,在合并分支时,我们尽量使用**--no-ff模式,合并后,分支历史会显示合并详情,能看出来曾经做过合并,而使用Fast-forward**模式就看不出来。
八、分支策略
在实际企业级开发中,我们按照下面几个原则进行分支管理:
- 首先,master分支是非常稳定的,仅仅用来发布新版本,平时的开发工作都在其他分支。
- 一般的开发工作都在dev分支上面进行,dev分支是不稳定的,发布测试版本,dev版本经过大量测试后,如果这个测试版本是稳定可靠的,再将dev分支合并到master分支上面,在master分支上面发布稳定的版本。
- 团队中的每个人都有自己的分支,进行自己的任务开发,在某一个约定的时间,将自己开发的内容合并到dev分支上面。
如果用图来表示,就是下面这个样子的:
九、bug分支
假如我们当前正在dev2分支进行开发,开发到一半,即已经书写了部分有效代码,此时,主分支master出现了bug,那么现在的主要任务就是修复bug。
但是dev2分支的代码在工作区的开发程度还不能提交,要怎么办。
git提供了git stash命令,用来将当前的工作区的代码进行临时储存。
cpp
1 hyb@139-159-150-152:~/gitcode$ git stash
2 Saved working directory and index state WIP on dev2: 41b082f modify ReadMe
3 hyb@139-159-150-152:~/gitcode$ git status
4 On branch dev2
5 nothing to commit, working tree clean
执行git stash后,dev2分支上工作区的代码得以保存。
修复bug是基于master分支的,因此要切回master再新建临时分支来修复bug。
cpp
1 hyb@139-159-150-152:~/gitcode$ git checkout master //切回master
2 Switched to branch 'master'
3 hyb@139-159-150-152:~/gitcode$ git checkout -b fix_bug //新建并切换到 fix_bug 分⽀
4 Switched to a new branch 'fix_bug'
5 hyb@139-159-150-152:~/gitcode$ vim ReadMe
6 hyb@139-159-150-152:~/gitcode$ cat ReadMe
7 hello bit
8 hello git
9 hello world
10 hello version1
11 hello version2
12 hello version3
13 write bbb for new branch
14 a,b,c,d,e //修复bug,假如bug是忘记写e
15 hyb@139-159-150-152:~/gitcode$ git add ReadMe // 重新add,commit
16 hyb@139-159-150-152:~/gitcode$ git commit -m"fix bug"
17 [fix_bug 4bbc0c4] fix bug
18 1 file changed, 1 insertion(+),
修复bug后,切回master分支,合并该分支到master分支,并且删除这个临时分支。
cpp
1 hyb@139-159-150-152:~/gitcode$ git checkout master
2 Switched to branch 'master'
3 hyb@139-159-150-152:~/gitcode$ git merge --no-ff -m"merge fix_bug branch" fix_bu
4 Merge made by the 'recursive' strategy.
5 ReadMe | 2 +-
6 1 file changed, 1 insertion(+), 1 deletion(-)
7 hyb@139-159-150-152:~/gitcode$ cat ReadMe
8 hello bit
9 hello git
10 hello world
11 hello version1
12 hello version2
13 hello version3
14 write bbb for new branch
15 a,b,c,d,e
16 hyb@139-159-150-152:~/gitcode$ git branch -d fix_bug
17 Deleted branch fix_bug (was 4bbc0c4).
至此,修复bug的工作已经完成,我们切回dev2继续我们的开发工作。
cpp
1 hyb@139-159-150-152:~/gitcode$ git checkout dev2
2 Switched to branch 'dev2'
3 hyb@139-159-150-152:~/gitcode$ git status
4 On branch dev2
5 nothing to commit, working tree clean
执行git status命令可以发现工作区没有修改,是因为我们将代码进行了保存。可以执行git stash list进行查看是否有被保存的代码。
cpp
1 hyb@139-159-150-152:~/gitcode$ git stash list
2 stash@{0}: WIP on dev2: 41b082f modify ReadMe
现在要将原来的开发到一半的状态进行恢复**,执行git stash pop**。
cpp
1 hyb@139-159-150-152:~/gitcode$ git stash pop
2 On branch dev2
3 Changes not staged for commit:
4 (use "git add <file>..." to update what will be committed)
5 (use "git restore <file>..." to discard changes in working directory)
6 modified: ReadMe
7
8 no changes added to commit (use "git add" and/or "git commit -a")
9 Dropped refs/stash@{0} (4f873250b3503687b5efd26196776aee7e3724c2)
需要注意的是,执行git stash pop后,被保存的现场也会被删除。如果你想恢复现场的同时继续保存现场,可以执行git stash apply命令。如果再要删除现场,可以执行git stash drop命令。
如果多次使用stash保存多个现场,在恢复时想要指定 恢复某一个现场,可以执行git stash **apply stash@{0/1/2···}**来达到要求。
恢复现场后,继续完成dev2分支上面的开发工作。
cpp
1 hyb@139-159-150-152:~/gitcode$ cat ReadMe
2 hello bit
3 hello git
4 hello world
5 hello version1
6 hello version2
7 hello version3
8 write bbb for new branch
9 a,b,c,d//dev2分支没有修复bug
10 i am coding ... Done!//假设我们已经完成了,然后add、commit
11 hyb@139-159-150-152:~/gitcode$ git add .
12 hyb@139-159-150-152:~/gitcode$ git commit -m"modify ReadMe"
13 [dev2 ed0916d] modify ReadMe
14 1 file changed, 1 insertion(+)
结果表明,我们在master分支上修复的bug并没有在dev2分支上面也修复,这是正常的,如果用图来表示,它是下面这个样子的:
我们最终要在master分支上面合并dev2分支,但是如果在这种情况下合并可能会造成合并冲突发生,这就会影响master分支的稳定性。
为了避免这样的问题发生,我们实际是在自己的分支去合并master分支,如果出现合并冲突,也可以很容易的解决而不影响master分支,然后再让master分支合并dev分支。如果用图来表示,它是下面这个样子的:
十、强制删除分支
软件开发中,总是有无穷无尽的功能要添加进来。
添加一个新功能时,为了不让实验性的代码干扰稳定的主分支代码,要创建出许许多多的临时分支。
假设现在正在feature分支上面开发功能,但是,产品经理突然通知这个功能不需要了,因此,feature分支必须尽快的销毁掉。
此时我们的开发内容不需要合并到主分支上面,如果切到主分支再删除这个分支,执行git branch -d是无法完成要求的。
因为git会认为你当前的开发工作正在进行,没有做合并操作,所以对该分支加以保护。
cpp
1 //新增并切换到 dev3 分⽀
2 hyb@139-159-150-152:~/gitcode$ git checkout -b dev3
3 Switched to a new branch 'dev3'
4
5 //开始开发新功能并提交
6 hyb@139-159-150-152:~/gitcode$ vim ReadMe
7 hyb@139-159-150-152:~/gitcode$ cat ReadMe
8 hello bit
9 hello git
10 hello world
11 hello version1
12 hello version2
13 hello version3
14 write bbb for new branch
15 a,b,c,d,e
16 i am coding ... Done!
17 i am writing new features ...
18 hyb@139-159-150-152:~/gitcode$ git add .
19 hyb@139-159-150-152:~/gitcode$ git commit -m"modify ReadMe for new features"
20 [dev3 cd2f149] modify ReadMe for new features
21 1 file changed, 1 insertion(+)
22
23 //此时新功能叫停
24
25 //切回master准备删除dev3
26 hyb@139-159-150-152:~/gitcode$ git checkout master
27 Switched to branch 'master'
28
29 //常规删除dev3分⽀时失败
30 hyb@139-159-150-152:~/gitcode$ git branch -d dev3
31 error: The branch 'dev3' is not fully merged.
32 If you are sure you want to delete it, run 'git branch -D dev3'.
按照提升,执行git branch -D强制删除分支。
cpp
1 hyb@139-159-150-152:~/gitcode$ git branch -D dev3
2 Deleted branch dev3 (was cd2f149).
3 hyb@139-159-150-152:~/gitcode$ git branch
4 * master