关于 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

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

6510 次点击
所在节点    程序员
42 条回复
GeruzoniAnsasu
2022-03-28 12:08:36 +08:00
@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
2022-03-28 17:33:31 +08:00
理论上是 1,但是小公司菜逼多,都是让他们推上来发 PR ,我来解决冲突然后合并

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

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

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

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

© 2021 V2EX