Rebase 或合并到 Develop 分支？ （小团队）

Question

我在一个由 5 名开发人员组成的小团队中工作。我们正在努力弄清楚如何使我们的开发分支尽可能保持清洁和污染更少。 到现在为止，我们一直在做这个流程：

1. 完成功能（压缩所有提交）
2. 结帐以开发分支
3. 从原点拉开发
4. 将功能分支合并到开发中（如果有冲突则解决）
5. 将更改推送到 origin/develop

问题是这通常会导致创建一个新的 "merge...onto dev" 提交，并创建有点令人困惑的菱形，即使只有 5 个开发人员也是如此。

有没有更好的流程，也许使用变基，来保持开发分支尽可能的干净和直？

此致

Answer 1

长话短说：

• 合并：当你在共享分支上取回功能分支时
• rebase：仅用于 local/development 分支（git pull --rebase 或 git rebase）
的维护

所以进入细节。

当我从 svn 转到 git 时，我对图形日志的复杂性感到震惊，在使用了多年的平面 svn 历史记录之后，阅读起来似乎很糟糕。但是图表是 git 的组成部分，日志中的复杂性也随之而来。

为了回答您的问题，我认为您需要继续在开发中合并您的功能分支，因为它对您的历史有意义：

• 你可以看到什么时候分叉
• 您可以看到该功能涉及哪些提交
• 您可以看到该功能何时合并回公共池

关于变基，您绝对必须避免 在public/shared 分支上进行。因为它经常重写你的历史，丢失信息的风险很高，你的远程存储库将很快与你伙伴的存储库不同步。如果您需要在共享分支上执行 git push --force，那么您处于危险区域。

我可以预先确定你做 rebase 只是为了用远程存储库更新你的本地分支。如果不这样做，更新确实会创建无用的合并提交，这会使您的历史变脏。

因此，仅使用 git pull --rebase 更新您的分支，并使用旧的经典 git 合并恢复您的功能。

更新后的流程将是：

1. 完成功能（如果需要，压缩所有提交）
2. 使用 git pull --rebase 更新功能分支（如果有冲突解决）
3. 结帐以开发分支
4. 从原点拉取开发（使用 git pull --rebase 用于更新目的）
5. 将功能分支合并到开发中（如果有冲突解决）
6. 将更改推送到 origin/develop

通过一些练习，您会更加适应“菱形”。

我个人使用 gup 别名 git pull --rebase 来强制我在每次更新时使用 rebase。

希望对您有所帮助。

朱利安。