首先从这张图开始我今天的git分支的行走情况:一般的git环境,一般包含master分支,dev开发分支,test测试分支,一般都是test通过的代码才能放到master中,所有我们的一般开发一个新的功能,都是从master中拉取代码,这个代码基本和线上的代码是一样的,然后通过建立分支来对代码进行开发(git checkout -b 分支名,查看分支git status或者git branch),然后开发测试完,然后git add 文件,git commit -m '注释',然后切换到dev分支与dev合并(git checkout dev ,git merge 分支名,如果有冲突,然后修改冲突(基本上保持dev上原来的不变把自己改的加上),注意不切换分支,然后git add ,git commit -m '',最后git pull ,然后推送到远端dev中git push),这样就与dev分支合并了,如果自测没有问题,就该交到测试去测试了,然后需要把分支与test合并,然后我们需要先切换到原分支(也就是自己之前建的那个分支),然后与git status看提交的情况,然后添加修改提交完,切换到test环境,然后与test合并,还是用git merge 原分支名,然后把冲突解决,以test上的代码为主(也就是接受test环境),然后冲突解决完,提交,然后推送到远端,这样与test的分支合并就结束了。之后就剩与master分支的合并了,这块一般都是把原分支推送到远端建立分支,然后在远端分支合并。这样一整套流程就结束了。弄完之后我们来看,其实每次一个新的功能都是从master开始,master就是一个个test测试没有问题的代码的集合,其中dev,test都是比master上要新,这样dev、test就是一个验证分支功能的过程,验证通过,才能放到master,也就是这样一套code管理流程。
这就是我在新公司新的一周对git的分支合并的体会。欢迎提出其中的问题,谢谢。