请教下关于 git 的工作流

[kyonn]

以前用的 svn, 大概开发模式如下:

1. 从 trunk 分支拉出某个产品的开发分支 dev1(不同产品团队可以拉不同的 dev 分支).
2. 所有人在 dev1 分支上提交.
3. dev1 分支打 tag, 从 tag 出版本进行人工测试.
4. 测试通过将 dev1 分支 merge 回 trunk, 如果有其它 dev 分支提前合回了 trunk, 则需解决冲突.

了解过三种 git 工作流, 目前想这么做: 分支用 master 和 dev, 开发人员基于 dev 拉自己的 feature 分支, 开发完成后基于 dev 做 rebase, 然后提 MR, 审核通过后代码 merge 进入 dev 分支. 等开发完成后, 基于 dev 去出版本测试, 测试通过后再将 dev merge 回 trunk. 个人的疑问是 dev 分支如何 merge 回 master? 如果 dev 也要基于 master 做 rebase 后再提 MR, 那么就违反了公共分支不能 rebase 的原则. 如果 dev 先 merge master 解决冲突后再提交 MR, 又会导致 master 历史非常乱.

ps: 我们的产品必须人工测试, 不能用基于主干开发的模式. 另外, 不同团队可能同时在开发不同产品, 所以用不同的 dev 分支隔离彼此是必要的.

[oppoic]

老图了，参考参考，几个人开发还是怎么简单怎么来

[unco020511]

我说说我们的,三个分支 main->dev->feature
main 用作发布分支,当要开发一个新版本时,从 main 拉一个 dev-version,各个版本要带出的功能由开发自己拉 feature 分支,某个功能开发完成后,在 feature 分支提测,测试通过后合并入 dev-version,等待这个版本的所有 feature 合入 dev-version 后,对 dev-version 进行版本测试(主要排除多个新功能间可能引发的问题),然后将 dev 合到 main,在 main 上出 xxx 版本的发布包.
开发下一个版本,从 main 拉新的 dev.....

[kyonn]

@unco020511 我想的也是这个策略. 我的疑问是 dev 修改合入 main 分支出现冲突时, 如何解决该冲突.
有两种处理策略:
1. dev 分支先 rebase onto main, 解决完冲突后提交 MR 或者 PR 给 main 分支(dev 和 main 历史清晰, 但是 dev 历史被重写).
2. dev 分支先 merge main 分支, 解决完冲突后提交 MR 或者 PR 给 main 分支(main 和 dev 历史会比较乱, 因为 dev 和 main 相互 merge).
不知道你们那边是如何处理的?

[Xheart]

@unco020511 我这也是这种流程

[statumer]

@kyonn #7 不会破坏。先创建一个临时分支指向 dev 。然后临时分支 rebase onto master 。解决冲突后，让 master 指向临时分支。

```
o------o------o trunk
\
o---o dev

创建临时分支 feat-pending
o------o------o trunk
\
o---o dev, feat-pending

rebase （处理冲突） 后
trunk
o------o------o----o'----o' feat-pending
\
o---o dev

fast forward
o------o------o----o'----o' trunk, feat-pending
\
o---o dev

移除临时分支 feat-pending
o------o------o----o'----o' trunk
\
o---o dev

可以看到全程和 dev 无关。
```

[kyonn]

@statumer 了解了, 相当于复制了 dev 分支, 用复制的分支去做 rebase 操作. 再请教下, master, dev, feature 倾向于用同一个仓库吗? 换句话说, 什么时候要 forking ?

[statumer]

@kyonn #26 用 gitlab 这种可以设置 protected branch 的 git 系统不需要 fork 。fork 不利于维护 single source of truth 。

[kyonn]

@statumer 了解了，多谢

[unco020511]

@kyonn #23 dev 合 main 是单向的怎么会有冲突呢,各个 feature 之间的冲突在 feature into dev 时就已经解决,每个 feature 自己怎么玩都可以,但在 mr 时要确保解决完冲突,且 mr 勾选 Squash commits .

其实不管是哪种模型,原则都是差不多的:
1. 主干都是受保护的,仅接受 mr 合并,且一般只有开发和测试 leader 有权限,mr 要求审核
2. feature 分支各个开发随便玩,但 mr 之前要预先解决冲突,冲突要确定影响面给到测试
3. 如果多个 feature 在同时开发中且有共用改动代码时(一般很少),采用 pick

[kyonn]

@unco020511 多个团队同时在开发会有多条 dev, 先合入主线的 dev 不会有冲突, 但是后合入的会有冲突.