Git系列：进一步讲讲Git的分支管理

爱被打了一巴掌 2023-06-20 09:15 7阅读 0赞

**目录**

•写在前面

•解决冲突

•分支创建策略

•bug分支

•Rebase指令整理分支

•最后

--------------------

# •写在前面 #

Git分支管理在前面说了，非常方便我们开发，没看过前面的可以到前面看这篇[文章][Link 1]，接下来，我们讲讲关于分支管理的其他指令，帮助我们进一步了解分支管理给我们带来了什么方便。

# •解决冲突 #

冲突是什么？很多时候，当你在分支上进行修改，或者进行多人协同开发的时候，你会需要使用git进行合并，合并的时候就会出现冲突，也就是在你要合并的分支上发生了你这边没有更新的修改，并且同时这一个分支也发生了修改，两个分支的某一些文件存在不一致的情况，就会发生冲突。一般合并若发生冲突，Git会告诉你哪些文件发生了冲突，如下：

$ git merge branch1
    Auto-merging readme.txt
    CONFLICT (content): Merge conflict in readme.txt
    Automatic merge failed; fix conflicts and then commit the result.

这里告诉你说readme.txt文件发生了冲突，你也可以使用git status指令查看发生冲突的相关文件，那我们知道冲突之后，我们需要怎么解决呢？很简单，首先我们在没有使用工具的情况下（比如idea等，idea提供了很强大的工具让我们配合使用git，这文章不是讲解idea的使用，所以这里就不多说了，以后有机会专门开工具篇再说），直接打开发生冲突的文件，一般会出现下图这样的情景：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0RCQ18xMjE_size_16_color_FFFFFF_t_70][]![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0RCQ18xMjE_size_16_color_FFFFFF_t_70 1][]

在1区间，也就是<<<<<<HEAD到=======之间的这段代码，是我们要合并过去的那个分支上的老代码，而第2区间，也就是======到>>>>>>branch1之间的代码是我们分支上最新的代码，这个时候你只要取舍其中一个区间就可以解决冲突，一般情况下都是保留最新的更新，也就是第2区间。删的时候注意把我上右图圈住的都删掉哦。

删除冲突之后，你只需要重新git add 和git commit，把修改提交一下就可以了，冲突就解决了。然后就可以开始你的合并了。你可以使用如下指令查看分支的合并情况。

$ git log --graph --pretty=oneline --abbrev-commit

# •分支创建策略 #

在实际的开发中，我们通常会创建不同的分支代表不同的开发环境，就拿我以前工作经验看，公司开发的分支会有四条主线，分别是master、release、stage三种环境，master是用于测试环境，一般自己新开发完的功能代码可以合并到这个分支，然后重启运行项目用于测试、release分支是线上分支，也就是目前开发的项目正在运行的环境，这个分支一般情况下不是谁都有权限进行合并的，毕竟线上正在运行的项目代码万一被搞乱了，简直是爆炸。stage分支是预发分支，也就是master分支上测试好的代码，可以合并到这个分支上，用于测试人员使用。这三条主分支上，你可以在这三条主分支上创建自己的分支，每个人都可以创建自己的分支，非常适合团队合作，所以协作起来可能长这样，是不是很刺激。

![20191209200303827.png][]

# •bug分支 #

听到bug是不是很令人头痛，在我们日常的开发中不可避免的会遇到bug，如果我们在开发自己的功能，还没有开发完的时候临时要处理一个bug怎么办，这个时候我们正在开发的代码功能还没有写完，不能提交，但是这个bug又需要我们停下手上的工作区解决，这个时候怎么办？OK，完全不要担心，Git之所以强大，就是它考虑了很多我们实际开发中可能会遇到的情况，Git对于这种情况，提供了一个stash功能，可以把当前工作现场“储存”起来，然后以后继续工作。使用如下指令。

$ git stash

执行指令之后你可以使用git status查看当前工作区，就是非常干净的，因此可以开始着手修复bug。首先确定要在哪个分支上修复bug，假定我们正在request分支（request分支是在master上创建的）上开发代码，需要在master上修复，我们就从master创建临时分支，这个时候你在这个临时分支上。创建分支之后，你就可以开始修复bug，修复完成之后，可以切换到master分支，并完成合并，最后删除这个临时分支，bug毫无多余痕迹的修复了。然后这个时候我就就可以切回request分支上了，但是request分支上的工作区非常干净，我们把原来的工作储存到哪里去了呢？我们可以使用一下指令查看，发现工作区还在，那么我们有两种方法恢复。

$ git stash list

$ git stash apply
    #可以使用这个恢复，恢复后，stash内容并不删除，你需要用
    $ git stash drop #来删除；
    
    #另一种方法是使用这个，恢复的同时把stash内容也删了
    $ git stash pop

在master分支上修复了bug后，我们要想一想，dev分支是早期从master分支分出来的，所以，这个bug其实在当前dev分支上也存在。那怎么在dev分支上修复同样的bug？重复操作一次，提交不就行了？有木有更简单的方法？有！同样的bug，要在dev上修复，我们只需要把4c805e2 fix bug 101这个提交所做的修改“复制”到dev分支。注意：我们只想复制4c805e2 fix bug 101这个提交所做的修改，并不是把整个master分支merge过来。为了方便操作，Git专门提供了一个cherry-pick命令，让我们能复制一个特定的提交到当前分支。Git自动给dev分支做了一次提交，注意这次提交的commit是1d4b803，它并不同于master的4c805e2，因为这两个commit只是改动相同，但确实是两个不同的commit。用git cherry-pick，我们就不需要在dev分支上手动再把修bug的过程重复一遍。

# •Rebase指令整理分支 #

多人在同一个分支上协作时，很容易出现冲突。即使没有冲突，后push的童鞋不得不先pull，在本地合并，然后才能push成功。每次合并再push后，会出现前面我放的那张图那样很乱的类似路线图的东西。Git有一种称为rebase的操作，有人把它翻译成“变基”。

# •最后 #

Git的分支管理是不是很强大，到这里了，你有没有爱上Git这款工具，如果爱上了，证明你已经能够使用了，还没爱上只能说明还不够了解，哈哈哈哈。

[Link 1]: https://blog.csdn.net/DBC_121/article/details/103336627
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0RCQ18xMjE_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20191209184836458.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0RCQ18xMjE=,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0RCQ18xMjE_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/2019120918522830.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0RCQ18xMjE=,size_16,color_FFFFFF,t_70
[20191209200303827.png]: https://img-blog.csdnimg.cn/20191209200303827.png