求问 git 流程设计问题

[levelworm]

我们组是做数据工程的，git 流程总是有问题。请教一下怎么设计比较好？

因为数据工程经常需要迅速、改动小的变动，所以我们没有 tag 和 release branch 。每次做开发的流程都是这样：

1. 从 main 创建 feature branch
2. feature branch 开发结束之后 merge 到 preprd
3. 测试结束之后，preprd merge 到 main

目前我们很少有冲突，这点还蛮好的，因为项目划分的还可以，极少碰到两个人修改一个文件的问题。但是很难解决preprd和main同步的问题，所以经常出现不知道为什么preprd merge 到 main的时候，会把很早的 commit 也合并进去的问题。当然这并不是致命的问题，所以团队很久都没有解决，我也是最近加入才发现这个问题的。我猜测是因为有些同事直接把 feature 分支 merge 到 main 导致的，但是我也不是 git 专家，所以也不确定。另外我们从来不用 rebase ，只能用 merge ，我觉得也不是很好，但是说不出来为什么不好。

最近我们加了一步，就是 2 和 3 之间让main 反向 merge 到 preprd。这似乎解决了问题，但是我又觉得十分的丑陋。不知道大家有没有什么好的设计方案？或者说，我究竟应该怎么排查问题？我翻了下 gitbook ，感觉里头介绍的十分详尽，反而搞不清楚应该如何排查了。

多谢！

[weixind]

你们这个流程如果单 feature 分支的话，理论上 preprd 到 main 的合并应该是 fast forward 。
出现的原因应该这样子：featureA 和 featureB 从同一个 commit 拉出。featureA 或者其他 feature 合并到 main 了。featureB 转到 preprd 以后，commit 和 main 是乱的。如果要解决，不改变大的流程的话，可以 feature -> preprd 以前 rebase 下 main 。preprd 应该是个多次使用的临时分支。

[declandragon]

设置不能 push master ，只能通过 merge request ，专人或者轮岗审核 MR

[chf007]

main 要保护起来啊，只能某一个人能操作

[U2Fsd]

“ main 反向 merge 到 preprd 。这似乎解决了问题，但是我又觉得十分的丑陋。 ”

保护 main 分支，开发分支合并前 rebase main, Gitlab 仓库设置为 Fast-forward merge

[DCNGAWE]

有没有了解过 git flow 命令呢

[csys]

这个情况下你们实际上有了两个主干分支 preprd 和 main
我觉得可以思考两个问题：
1. 为什么 preprd 还要合并到 main 分支？
2. 为什么还需要 main 分支？

既然已经在 preprd 上进行了测试，那么 preprd 就是一个可靠的分支，相反，如果它合并到 main 上会导致 main 上的代码成为未测试过的代码

[xliao]

看你的描述吧，应该是哪两个主干分支 merge 出的问题。

一般是 feature branch 开发完，创建 MR 合并到 preprd ，测试成功后再来 cherry-pick 到 main

[levelworm]

@weixind 多谢，我研究一下 githook ，看看能不能自动化。不过还是想好好研究一下 git ，看看到底是怎么回事。。。

[levelworm]

@declandragon 多谢。我们这里有点松，的确不太好。

[levelworm]

@U2Fsd 多谢，我去研究一下 fast forward merge 。我是 GitHub ，好像只看到过 merge 和 rebase 。

[levelworm]

@DCNGAWE 我看过了，但是那个 release 分支的确不适合我们。我们基本上每个 task 都能算是个 release ，哪怕是改一行代码，也必须尽快上生产环境。