Rebase还是Merge into Develop分支？ （小团队）

Question

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

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

问题在于，这通常会导致创建一个新的＆＃34;合并...到开发＆＃34;提交，并创建钻石形状，这有点令人困惑，即使只有5个开发人员。

是否有更好的流程，可能使用rebase，以保持开发分支更清洁，尽可能直接？

祝你好运

Answer 1

TL; DR：

• merge：当您在共享分支上返回功能分支时
• rebase：仅用于维护本地/开发分支（git pull --rebase或git rebase）

所以详细了解。

当我从svn传递给git时，我被图形日志的复杂性所震撼，在使用平面svn历史记录多年后看起来很糟糕。但是图形是git不可或缺的一部分，日志的复杂性随之而来。

要回答您的问题，我认为您需要继续合并您的功能分支，因为它会为您的历史带来感觉：

• 你可以看到分支何时分歧
• 您可以看到哪些提交与功能相关
• 您可以看到该功能何时合并回公共池

关于rebase，你绝对必须避免在公共/共享分支上执行此操作。因为它经常重写您的历史记录，丢失信息的风险很高，您的远程存储库很快就会与您的配合存储库不同步。如果您需要在共享分支上执行git push --force，则您处于危险区域。

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

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

更新的流程将是：

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

通过一些练习，您可以更轻松地使用＆＃34;钻石形状＆＃34;。

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

希望它有所帮助。

于连。