让处女座、强迫症患者更舒服的 Git 合并
起因
首先先给大家看下我们公司一个项目的功能开发分支。
从左边生命线可以看到好多好多的合并记录。
再给大家看看我们公司的 master 的分支。
处女座有没有感觉到很舒服啊。
因为我们的老大是处女座,所以他很强迫的不想看到 Merge
这种无用的 commit。 :expressionless:
So,让我们来了解下如何在分支合并后更加美观。
让我们先来了解下常用分支合并步骤。
1.先创建一个测试用的仓库。
2.创建一个分支进行修改并提交。
3.发起合并请求。
此时,我以前都是通过点击合并按钮来确认合并就 OK 了。
在 Github 中则是一个 Merge pull request
的按钮在下方。
如果是有冲突的话。
则通过如下方式进行冲突解决并合并。
git pull origin test
vim 冲突文件
git add -A
git commit -m ""
git push origin master
4.查看结果
此时在提交栏中就会显示一个灰色的 Merged 合并记录。
显然,当合并次数越来越多时。
提交栏中的记录就会像上方我的开发分支截图一样越来越多,越来越复杂。
创建干净、美观、适合处女座的合并记录
1.切换回 master 并更新,在创建新的分支。
2.修改提交并发起合并。
这里的 git rebase master
是为了保持与 master 的更新并处理冲突。
这样 master 在合并时就不会产生冲突。 (这一步非常重要)
3.通过 rebase 合并分支。
git checkout master
git fetch --all --tags
git merge origin/master
git rebase origin/master
git push origin master
在该操作中可能会有冲突(因为篇幅原因就不赘述了)。
4.查看结果
最后
图片有点多,非常抱歉。
还是想问各位有没有觉得很舒服呢? :laughing:
然后在上方的命令当中穿插了很多。
git checkout master
git fetch --all --tags
git merge origin/master
是为了更新master分支。git pull
本质就是 git fetch + git merge
。
由于篇幅原因。rebase
中的原理就由大家自己去百度吧。
本作品采用《CC 协议》,转载必须注明作者和本文链接
慎用 rebase,只要团队里有一个人没掌握好出现了误操作就炸了
@leo 如果不是团队要求,我也不想这么麻烦啊 :cry:
可以使用
git pull --rebase
最后的图片用错了吧