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

2022-03-27 13:56:22 +08:00
 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

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

6503 次点击
所在节点    程序员
42 条回复
GeruzoniAnsasu
2022-03-27 17:07:09 +08:00
@cyang812 rebase 后分岔点在基分支的最前端，merge 的分岔点是基分支上历史中的某个点。rebase 的历史永远是线性的，merge 会织出复杂的演化网。

rebase 目标分支和本分支不对等，你基本不可能搞错（不可能试图把 main 拼到 feature 上，只会把 feature 拼到 main ）
而 merge 就可 tm 难说了，feature merge main 和 main merge feature 观感上根本没什么区别，看起来也都很合法，但形成的历史网是不同的，出问题的时候根本没人有能力搞清楚发生了啥
FrankHB
2022-03-27 17:10:12 +08:00
正常都是开发者自己解决冲突，不限制解决冲突使用的工具，测过了再提交，而不是滥用 Web 编辑器让公共分支变成不可维护的临时 patch 火葬场。
Reviewer 只需要对 diff 和 merge 结果负责，不需要对具体操作负责。
即便要用统一的 flow ，Gerrit 之类也有事后诸葛亮。
实际上 merge 不见得应该是首选项。要 merge 还是 ff-only 还是 squash ，你作为分支的 owner 应该清楚。或者你就不管，活干完了找清楚怎么处理这些问题的专人负责。
msg7086
2022-03-27 18:49:04 +08:00
你说的两点都是错的。
2 不行因为 WebUI 功能太弱，建议本地合并完做好测试再推。
1 的话做法错了，主线往分支合并用 rebase 更好。以前 git 那个坑爹的命令行默认 pull 执行 merge ，然后不懂的小白就跟着 pull 了瞎 merge 。现在新版本的 git 命令行总算是去掉了默认 merge 的行为。
jsq2627
2022-03-27 19:57:12 +08:00
尝试在团队推行过 "Require branches to be up to date before merging"
最后发现 PR 合并效率太低，一次只能合并 1 个人 PR ，合并后其他人又要 rebase master ，然后重新等 CI 。。
unco020511
2022-03-27 20:53:03 +08:00
@GeruzoniAnsasu #13,我明白了,谢谢
alanhe421
2022-03-27 22:19:22 +08:00
根本上还是在于是在 feat 分之还是 main 分支上处理冲突，肯定都会是在非 main 分支处理的。

比如我所在的团队，均是 feat owner 拉取 main 分支的，解决冲突后，再 MR 到 main.且为了 Review 体验方便，一般是在本地，当然特别小的 diff 的话，上游 WEB 也 OK
codeMore
2022-03-27 23:11:46 +08:00
1 、feat 要合并前，先 rebase master 分支，本地解决完冲突后，推送到 feat
levelworm
2022-03-27 23:34:26 +08:00
我之前恰好看过几篇文章，似乎是推荐先 rebase
levelworm
2022-03-27 23:45:54 +08:00
@jsq2627 求问一下这样是否可行？

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

如果互相之间有干扰，比如说有个配置文件多人需要共同编辑，那看来只能指认其中一人为 feature reviewer ，把这些共同的文件承担下来了。
levelworm
2022-03-27 23:47:34 +08:00
@Macolor21 #12
新手求问，如果能够让每个 feature branch 在合并之前都自动进行 rebase ，是好是坏？
Macolor21
2022-03-28 00:16:54 +08:00
@levelworm 有冲突的时候 rebase 不成功的，没冲突的情况下，rebase 没问题
815979670
2022-03-28 00:44:28 +08:00
看公司，如果这个项目是你单独维护，甚至可以直接 push main 分支，能解决冲突就好。
如果是多人协作 且你不是分支管理员 的情况下 通常使用 1.
但需要注意的是，无论哪种方案，冲突都是在本地解决的，不允许在线上（ web ）处理。
levelworm
2022-03-28 01:33:07 +08:00
@Macolor21 也是，看来还是冲突最麻烦。那么是否应该尽量从项目架构上去避免冲突？比如说尽量避免多人修改同一个文件的情况出现？虽然未必现实。。。
darknoll
2022-03-28 06:43:14 +08:00
把 main 分支更新下，然后重新 checkout 一个新分支，把修改加进去，然后用这个新分支发送 pr
wu67
2022-03-28 09:29:05 +08:00
当然是本地处理, 远程当成存档点来用. 我个人是倾向自己处理冲突合并的, 基本没 rebase 过.
nothingistrue
2022-03-28 09:58:02 +08:00
你说的 2 ，其实就是 1 ，只不过是把解决冲突的操作从本地搬到远程而已。2 发生冲突的时候，你并不是必须用远程仓库的工具，还可以本地在 feture 解决冲突并推送之后，再重新执行 MR/PR 的合并。MR/PR 开启之后，是可以继续提交的。

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

如果是用 rebase 来搞准线性历史的话，要用 1 的方式。
zhaol
2022-03-28 10:20:17 +08:00
@GeruzoniAnsasu 想问下，如果 rebase 的话，这个时候我的分支会有别人的 feature 或者 bugfix 的代码了，但是如果别人的 feature 这个版本不上，我的分支要上，怎么把别人的那部分拆出来？
libotony
2022-03-28 10:25:50 +08:00
@zhaol cherry-pick
stimw
2022-03-28 11:43:08 +08:00
冲突要在 rebase 解决，不要在 merge 时候再去解决冲突。。我一直记得这句话
cgdddd
2022-03-28 11:53:15 +08:00
我们公司要求,所有冲突必须要求本地解决,一律 request 的冲突全部打回

这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://ex.noerr.eu.org/t/843165

V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX