git 常见的分支管理流程(Git开发过程中的真正使用)

git 常见的分支管理流程(Git开发过程中的真正使用)(1)

合并分支可谓是分支操作中最为繁琐、最容易出现问题的环节。

但有些人会有疑问,一定要在其他分支上开发,开发完成再合并到主分支上吗?那如果多人协作的情况怎么办?不会出现问题吗?

在开发中,我们一般不会直接对主干进行修改,而是从开发分支,如dev分支中,创建自己的分支,在分支上进行修改。

在我的理解中,是为了保证主干上代码的干净。

保证了主干上的代码是可以直接发布或者被项目之外的人使用(例如新入职的员工,总不能给人家一个一运行就报错的代码库吧)。然后关于产品/项目的新特性和BUG修改都在不同的分支上进行开发和测试。这样规范了整个软件的开发流程。分支之间的互不影响这种特性可以增加团队合作的效率。

至于多人协作时出现的各式各样的问题,归根到底只需要记住一个点,就能大量避免远端上的问题,那就是!

在合并之前,记得要先更新合并分支的代码,避免出现提交的历史不匹配,而导致更多的冲突。

git 常见的分支管理流程(Git开发过程中的真正使用)(2)

git最佳分支流程

接下来,我们就基于前面几篇,来进行一个完整的开发流程:

这篇没有H1标题了!

一般开发环境中,Git会存在master主分支、release发布分支、dev开发分支,甚至还有test测试分支。

以下基于存在master主干分支、dev开发分支的情况下进行,若没有dev分支,那么建议你说服你的技术主管(我相信你可以的)

1、从远端clone项目到本地后,先切换到dev分支并在该dev分支上更新下最新代码,保证待会创建的分支的代码都是最新的:

git pull

2、开分支:

git branch feature-2019-6-29-testBranch

git 常见的分支管理流程(Git开发过程中的真正使用)(3)

feature一般用于新功能开发

feature命名的分支,我们一般用于新功能的开发,它只与dev分支交互,开发完成并合并到dev后,就会删除该分支。

另外还有hotfix命名的分支,一般用于修复主干分支上的bug,但需要注意,由于该bug是旧版本所存在的问题,那么在dev分支上也同样存在该问题,也就代表着,修复了这个bug后,该hotfix分支的提交需要合并到master和dev两个分支上,避免后续dev分支合并master分支时出现问题。

而dev分支将作为最终开发和调试的代码库,完成后合并master分支,并发布新版本。

3、查看分支情况(以及自己正在使用的分支):

git branch

git 常见的分支管理流程(Git开发过程中的真正使用)(4)

4、切换分支:

git checkout featrure-2019-6-29-testBranch

git 常见的分支管理流程(Git开发过程中的真正使用)(5)

5、查看分支情况(是否有提交之类的):

git 常见的分支管理流程(Git开发过程中的真正使用)(6)

总结下上面的步骤:

1、上面的步骤可以直接通过一个命令来进行创建分支,并切换分支:

git checkout -b feature-2019-6-29-testBranch

git 常见的分支管理流程(Git开发过程中的真正使用)(7)

2、在该分支上进行修改,修改完后进行添加和提交:

git add . git commit -m "备注"

git 常见的分支管理流程(Git开发过程中的真正使用)(8)

3、本地切换为dev分支,更新下dev为最新(因为可能其他开发人员已经合并过代码,此时你本地的dev不再是最新),为了下面的合并不受冲突:

git checkout dev git pull

git 常见的分支管理流程(Git开发过程中的真正使用)(9)

4、切换回来

git checkout feature-2019-6-29-testBranch

5、将更新到最新dev合并到自己这个分支上,这一步是为了在你修改自己的分支的过程中,已经有分支合并到dev上了,如果有冲突的话,就先把dev的合并过来,然后在分支上进行冲突解决:

git merge dev

git 常见的分支管理流程(Git开发过程中的真正使用)(10)

注意,当前分支为要被合并的分支

6、如果merge后有冲突需要修改,修改后进行 添加、提交、拉取最新(如果这个分支别人也有修改,记得pull更新最新,确保不冲突):

git add . git commit -m "备注" git pull orgin feature-2019-6-29-testBranch

7、确认无误后,保证编译正常的情况下,就可以push这个分支到远程仓库了:

git push origin feature-2019-6-29-testBranch

git 常见的分支管理流程(Git开发过程中的真正使用)(11)

8、之后就可以在dev分支上合并自己的那个分支了(但项目不受权限控制,可以直接通过命令来合并):

git checkout dev git merge feature-2019-6-29-testBranch git pull git push dev

注意,需要先切换当前分支为要被合并的分支,如此时是dev分支。

9、当没有权限对dev进行操作的时候,则需要在页面上进行合并的操作(以GitLab为例):

提交合并请求,给到有权限的人,去确定合并

git 常见的分支管理流程(Git开发过程中的真正使用)(12)

git 常见的分支管理流程(Git开发过程中的真正使用)(13)

10、至此分支操作结束,删除分支,删除分支的时候需要先切换分支为其他分支,才能进行删除:

删除本地分支:

git branch -d feature-2019-6-29-testBranch

删除远程分支:

git push origin --delete feature-2019-6-29-testBranch

git 常见的分支管理流程(Git开发过程中的真正使用)(14)

当出现冲突的时候:

1、主干版本有新的提交,分支上也同样修改了该文件,此时在主干上pull更新到最新,然后checkout到分支上,合并主干的时候,会出现

git 常见的分支管理流程(Git开发过程中的真正使用)(15)

这种情况,可以先将本地的修改存储到暂存区:

git 常见的分支管理流程(Git开发过程中的真正使用)(16)

然后再合并:

git 常见的分支管理流程(Git开发过程中的真正使用)(17)

再把自己的修改从暂存区拿出来:

git 常见的分支管理流程(Git开发过程中的真正使用)(18)

(git stash list: 可以看到暂存区里面的东西,从而可以根据需要来获取

git stash pop: 把暂存区里面的修改取出来

git stash clear:清除暂存区 )

这时候,文件会变成conflict状态:

git 常见的分支管理流程(Git开发过程中的真正使用)(19)

修改后,再提交,再合并回主干,就不会有冲突了。

是不是真的没有H1标题

git 常见的分支管理流程(Git开发过程中的真正使用)(20)

总的来说,一般开发过程中,都有一个前提,那就是不会直接使用master分支进行开发,而是由dev分支进行,有些团队在这个基础上,让各个开发人员都使用自己的dev分支,也就是说会有很多个dev分支(如dev_某某某),开发人员在开发完成,解决完冲突后,再将自己的分支合并到主开发分支(可能会使用dev分支,或者也可能会使用release发布分支)上,各自维护各自的开发分支。

后续

git 常见的分支管理流程(Git开发过程中的真正使用)(21)

欢迎关注我【居家程序员】

使用分支 merge开发,是Git在开发中最常见的开发方式,但由于每次合并都会使用merge,在本地分支的提交历史和远端的分支的提交历史不一致的情况下,此时Git会为我进行了自动合并,然后生成了一个新的提交历史,内容如“merge branch 'master' of...”,也就是产生了分叉,若不想看到这种情况,我们就会使用另一个命令git rebase来进行,该命令可以使分支间的提交历史同步,不会产生分叉,我们后面再来说。

我并不是高冷(Git进行中01):git基本流程简介可以说是矫情暖男(Git进行中02):git基本操作想独立门户吗(Git进行中03):Git分支介绍

,

免责声明:本文仅代表文章作者的个人观点,与本站无关。其原创性、真实性以及文中陈述文字和内容未经本站证实,对本文以及其中全部或者部分内容文字的真实性、完整性和原创性本站不作任何保证或承诺,请读者仅作参考,并自行核实相关内容。文章投诉邮箱:anhduc.ph@yahoo.com

    分享
    投诉
    首页