遇到冲突了怎么解决?

两个分支进行合并时,可能会遇到冲突,同时被修改的文件会进入 both modified 状态,需要解决冲突。

1、最快的办法

大部分时候,「最快解决冲突」的办法是:直接选择当前 HEAD 的版本(ours),或合并进来的分支版本(theirs)。

# 使用当前分支 HEAD 版本,冲突源文件的 <<<<<<< 标记部分,======= 的上方
git checkout --ours <文件名> # gco --ours

# 使用合并分支版本,冲突源文件的 >>>>>>> 标记部分
git checkout --theirs <文件名>

# 标记为解决状态加入暂存区
git add <文件名> # ga

2、最普通的办法

你可以直接用编辑器打开冲突的源文件进行修改,但需要注意删除冲突标记,你也可以使用体验更加友好的 Three-Way Merge 工具,借助 git mergetool 命令来完成。

如何配置 git merge tool?请参见后续章节。

3、好的习惯

以下好的习惯,可以减少代码的冲突的发生:

  • 在开始修改代码前先 git pull 一下;

  • 将业务代码进行划分,尽量不要多个人在同一时间段修改同一文件;

  • 通过 Gitflow 工作流 也可以提升 git 流程效率,减少发生冲突的可能性。

4、最复杂的情况

如果你的项目周期比较长,还应该养成「定期 rebase 的习惯」,git pull --rebase 可以让分支的代码和 origin 仓库的代码保持兼容,同时还不会破坏线上代码的可靠性。

它的大概原理是,先将 origin 仓库的代码按 origin 的时间流在本地分支中提交,再将本地分支的修改记录追加到 origin 分支上。如果发生冲突,则可以即时的发现问题并解决,否则到项目上线时再解决冲突,可能会发生额外的风险。

rebase 大概的操作步骤如下:

# 将当前分支的版本追加到从远程 pull 回来的节点之后
git pull --rebase       # gup

# 若发生冲突,则按以上其他方法进行解决,解决后继续
git rebase --continue   # grbc

# 直到所有冲突得以解决,待项目最后上线前再执行
git push origin         # ggp

# 若多次提交修改了同一文件,可能需要直接跳过后续提交,按提示操作即可
git rebase --skip       # grbs

需要注意的是,rebase 默认以 bog-standard flattening 模式将提交的时间线进行扁平化处理,如果希望保留两个版本的合并记录,可以使用 git pull --rebase=preserve 参数,或直接将该参数设置为全局配置:

git config --global pull.rebase preserve

Last updated