关于 git 工作流我有个小疑问(冲突在本地还是远端解决)

[unco020511]

正常开发中,我们会从 main->new branch feature 分支,当我的 feature 开发完毕后,origin/main 可能已经更新了很多个 commit(从其他 feature 合并而来),很可能存在冲突,此时我有两种操作方式,哪种方式更好?

1. 先在本地将 main pull 之后,将 local/main 合并到 local/feature,在本地解决冲突,然后 push origin feature,然后在 gitlab(或 github)提交 merge request(或者 pull request),将 origin/feature 合并到 origin/main
2. 直接 push origin feature,然后在远程提交 merge request(或者 pull request),在远程仓库(可视化工具)解决冲突,然后将 origin/feature 合并到 origin/main

这两种方式各有什么优缺点?哪种更适合企业项目的团队合作?

[imkerberos]

远端不用重新 approve .

[unco020511]

@imkerberos approve 肯定都需要,我们是两个同事 review 后 approve,才能进行 mr

[momocraft]

1 才有机会解决冲突后运行和测试

除非你们有足够好的自动测试 不需要手工保证

[unco020511]

@momocraft 你的意思是 1 可以在 mr 之前基于 feature 进行测试是吗?我这里简化了,实际上肯定不是直接 mr 到 main 上,一般会有个 dev,2 的话也可以 mr 之后基于 dev 测试

[imkerberos]

我的意思是 重新 approve.

[unco020511]

@imkerberos 推荐 1 是吧

[EastLord]

1

[lidlesseye11]

1

[cowcomic]

1 提交代码要保证合并的正确性和正常运行

[janus77]

对于比较大的团队和比较严格的规范，应该是远程合并，因为普通开发不应该有 write main 分支的权限。
而对于简单项目和小团队，以及实际操作上来讲，本地合并的话，解决冲突更容易，因为远程合并一般都是命令行或者 web 界面，本地可以用一些 gui ，鼠标点点就能正确合并，操作更简单。

[sue0917]

楼上在说啥😂

[Macolor21]

@janus77 #10

让 feat 分支 rebase main ，然后解决冲突后 push feat 再 开启 mr 就可以了，不用 merge 到 main 再 push main 。

[GeruzoniAnsasu]

其实没有「远端解决冲突」一说，所有的合并和冲突解决都是在叶子节点上或者说都在 git 的「客户端」进行的。

web 界面只是自动做了一些额外的事情而已，跟你在本地用一个 GUI git 工具是一回事。




> 当我的 feature 开发完毕后,origin/main 可能已经更新了很多个 commit(从其他 feature 合并而来),很可能存在冲突

此时你 **不应该进行任何 MERGE 尝试**。

1. 首先应该在本地切换到主分支（ dev/main/master ），拉取远程的状态。由于你不可能直接在这些分支上修改，所以这一步不会产生任何冲突，仅仅是快进
2. 切回到你的开发分支，把它 rebase 到主分支上，此时产生冲突，resolve ，重新 commit 。
3. 由于到目前为止你还是只修改过你的独占分支（就算有远程也是可以随便 push -f 的那个），所以不会对其他人产生任何影响。
4. push 你 rebase 过后的分支，开启或刷新 MR





之所以采用不断 rebase 分岔点的方式是因为，如果你不进行 rebase ，merge 操作时是一个三路合并，而三路合并是一个**既复杂又存在危险性** 的操作


(!!) 其实我本来想简单解释一下为什么三路合并会出问题，但在我搜索看了近一个小时文章后，我选择放弃解释：
https://www.waynerv.com/posts/git-merge-intro/
https://git-repo.info/zh_cn/2020/03/something-about-git-merge/
https://actake.github.io/2021/03/21/git%E5%BF%85%E7%9F%A5%E5%BF%85%E4%BC%9A-%E5%88%86%E6%94%AF%E5%90%88%E5%B9%B6%E9%82%A3%E4%BA%9B%E4%BA%8B/





(!!) 因为这已经是我至少第 4 次搜索这个问题然后仍然没有完全搞懂了


如果采用 rebase - merge FF 的方式，合并操作等同于在对方分支上把你做过的操作重放一次，心智负担和风险要小得多。只有一个麻烦，因为是重放，当你的 commit 序列一开始就与对方冲突时，这个冲突会有传递性（对方是 A ，你第一个提交把 A 改成了 B ，后面的提交全部在用 B ；发现冲突后你决定改成 C ，那么当你 rebase 重放的时候所有后面的提交都会不断发生 B 和 C 的冲突）。但这都可以通过减少 commit 修改量和 squash 改善，相比起三路合并能由（虽然存在疏忽的）正常操作产生 **无感知的** 丢修改相比，成本显然要低得多

[rickll]

如果在本地已经有冲突的代码，为什么还要提交到远端去？ 别人把这个冲突代码拉下来不是骂娘。 所有冲突都应该在本地解决。

[maninfog]

一般这种情况是 1.git fetch 2.git rebase origin/master 3. git push -f (rebase 之后 feature 分叉了所以需要 force push)

[rbe]

这两个方式没有什么本质区别呀，核心都是自己 feature 分支随便玩，自己单独开发的话 rebase 都可以，保证合入不冲突，最后 mr 到 main 都只有一个 commit 。
区别就是你在本地 editor 解决冲突还是网页端可视化工具解决冲突。大概率复杂情况下你都需要在本地解决的，网页端都不好搜索代码

[Chism]

我倾向于本地解决冲突，还能顺便测试一下是否运行正常

[cyang812]

@GeruzoniAnsasu rebase 到 main 和 merge main 有什么区别呢？

[ClericPy]

不太复杂的小项目 git flow 感觉有点复杂, Github flow 就够用了

rebase 吧, 你的基被人往前推了, 那就变基到跟线上一致提个 PR, 主线分支光溜溜一根挺好的.

[jessun1990]

git rebase ，本地解决冲突，再 push 上去。

[GeruzoniAnsasu]

@cyang812 rebase 后分岔点在基分支的最前端，merge 的分岔点是基分支上历史中的某个点。rebase 的历史永远是线性的，merge 会织出复杂的演化网。

rebase 目标分支和本分支不对等，你基本不可能搞错（不可能试图把 main 拼到 feature 上，只会把 feature 拼到 main ）
而 merge 就可 tm 难说了，feature merge main 和 main merge feature 观感上根本没什么区别，看起来也都很合法，但形成的历史网是不同的，出问题的时候根本没人有能力搞清楚发生了啥

[FrankHB]

正常都是开发者自己解决冲突，不限制解决冲突使用的工具，测过了再提交，而不是滥用 Web 编辑器让公共分支变成不可维护的临时 patch 火葬场。
Reviewer 只需要对 diff 和 merge 结果负责，不需要对具体操作负责。
即便要用统一的 flow ，Gerrit 之类也有事后诸葛亮。
实际上 merge 不见得应该是首选项。要 merge 还是 ff-only 还是 squash ，你作为分支的 owner 应该清楚。或者你就不管，活干完了找清楚怎么处理这些问题的专人负责。

[msg7086]

你说的两点都是错的。
2 不行因为 WebUI 功能太弱，建议本地合并完做好测试再推。
1 的话做法错了，主线往分支合并用 rebase 更好。以前 git 那个坑爹的命令行默认 pull 执行 merge ，然后不懂的小白就跟着 pull 了瞎 merge 。现在新版本的 git 命令行总算是去掉了默认 merge 的行为。

[jsq2627]

尝试在团队推行过 "Require branches to be up to date before merging"
最后发现 PR 合并效率太低，一次只能合并 1 个人 PR ，合并后其他人又要 rebase master ，然后重新等 CI 。。

[unco020511]

@GeruzoniAnsasu #13,我明白了,谢谢

[alanhe421]

根本上还是在于是在 feat 分之还是 main 分支上处理冲突，肯定都会是在非 main 分支处理的。

比如我所在的团队，均是 feat owner 拉取 main 分支的，解决冲突后，再 MR 到 main.且为了 Review 体验方便，一般是在本地，当然特别小的 diff 的话，上游 WEB 也 OK

[codeMore]

1 、feat 要合并前，先 rebase master 分支，本地解决完冲突后，推送到 feat

[levelworm]

我之前恰好看过几篇文章，似乎是推荐先 rebase

[levelworm]

@jsq2627 求问一下这样是否可行？

假如某 feature 需要多人共同开发，于是事先约定大家新建、改动什么文件，保证不会互相干扰，于是从 main 分出 feature_branch ，并又分成多个个人的 feature_individual_branch ，最后开发完成之后合并进 feature_branch ，如何？

如果互相之间有干扰，比如说有个配置文件多人需要共同编辑，那看来只能指认其中一人为 feature reviewer ，把这些共同的文件承担下来了。

[levelworm]

@Macolor21 #12
新手求问，如果能够让每个 feature branch 在合并之前都自动进行 rebase ，是好是坏？

[Macolor21]

@levelworm 有冲突的时候 rebase 不成功的，没冲突的情况下，rebase 没问题

[815979670]

看公司，如果这个项目是你单独维护，甚至可以直接 push main 分支，能解决冲突就好。
如果是多人协作 且你不是分支管理员 的情况下 通常使用 1.
但需要注意的是，无论哪种方案，冲突都是在本地解决的，不允许在线上（ web ）处理。

[levelworm]

@Macolor21 也是，看来还是冲突最麻烦。那么是否应该尽量从项目架构上去避免冲突？比如说尽量避免多人修改同一个文件的情况出现？虽然未必现实。。。

[darknoll]

把 main 分支更新下，然后重新 checkout 一个新分支，把修改加进去，然后用这个新分支发送 pr

[wu67]

当然是本地处理, 远程当成存档点来用. 我个人是倾向自己处理冲突合并的, 基本没 rebase 过.

[nothingistrue]

你说的 2 ，其实就是 1 ，只不过是把解决冲突的操作从本地搬到远程而已。2 发生冲突的时候，你并不是必须用远程仓库的工具，还可以本地在 feture 解决冲突并推送之后，再重新执行 MR/PR 的合并。MR/PR 开启之后，是可以继续提交的。

如果你执行的是全 merge ，并没有 rebase 的话，2 会更省事点。

如果是用 rebase 来搞准线性历史的话，要用 1 的方式。

[zhaol]

@GeruzoniAnsasu 想问下，如果 rebase 的话，这个时候我的分支会有别人的 feature 或者 bugfix 的代码了，但是如果别人的 feature 这个版本不上，我的分支要上，怎么把别人的那部分拆出来？

[libotony]

@zhaol cherry-pick

[stimw]

冲突要在 rebase 解决，不要在 merge 时候再去解决冲突。。我一直记得这句话

[cgdddd]

我们公司要求,所有冲突必须要求本地解决,一律 request 的冲突全部打回

[GeruzoniAnsasu]

@zhaol 在他的 feture 合并前，应该准备好 4 个分支：1 你的 feature ，2 他的 feature ，4 有他 feature 的版本分支，4 没有他 feature 的版本分支

我们之前的实践是，有一个接受所有 feature 的分支，比如 master ，然后给每个要发布的版本建 release 分支，他先写完后合并到 master ，你写完，rebase master ，合并。此时 master 上有两个 feature （ 0-2-1 ），而 release 上还什么都没有。 像 gitlab 有 自动 cherry-pick 的功能，web 界面上点一下可以把整个 MR （比如你合并 master 那个 MR ）里的所有 commit 都 cherry-pick 到另一个分支上（ release ）。pick 完 release 看起来像是（ 0-1 ），但 1 的那些 commit 不是原始 commit ，是 cherry-pick 重新生成的。

如果 web 界面没有这个功能，就只能在本地手动 pick 一堆 commit 。不过鉴于 release 分支一般也不需要保留修改历史（ master 已经有了），所以可以把 feature 的所有 commit 都 squash 成一个 pick 给 release ，这样手动也不会很麻烦

[hanleisky]

理论上是 1,但是小公司菜逼多，都是让他们推上来发 PR ，我来解决冲突然后合并