本教程操作环境:Windows7系统、Git2.30.0版、Dell G3电脑。
在项目中,我们总会创建很多分支进行不同功能或者需求的开发,等功能完成后再合并回主分支。那么如何才能优雅的合并分支呢?如果此时你提起了兴趣,那么不妨继续读下去了。
建立多人开发场景
1. 创建仓库
// 初始化仓库git init// 创建a.txttouch a.txt// 创建b.txttouch b.txt// 加入暂存区git add .// 提交git commit -m "initial"
登录后复制
2. 创建 feature 分支
git checkout -b feature
登录后复制
3. 两个分支同时开发
feature 分支开发下一版本新功能,提交了两次,分别修改 a.txt 文件和 b.txt 文件。
【资料图】
master 分支开发本次版本功能,同样提交了两次,且修改了 a.txt 文件和 b.txt 文件。
当前分支情况如下图,各节点上面的字符是每次 commit 的散列值,当前 master 分支的 header 在 c5 节点上,feature 分支的 header 在 c3 节点上。
这个时候需要将 feature 分支合并回 master 分支,有两种方案:
在 master 分支上直接 merge feature 分支;
是先在 feature 分支上 rebase(变基),然后在 master 分支上 merge feature 分支。
下面分别说明一下这两种方案:
合并命令1:git merge
git merge 用来做分支合并,将其他分支中的内容合并到当前分支中。
git merge 操作比较暴力,也是用的比较多的方式,下面演示的是 feature 分支合并至 master 分支,具体过程如下:
找到 feature 分支和 master 分支的最近共同祖先 commit 节点 c1;
把 feature 分支的最新一次 commit 节点 c3 和 master 分支上的最新一次 commit 节点 c5 合并,此时若有冲突,则一次性解决所有冲突,然后生成一个新的 commit 节点 c6;
同时根据两个分支上的 commit 时间的先后顺序,依次放到 master 分支上,使用git log可以看到时间顺序。
上面流程的结果示意图如下所示:
在项目中的操作命令如下。可以看到执行 git merge feature
命令后,存在冲突,进入 merging 工作区,然后一次性解决所有冲突后,提交一个新的 commit。
执行 gitk 命令行,可以在界面上看到当前分支如下图所示。有一个新的 commit。
合并命令2:git rebase
这个命令从名字上就可以直观看出它的功能:改变当前的分支的基点
。对于 feature 分支,它是从 master 分支的 c1 节点创建的分支,所以它的基点
就是 c1。如果在 feature 分支上执行 git rebase master ,其过程大致如下:
找到当前 master 分支最新的 commit 节点 c5,将 feature 分支的基点变成 c5 节点。;
若 feature 分支与 master 分支存在冲突,那么将根据 feature 分支的提交时间,依次解决冲突,并修改 feature 分支此次 commit 的散列值。
最终在分支上看,呈现一条直线,但是存在历史commit覆写的问题。
上面过程的结果示意图如下所示,其中 c2’和 c3’表示散列值改变了。
了解其基本过程后,我们就可以是用 rebase 命令开始进行合并分支的操作:
在项目中执行 git rebase master,如下所示。因为两次提交都存在冲突,故在 rebase 工作区中需要依次解决这些冲突。
在 feature 分支上执行 gitk 命令,可以在界面中看到:
feature 分支完成变基之后,切换回 master 分支执行 git merge feature,就可以完成合并操作。
在 master 分支上执行 gitk,其分支结构如下。可以看到分支呈现一条线,看上去非常清爽。
说明:git stash
有时候分支上的代码还没开发完成,需要合并分支,此时只需要:
1、执行 git stash 将工作区内容存储起来,然后选择上述两种合并分支的方式进行分支合并。2、完成分支合并后,切回开发的分支,执行 git stash pop 将工作区内容弹出就可以继续愉快的写代码了。
总结
git merge 比较粗暴,也是大多数会选择的方式,这种方式可以保证每个 commit 都按照时间顺序排列,但是分支图会非常凌乱,而会引入一次没有意义的 commit。
git rebase 在历史提交记录就是一条线,非常优雅,但存在修改历史commit的风险,并且git log查看日志时commit时间线错乱。同时,谨记已推送至远程的内容就不要再变基,否则分支会变得很乱。
个人倾向于使用 rebase 方法,毕竟 commit 的认知成本摆在那里,而且看着也舒服。不过如果开发人员很多,还是merge吧,毕竟一个个解决冲突会烦死个人,哈哈哈
在项目中,我们总会创建很多分支进行不同功能或者需求的开发,等功能完成后再合并回主分支。那么如何才能优雅的合并分支呢?如果此时你提起了兴趣,那么不妨继续读下去了。
以上就是git怎么合并分支代码的详细内容,更多请关注php中文网其它相关文章!