环球今日讯!git怎么合并分支代码

时间:2023-01-04 11:01:48       来源:PHP中文网

本教程操作环境: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中文网其它相关文章!

关键词: 一个新的 时间顺序