git：分支管理

目录

一、分支概念

二、创建分支

 三、切换分支

四、合并分支

五、删除分支

六、合并冲突

 七、分支管理策略

八、分支策略

九、bug分支

十、强制删除分支

一、分支概念

        在版本回退里，每次提交，git都把它们串成一条时间线，这条时间线可以理解为是一个分支。默认git创建仓库以后，只有一个分支，叫做主分支master。

        分支的命名和设计，完全可以由团队创作者自己来管理。

        HEAD指针，严格来说不是指向提交，而是指向master，master才是指向提交的。而HEAD指向的分支就是当前分支。

        每次提交，master分支都会向前移动一步，这样，随着不断的提交，master分支线也会越来越长，而HEAD只要一直指向master分支即可指向当前分支。

        通过查看版本库，也能发现一些关联：

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。

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分支。

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完成分支切换。

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文件，新增一行内容，并完成提交操作。

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分支。

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

        现在来观察一下两个分支最新的提交。

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命令用于将指定分支合并到当前分支。

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分支。

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一步完成创建和切换分支的动作。

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文件，并进行一次提交。

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文件没有发生变化。

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文件再做一次修改，并完成提交操作。

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会试图将每个分支的修改合并起来，但是可能造成合并冲突。

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会使用<<<<<<<<<、==========、>>>>>>>>>>来标记出不同分支的冲突内容。

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

        此时，我们必须要手动修改冲突的代码，并且再次完成提交操作，一定要再次提交！！！

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也可以看到合并冲突的情况。

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直接提交而来。

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并切换到该分支。

1 hyb@139-159-150-152:~/gitcode$ git checkout -b dev2
2 Switched to a new branch 'dev2'

        修改ReadMe文件，并做一次提交。

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分支的提交。

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参数作提交描述。

        合并后，查看分支历史。

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命令，用来将当前的工作区的代码进行临时储存。

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。

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分支，并且删除这个临时分支。

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继续我们的开发工作。

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进行查看是否有被保存的代码。

1 hyb@139-159-150-152:~/gitcode$ git stash list
2 stash@{0}: WIP on dev2: 41b082f modify ReadMe

        现在要将原来的开发到一半的状态进行恢复，执行git stash pop。

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分支上面的开发工作。

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会认为你当前的开发工作正在进行，没有做合并操作，所以对该分支加以保护。

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强制删除分支。

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