devbox
不正经
这个屌丝很懒，什么也没留下！
关注作者
热门标签
热门文章
当前位置:   article > 正文

【Git原理与使用】-- 分支管理_git分支

作者：不正经 | 2024-04-13 03:42:39

赞

踩

git分支

目录

理解分支

创建分支

查看当前分支

创建本地分支

切换分支

合并分支

删除分支

合并冲突

分支管理策略

分支策略 

bug 分支

不建议的合并方式

建议的合并方式

第一步

第二步

删除临时分支

理解分支

        分支就是科幻电影里面的平行宇宙，当你正在电脑前努力学习 C++ 的时候，另⼀个你正在另⼀个平行宇宙里努力学习 JAVA。如果两个平行宇宙互不干扰，那对现在的你也没啥影响。不过，在某个时间点，两个平行宇宙合并了，结果：你既学会了 C++ 又学会了 JAVA！

回顾：在讲解工作区、暂存区、版本库的概念的时候有所提到，在版本库中是有一个HEAD指针，其是指向了一个 master 分支。 

  1. [qcr@ecs-205826 project]$ cat .git/HEAD 
  2. ref: refs/heads/master

  1. [qcr@ecs-205826 project]$ cat .git/refs/heads/master 
  2. dccd2a4405215cffcf40a12308449e27b1e58ea0

        master里面存储的就是我们的最新的一次提交，而最新的一次提交对应的就是commit id，对应的就是对象库中的一个对象的索引，我们可以适应 log 命令进行查看。

  1. [qcr@ecs-205826 project]$ git log --pretty=oneline
  2. dccd2a4405215cffcf40a12308449e27b1e58ea0 删除test3
  3. 1bba34a04f231d8ad49f3ce5079879144cf6f4db 临时空文件
  4. 8f2b55aca176fb578cf39952f776c3da9aa50009 新增一行
  5. e797df72c0669a2b81339ff4854328126d2e6c8e 一行你好，用于学习git
  6. [qcr@ecs-205826 project]$
        在版本回退里，每次提交，Git都把它们串成⼀条时间线，这条时间线就可以理解为是一个分⽀。截止到目前，只有⼀条时间线，在Git里，这个分⽀叫主分⽀，即 master 分⽀。 再来理解⼀下HEAD，HEAD 严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD 指向的就是当前分支。

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

创建分支

        Git 支持持我们查看或创建其他分支，在这⾥我们来创建第⼀个自己的分支 dev ，对应的命令为：

查看当前分支

        查看当前本地所有分支 branch。

  1. [qcr@ecs-205826 project]$ git branch
  2. * master

        其实在我们创建本地仓库的时候，git会为我们自动创建出来一个master主分支，所以此处只有一个master分支，而前面有一个*号，就是因为master前面存在一个HEAD指针。HEAD是不止可以指向master分支，还可以指向其他的任意分支的，而被HEAD指向的分支其实才是当前的工作分支。所以master前面有一个*号，其实是因为当前我们正在master上工作。

创建本地分支

        创建本地分支 dev。

  1. [qcr@ecs-205826 project]$ git branch dev
  2. [qcr@ecs-205826 project]$ git branch
  3.   dev
  4. * master

        通过*号我们可以知道，HEAD 指针还是指向 master 分支的，可以通过查看验证：

  1. [qcr@ecs-205826 project]$ cat .git/HEAD
  2. ref: refs/heads/master

        这个时候通过 tree 命令查看 .git 可以发现：
 

         以前只有一个 master ，而这一次多了一个 dev ，通过查看 dev 内的内容可以发现：

  1. [qcr@ecs-205826 project]$ cat .git/refs/heads/dev 
  2. dccd2a4405215cffcf40a12308449e27b1e58ea0
  3. [qcr@ecs-205826 project]$ cat .git/refs/heads/master
  4. dccd2a4405215cffcf40a12308449e27b1e58ea0

        其里面也是一个 commit id ，并且其里面放的内容与 master 里面放的内容是一摸一样的，指向的是最新的一次提交。

         原因就是因为：我们创建 dev 分支的时候，是基于最新的一次的提交创建出来的，即我们在git branch dev 的时候是站在当前最新的一个版本上去创建的。

切换分支

        如果想在对应的分支下进行操作，即切换到 dev 分支下进行开发，使用 git checkout 命令即可完成切换。

  1. [qcr@ecs-205826 project]$ git checkout dev
  2. Switched to branch 'dev'
  3. [qcr@ecs-205826 project]$ git branch
  4. * dev
  5.   master

        我们发现 HEAD 已经指向了 dev，就表示我们已经成功的切换到了 dev 上了。接下来，在 dev 分支 下修改 ReadMe 文件，新增一行内容，并进行一次提交操作。 
  1. [qcr@ecs-205826 project]$ cat test.txt 
  2. 你好
  3. hello
  4. on dev branch

        然后进行提交。

  1. [qcr@ecs-205826 project]$ git add test.txt 
  2. [qcr@ecs-205826 project]$ git commit -m "新增一行"
  3. [dev d9412c1] 新增一行
  4.  1 file changed, 1 insertion(+)

        这个时候再切回 master 分支，进行查看我们在 dev 分支下进行修改并提交的 test.txt 文件。

  1. [qcr@ecs-205826 project]$ git checkout master
  2. Switched to branch 'master'
  3. [qcr@ecs-205826 project]$ git branch
  4.   dev
  5. * master
  6. [qcr@ecs-205826 project]$ cat test.txt 
  7. 你好
  8. hello

        可以发现在 dev 上的修改并没有在 master 上体现出来。并且这个时候我们再打印 dev 里面的内容，可以发现发生了改变。

  1. [qcr@ecs-205826 project]$ cat .git/refs/heads/dev 
  2. d9412c152d40b391d55c01a75e60d99f78ef45cf

        也就是说 dev 分支其实也是每一次提交，对应进行一次的更新的，我们可以查看此处 dev 中更新的 commit id 的 parent 是什么。

  1. [qcr@ecs-205826 project]$ git cat-file -p d9412c152d40b391d55c01a75e60d99f78ef45cf
  2. tree c7375ebb32b60c3e84d5b0f78b2cb6817060de54
  3. parent dccd2a4405215cffcf40a12308449e27b1e58ea0
  4. author qcr <2390139574@qq.com> 1688126065 +0800
  5. committer qcr <2390139574@qq.com> 1688126065 +0800
  6.  
  7. 新增一行

         可以发现，是创建完 dev 分支的时候里面保存的内容。也就是说我们在 dev 分支上，实现了一次的提交，实际上是进行了：

        所以，当切换到 master 分⽀之时，HEAD 就指向了 master，当然看不到提交了。

合并分支

        为了在 master 主分⽀上能看到新的提交，就需要将 dev 分⽀合并到 master 分⽀，合并后，master 就能看到 dev 分支提交的内容了，首先如果是想让 master 分支来合并 dev 分支，必须要先切到 master 分支上。

  1. [qcr@ecs-205826 project]$ git branch
  2.   dev
  3. * master
  4. [qcr@ecs-205826 project]$ git merge dev
  5. Updating dccd2a4..d9412c1
  6. Fast-forward
  7.  test.txt | 1 +
  8.  1 file changed, 1 insertion(+)

        这个时候我们再查看 test.txt 文件，可以发现 master 分支下的文件确实发生了改变。

  1. [qcr@ecs-205826 project]$ git branch
  2.   dev
  3. * master
  4. [qcr@ecs-205826 project]$ cat test.txt 
  5. 你好
  6. hello
  7. on dev branch

        并且 master 中存的 commit id 也变为了 dev 中的最新提交。

  1. [qcr@ecs-205826 project]$ cat .git/refs/heads/master 
  2. d9412c152d40b391d55c01a75e60d99f78ef45cf
  3. [qcr@ecs-205826 project]$ cat .git/refs/heads/dev 
  4. d9412c152d40b391d55c01a75e60d99f78ef45cf

        这个时候再回头看一看在 master 分支中合并 dev 分支的命令。

        Fast-forward 代表 “ 快进模式 ” ，也就是直接把 master 指向 dev 的当前提交，所以合并速度非常快。

Note：当然，也不是每次合并都能 Fast-forward，我们后⾯会讲其他方式的合并。

删除分支

        合并完成后，dev 分支对于我们来说就没用了，因为 dev 分支所需要达到的目标已经做到了，并且已经将结果交付给了 master 主分支，那么 dev 分支就需要被删除掉（荒废的分支会占用一定的资源，并且不利于管理）。

Note：如果当前正处于某分支下，就不能删除当前分⽀。

  1. [qcr@ecs-205826 project]$ git branch
  2. * dev
  3.   master
  4. [qcr@ecs-205826 project]$ git branch -d dev
  5. error: Cannot delete the branch 'dev' which you are currently on.
  1. [qcr@ecs-205826 project]$ git branch
  2.   dev
  3. * master
  4. [qcr@ecs-205826 project]$ git branch -d dev
  5. Deleted branch dev (was d9412c1).
  6. [qcr@ecs-205826 project]$ git branch
  7. * master

        此时的状态如图如下所示。 

        因为创建、合并和删除分支非常快，所以 Git 鼓励你使用分支完成某个任务，合并后再删掉分支，这和直接在 master 分支上工作效果是⼀样的，但过程更安全。

合并冲突

        可是，在实际分支合并的时候，并不是想合并就能合并成功的，有时候可能会遇到代码冲突的问题。为了演示这问题，创建⼀个新的分支 dev ，并切换至目标分支。

Note：我们可以使用 git checkout -b dev ⼀步完成创建并切换的动作。

        大致操作流程：

  1. [qcr@ecs-205826 project]$ git checkout -b dev
  2. Switched to a new branch 'dev'
  3. [qcr@ecs-205826 project]$ vim test.txt 
  4. [qcr@ecs-205826 project]$ git add test.txt 
  5. [qcr@ecs-205826 project]$ git commit -m "最后一行添加5个a"
  6. [dev 0bd9eb1] 最后一行添加5个a
  7.  1 file changed, 1 insertion(+), 1 deletion(-)
  8. [qcr@ecs-205826 project]$ git checkout master
  9. Switched to branch 'master'
  10. [qcr@ecs-205826 project]$ vim test.txt 
  11. [qcr@ecs-205826 project]$ git add test.txt 
  12. [qcr@ecs-205826 project]$ git commit -m "最后一行添加5个b"
  13. [master 88dbe15] 最后一行添加5个b
  14.  1 file changed, 1 insertion(+), 1 deletion(-)

        于是我就得到了如下关系的两个分支。

        这个时候本地的仓库就如下图类似：

         这种情况下， Git 只能试图把各自的修改合并起来，但这种合并就可能会有冲突。 
  1. [qcr@ecs-205826 project]$ git branch
  2.   dev
  3. * master
  4. [qcr@ecs-205826 project]$ git merge dev
  5. Auto-merging test.txt
  6. CONFLICT (content): Merge conflict in test.txt
  7. Automatic merge failed; fix conflicts and then commit the result.
        发现 test.txt 文件有冲突后，可以直接查看⽂件内容，要说的是 Git 会⽤ <<<<<<<、=======、>>>>>>> 来标记出不同分⽀的冲突内容，如下所示： 
  1. [qcr@ecs-205826 project]$ cat test.txt 
  2. 你好
  3. hello
  4. <<<<<<< HEAD
  5. bbbbb on dev branch
  6. =======
  7. aaaaa on dev branch
  8. >>>>>>> dev

        此时我们必须要手动调整冲突代码，并需要再次提交修正后的结果！ （再次提交很重要，切勿忘记）
        我们需要自行的编写，来决定代码的保留。

        冲突修复完整之后就是对应的，一定需要进行的提交的操作。 

  1. [qcr@ecs-205826 project]$ git add .
  2. [qcr@ecs-205826 project]$ git commit -m "使用dev分支的变动"
  3. [master 937bd7e] 使用dev分支的变动
         到这里冲突就解决完成，此时的状态变成了如下图所示：

        因为我们就是再之前的基础上，进行了又一次的提交。这个时候 master 就指向了最新的一次的提交了，但是 dev 还是执行的它的提交。

  1. [qcr@ecs-205826 project]$ cat .git/refs/heads/master 
  2. 937bd7e54a78557ff84d4d0ab095f635b9b30596
  3.  
  4. [qcr@ecs-205826 project]$ cat .git/refs/heads/dev 
  5. 0bd9eb10a93857eb66698c86d21571715da0477d
  6.  
  7. [qcr@ecs-205826 project]$ git log --pretty=oneline
  8. 937bd7e54a78557ff84d4d0ab095f635b9b30596 使用dev分支的变动
  9. 88dbe15a8c877e05e17a1cbc8a0904ac1510a9d5 最后一行添加5个b
  10. 0bd9eb10a93857eb66698c86d21571715da0477d 最后一行添加5个a
  11. d9412c152d40b391d55c01a75e60d99f78ef45cf 新增一行
  12. dccd2a4405215cffcf40a12308449e27b1e58ea0 删除test3
  13. 1bba34a04f231d8ad49f3ce5079879144cf6f4db 临时空文件
  14. 8f2b55aca176fb578cf39952f776c3da9aa50009 新增一行
  15. e797df72c0669a2b81339ff4854328126d2e6c8e 一行你好，用于学习git
        ⽤带参数的 git log 也可以看到分支的合并情况： 
  1. [qcr@ecs-205826 project]$ git log --graph --abbrev-commit
  2. *   commit 937bd7e
  3. |\  Merge: 88dbe15 0bd9eb1
  4. | | Author: qcr <2390139574@qq.com>
  5. | | Date:   Fri Jun 30 23:09:03 2023 +0800
  6. | | 
  7. | |     使用dev分支的变动
  8. | |   
  9. | * commit 0bd9eb1
  10. | | Author: qcr <2390139574@qq.com>
  11. | | Date:   Fri Jun 30 22:17:49 2023 +0800
  12. | | 
  13. | |     最后一行添加5个a
  14. | |   
  15. * | commit 88dbe15
  16. |/  Author: qcr <2390139574@qq.com>
  17. |   Date:   Fri Jun 30 22:18:45 2023 +0800
  18. |   
  19. |       最后一行添加5个b
  20. |  
  21. * commit d9412c1
  22. | Author: qcr <2390139574@qq.com>
  23. | Date:   Fri Jun 30 19:54:25 2023 +0800
  24. | 
  25. |     新增一行
  26. |  
  27. * commit dccd2a4
  28. | Author: qcr <2390139574@qq.com>
  29. | Date:   Sun Jun 18 20:48:38 2023 +0800
  30. | 
  31. :

        可以发现其左侧就与我们之前画的图一样。

        觉得太杂、太乱，可以再加一个选项，让其一行漂亮干净的显示。

  1. [qcr@ecs-205826 project]$ git log --graph --abbrev-commit --pretty=oneline
  2. *   937bd7e 使用dev分支的变动
  3. |\  
  4. | * 0bd9eb1 最后一行添加5个a
  5. * | 88dbe15 最后一行添加5个b
  6. |/  
  7. * d9412c1 新增一行
  8. * dccd2a4 删除test3
  9. * 1bba34a 临时空文件
  10. * 8f2b55a 新增一行
  11. * e797df7 一行你好，用于学习git
        最后，不要忘记 dev 分支使用完毕后就可以删除了。 
  1. [qcr@ecs-205826 project]$ git branch
  2.   dev
  3. * master
  4. [qcr@ecs-205826 project]$ git branch -d dev
  5. Deleted branch dev (was 0bd9eb1).

分支管理策略

        通常合并分支时，如果可能 Git 会采⽤ Fast forward 模式。如果我们采用 Fast forward 模式之后，形成的合并结果如下图。

        在这种 Fast forward 模式下，删除分支后，查看分支历史时，会丢掉分支信息，看不出来最新提交到底是 merge 进来的还是正常提交的。
        举个例子： 接下来再创建一个分支 dev1 用于实现  Fast forward 模式： 
  1. [qcr@ecs-205826 project]$ git checkout -b dev1
  2. Switched to a new branch 'dev1'
  3. [qcr@ecs-205826 project]$ vim test.txt 
  4. [qcr@ecs-205826 project]$ git add .
  5. [qcr@ecs-205826 project]$ git commit -m "dev1分支下新增一行"
  6. [dev1 93e5bb2] dev1分支下新增一行
  7.  1 file changed, 1 insertion(+)
  8. [qcr@ecs-205826 project]$ git checkout master
  9. Switched to branch 'master'
  10. [qcr@ecs-205826 project]$ git merge dev1
  11. Updating 937bd7e..93e5bb2
  12. Fast-forward
  13.  test.txt | 1 +
  14.  1 file changed, 1 insertion(+)

        接下来再让我们看一看 git log 下的情况（由于此处主要是看线路，所以查看简洁版）。

  1. [qcr@ecs-205826 project]$ git log --graph --abbrev-commit --pretty=oneline
  2. * 93e5bb2 dev1分支下新增一行
  3. *   937bd7e 使用dev分支的变动
  4. |\  
  5. | * 0bd9eb1 最后一行添加5个a
  6. * | 88dbe15 最后一行添加5个b
  7. |/  
  8. * d9412c1 新增一行
  9. * dccd2a4 删除test3
  10. * 1bba34a 临时空文件
  11. * 8f2b55a 新增一行
  12. * e797df7 一行你好，用于学习git

        可以很明显的看出来：Fast forward 模式下，删除分支后，查看分支历史时，会丢掉分支信息，看不出来最新提交到底是 merge 进来的还是正常提交的。

        就算是详细显示也是一个样，但在合并冲突部分，我们也看到通过解决冲突问题，会再进行⼀次新的提交，得到的最终状态为：

        那么这就不是 Fast forward 模式了，这样的好处是，从分支历史上就可以看出分支信息。例如：我们现在已经删除了在合并冲突部分创建的 dev  分支 ，但依旧能看到 master 其实是由其他分支合并得到。
        其实 Git 支持我们强制禁用  Fast forward 模式，那么就会在 merge 时⽣成⼀个新的 commit ，这样从分⽀历史上就可以看出分⽀信息。
         举个例子： 接下来再创建一个分支 dev2 用于实现 强制禁用  Fast forward 模式： 
  1. [qcr@ecs-205826 project]$ git checkout -b dev2 
  2. Switched to a new branch 'dev2'
  3. [qcr@ecs-205826 project]$ vim test.txt 
  4. [qcr@ecs-205826 project]$ git add .
  5. [qcr@ecs-205826 project]$ git commit -m "在dev2分支下新增一行"
  6. [dev2 803a10f] 在dev2分支下新增一行
  7.  1 file changed, 1 insertion(+)
  8. [qcr@ecs-205826 project]$ git checkout master
  9. Switched to branch 'master'
        开始合并。 请注意 --no-ff 参数，表示禁用  Fast forward 模式。禁用  Fast forward 模式后合并会创建⼀个新的 commit ，所以加上 -m 参数，把描述写进去。 
  1. [qcr@ecs-205826 project]$ git merge --no-ff -m "merge dev2" dev2
  2. Merge made by the 'recursive' strategy.
  3.  test.txt | 1 +
  4.  1 file changed, 1 insertion(+)
  5. [qcr@ecs-205826 project]$ cat test.txt
  6. 你好
  7. hello
  8. aaaaa on dev branch
  9. ont dev1 branch
  10. on dev2 branch

        现在再使用 git log 查看可以发现：

  1. [qcr@ecs-205826 project]$ git log --graph --abbrev-commit --pretty=oneline
  2. *   bb787c5 merge dev2
  3. |\  
  4. | * 803a10f 在dev2分支下新增一行
  5. |/  
  6. * 93e5bb2 dev1分支下新增一行
  7. *   937bd7e 使用dev分支的变动
  8. |\  
  9. | * 0bd9eb1 最后一行添加5个a
  10. * | 88dbe15 最后一行添加5个b
  11. |/  
  12. * d9412c1 新增一行
  13. * dccd2a4 删除test3
  14. * 1bba34a 临时空文件
  15. * 8f2b55a 新增一行
  16. * e797df7 一行你好，用于学习git

Note：所以在合并分支时，加上 --no-ff 参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并，而 fast forward 合并就看不出来曾经做过合并。

分支策略 

        在实际开发中，我们应该按照几个基本原则进行分支管理： 首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活，干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本。

        我们和我们的团队每个人都在 dev 分支上干活，每个人都有自己的分⽀，时不时地往dev分支上合并就可以了。 所以，团队合作的分支看起来就像这样：

bug 分支

        假如我们现在正在 dev 分支上进行开发，开发到⼀半，突然发现 master 分支上面有 bug，需要解决。在Git中，每个 bug 都可以通过⼀个新的临时分⽀来修复，修复后，合并分⽀，然后将临时分支删除。 

  1. [qcr@ecs-205826 project]$ git checkout -b dev
  2. Switched to a new branch 'dev'
  3. [qcr@ecs-205826 project]$ vim test.txt 
  4. [qcr@ecs-205826 project]$ cat test.txt 
  5. 你好
  6. hello
  7. aaaaa on dev branch
  8. ont dev1 branch
  9. on dev2 branch
  10. I am coding ……

        这个时候突然遇到了 bug ，我们就需要新建一个分支来进行 bug 的修复，虽然 dev 分支可以用来修复 bug ，但是这违背了开辟 dev 分支的初衷，其是用来开发部分的新需求的，而不是用来解决 bug 的。这个时候就需要切到 master 分支上，然后基于 master 分支进行创建一个新的分支用于解决 bug。

  1. [qcr@ecs-205826 project]$ git checkout master
  2. M	test.txt
  3. Switched to branch 'master'

        这个时候我么可以看到，除了打印切换成功的一行提示之外，还多打印了一行。而大写的M就代表修改（modify），这个时候再让我们查看 master 分支上的 test.txt 会发现其也发生了更改（dev 的内容跑到了 master 上了）。

  1. [qcr@ecs-205826 project]$ git checkout master
  2. M	test.txt
  3. Switched to branch 'master'
  4. [qcr@ecs-205826 project]$ cat test.txt 
  5. 你好
  6. hello
  7. aaaaa on dev branch
  8. ont dev1 branch
  9. on dev2 branch
  10. I am coding ……

        这个时候查看当前状态。

  1. [qcr@ecs-205826 project]$ git status
  2. # On branch master
  3. # Changes not staged for commit:
  4. #   (use "git add <file>..." to update what will be committed)
  5. #   (use "git checkout -- <file>..." to discard changes in working directory)
  6. #
  7. #	modified:   test.txt
  8. #
  9. no changes added to commit (use "git add" and/or "git commit -a")

        可以发现 test.txt 文件只是再工作区中被修改了。虽然没有对我们的仓库进行影响，但是我们并不想在 master 上看到 dev 上的内容。Git 提供了 git stash 命令，可以将当前的工作区信息进行储藏，被储藏的内容可以在将来某个时间恢复出来。

Note：首先要在其对应的分支下。

  1. [qcr@ecs-205826 project]$ git checkout dev
  2. M	test.txt
  3. Switched to branch 'dev'
  4. [qcr@ecs-205826 project]$ git stash
  5. Saved working directory and index state WIP on dev: 920acfc 有bug
  6. HEAD is now at 920acfc 有bug

        通过查看 .git 中对应的文件，可以发现，refs 中多了一个对应的 stash 文件。这个文件里就是临时抱保存的工作区中的代码数据。

        这个时候在查看当前仓库状态，就可以发现工作区是干净的。

  1. [qcr@ecs-205826 project]$ git status
  2. # On branch dev
  3. nothing to commit, working directory clean
  4. [qcr@ecs-205826 project]$ cat test.txt 
  5. 你好
  6. hello
  7. aaaaa on dev branch
  8. ont dev1 branch
  9. on dev2 branch

        而 stash 里面存的其实是已经被 Git 追踪、管理的一些文件，而如果是 touch 一个文件，然后其只是在工作区中新建了，并没有进行 add、commit 操作，其是不属于 Git 追踪、管理的文件。这个时候就是不可以被 git stash 命令，进行储藏：

  1. [qcr@ecs-205826 project]$ touch tmp.txt
  2. [qcr@ecs-205826 project]$ git stash
  3. No local changes to save

        提示为：没有一些变动需要存储。

        当存储起来之后，就可以发现 test.txt 文件里面新增的内容也就没有了。储藏 dev 工作区之后，由于我们要基于 master 分支修复 bug，所以需要切回 master 分支，再新建临时分支来修复 bug。

  1. [qcr@ecs-205826 project]$ git checkout -b fit_bug
  2. Switched to a new branch 'fit_bug'
  3. [qcr@ecs-205826 project]$ cat test.txt 
  4. 你好
  5. hello
  6. aaaaa on dev branch
  7. ont dev1 branch
  8. on dev2 branch
  9. [qcr@ecs-205826 project]$ vim test.txt 
  10. [qcr@ecs-205826 project]$ cat test.txt 
  11. 你好
  12. hello
  13. aaaaa on dev branch
  14. aaaaa on dev1 branch
  15. aaaaa on dev2 branch
  16. [qcr@ecs-205826 project]$ git add . 
  17. [qcr@ecs-205826 project]$ git commit -m "修复内容不完整的bug"
  18. [fit_bug 171cefc] 修复内容不完整的bug
  19.  1 file changed, 2 insertions(+), 2 deletions(-)

        修复完成后，切换到 master 分支，并完成合并，最后删除 fix_bug 分支。

  1. [qcr@ecs-205826 project]$ git checkout master
  2. Switched to branch 'master'
  3. [qcr@ecs-205826 project]$ git merge --no-ff -m "merge fit_bug" fit_bug
  4. Merge made by the 'recursive' strategy.
  5.  test.txt | 4 ++--
  6.  1 file changed, 2 insertions(+), 2 deletions(-)
  7. [qcr@ecs-205826 project]$ git branch -d fit_bug
  8. Deleted branch fit_bug (was 171cefc).

        此时，bug 的修复工作已经做完了。

  1. [qcr@ecs-205826 project]$ cat test.txt 
  2. 你好
  3. hello
  4. aaaaa on dev branch
  5. aaaaa on dev1 branch
  6. aaaaa on dev2 branch
        至此，我们还要继续回到 dev 分支进行开发。 
  1. [qcr@ecs-205826 project]$ git checkout dev
  2. Switched to branch 'dev'
  3. [qcr@ecs-205826 project]$ cat test.txt 
  4. 你好
  5. hello
  6. aaaaa on dev branch
  7. ont dev1 branch
  8. on dev2 branch

        然而此时，工作区是干净的，刚才的工作现场存到哪去了？需要用 git stash list 命令进行查看。

  1. [qcr@ecs-205826 project]$ git stash list
  2. stash@{0}: WIP on dev: 920acfc 有bug
        工作现场还在，Git 把 stash 内容存在某个地方了，但是需要恢复⼀下，我们可以使用  git stash pop 命令，并且恢复的同时会把 stash 也删了。 
  1. [qcr@ecs-205826 project]$ git stash pop
  2. # On branch dev
  3. # Changes not staged for commit:
  4. #   (use "git add <file>..." to update what will be committed)
  5. #   (use "git checkout -- <file>..." to discard changes in working directory)
  6. #
  7. #	modified:   test.txt
  8. #
  9. no changes added to commit (use "git add" and/or "git commit -a")
  10. Dropped refs/stash@{0} (ec2f9704d78aec920b0ef53a711241e3ce3c215b)
  11. [qcr@ecs-205826 project]$ cat test.txt 
  12. 你好
  13. hello
  14. aaaaa on dev branch
  15. ont dev1 branch
  16. on dev2 branch
  17. I am coding ……

        这个时候可以看见，工作区中原有的内容是恢复过来了，但是原有的 "ont" bug是并未被修复的。原因就是因为，创建 dev 分支的时候，是基于 master 的 bug 提交所创建出来的，而 master 分支下的 bug 是已经被修复了的，所以并不会影响。

        此时，dev 中的新项目的开发完成了，并进行了提交。

  1. [qcr@ecs-205826 project]$ vim test.txt 
  2. [qcr@ecs-205826 project]$ cat test.txt 
  3. 你好
  4. hello
  5. aaaaa on dev branch
  6. ont dev1 branch
  7. on dev2 branch
  8. I am coding … done
  9. [qcr@ecs-205826 project]$ git add .
  10. [qcr@ecs-205826 project]$ git commit -m "新功能更新完成"
  11. [dev bdea1fa] 新功能更新完成
  12.  1 file changed, 1 insertion(+)

        master 分支目前最新的提交，是要领先于新建 dev 分支时基于的 master 分支的提交的，所以在 dev 中当然看不见修复 bug 的相关代码。

不建议的合并方式

        我们最终目的是要让 master 合并 dev 分支的，那么正常情况下我们切回 master 分支直接合并即可，但这样其实是有⼀定风险的。是因为在合并分支时可能会有冲突，而代码冲突需要我们手动解决（在 master 上解决）。我们无法保证对于冲突问题可以正确地⼀次性解决掉，因为在实际的项目中，代码冲突不只⼀两行那么简单，有可能几十上百行甚至更多，解决的过程中难免手误出错，导致错误的代码被合并到 master 上。

建议的合并方式

        解决这个问题的⼀个好的建议就是：最好在自己的分支上合并下 master ，再让 master 去合并 dev ，这样做的目的是有冲突可以在本地分支解决并进行测试，而不影响 master 。

        接下来就是实操。

第一步

        首先我们需要将 dev 与 master 进行合并。

  1. [qcr@ecs-205826 project]$ cat test.txt 
  2. 你好
  3. hello
  4. aaaaa on dev branch
  5. ont dev1 branch
  6. on dev2 branch
  7. I am coding … done
  8. [qcr@ecs-205826 project]$ git branch
  9. * dev
  10.   master
  11. [qcr@ecs-205826 project]$ git merge --no-ff -m "merge master" master
  12. Auto-merging test.txt
  13. CONFLICT (content): Merge conflict in test.txt
  14. Automatic merge failed; fix conflicts and then commit the result.
  15. [qcr@ecs-205826 project]$ cat test.txt 
  16. 你好
  17. hello
  18. aaaaa on dev branch
  19. <<<<<<< HEAD
  20. ont dev1 branch
  21. on dev2 branch
  22. I am coding … done
  23. =======
  24. aaaaa on dev1 branch
  25. aaaaa on dev2 branch
  26. >>>>>>> master

        发现在 test.txt 中是有冲突的，但是这一次是无所谓的，因为这一次冲突是在本地分支上的，在本地分支上就可以随意的修改了。

  1. [qcr@ecs-205826 project]$ vim test.txt 
  2. [qcr@ecs-205826 project]$ cat test.txt 
  3. 你好
  4. hello
  5. aaaaa on dev branch
  6. aaaaa on dev1 branch
  7. aaaaa on dev2 branch
  8. I am coding … done
  9. [qcr@ecs-205826 project]$ git add .
  10. [qcr@ecs-205826 project]$ git commit -m "合并与master的冲突"
  11. [dev c6eafd4] 合并与master的冲突

第二步

        然后就可以切换到 master 上，进行dev的没有冲突的合并了。

  1. [qcr@ecs-205826 project]$ git checkout master
  2. Switched to branch 'master'
  3. [qcr@ecs-205826 project]$ git merge --no-ff -m "merge dev" dev
  4. Merge made by the 'recursive' strategy.
  5.  test.txt | 1 +
  6.  1 file changed, 1 insertion(+)
  7. [qcr@ecs-205826 project]$ cat test.txt 
  8. 你好
  9. hello
  10. aaaaa on dev branch
  11. aaaaa on dev1 branch
  12. aaaaa on dev2 branch
  13. I am coding … done
  14. [qcr@ecs-205826 project]$ git branch -d dev
  15. Deleted branch dev (was c6eafd4).

删除临时分支​​​​​​​

        软件开发中，总有无穷无尽的新的功能要不断添加进来。
        添加一个新功能时，你肯定不希望因为一些实验性质的代码，把主分支搞乱了，所以，每添加一个新功能，最好新建一个分支，我们可以将其称之为 feature 分支，在上面开发。完成后，合并，最后删除该 feature 分支。
        可是，如果我们今天正在某个 feature 分支上开发了一半，被产品经理突然叫停，说是要停止新功能的开发。虽然白干了，但是这个 feature 分支还是必须就地销毁，留着无用了。这时使用传统的 git branch -d 命令删除分支的方法是不行的。因为之前使用这个命令进行删除分支的时候，该分支都是已经进行了 merge 操作的，这样 Git 才支持我们删的。
        如果是一个我们还未进行 merge 操作的时候，并且还在该分支上，进行了一定的提交操作， Git 就会保护这个分支，因为 Git 认为只要我们创建出来的分支就是有用的！这个时候需要使用  git branch -d 命令强行删除分支。
声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/不正经/article/detail/414238
推荐阅读
相关标签

Copyright © 2003-2013 www.wpsshop.cn 版权所有，并保留所有权利。

  

闽ICP备14008679号