我通常更喜欢rebase，因为它具有清晰的历史记录(至少在master分支上(。
看看git-flow，它需要来处理合并提交。这感觉很难看/不整洁，因为所有的合并提交(我通常会重新基准(，但也因为与同一代码相关的多个合并提交(ui-feature1合并到ui-development，然后合并到development，然后合并为master；即使没有ui-development分支也是如此(。
相反，Rebase会更干净/更漂亮，但它会创建重放的重复提交，所以：
- 了解从哪里分支更为复杂(分支分化风险的原因(
- 需要进行额外的维护(某些分支将始终重新建立在中，而其他分支则需要删除并重新创建(
- 像Redmine这样的系统(其Issues/Ttickets可以在提交消息中列出通过
refs #redmine-issue引用它们的所有相应的存储库提交(将在ref在第一个源提交中出错时显示源和基于的重新提交
有中间的方法吗？有什么方法可以很好地集成git flow，但仍然在提交消息中引用Redmine问题？
git rebase如何使用git flow？是否有其他有效的git工作流支持rebase而不是merge？是否可以在不进行合并提交的情况下遵循git flow？
在将rebase功能分支合并到develop或master之前，可以将其合并到相应的分支上，如下所示：
git checkout feature/my-super-feature
git rebase develop
git checkout develop
git merge feature/my-super-feature
因此，您的git-flow中会有更干净的历史记录，但它仍然有成本，就像任何rebase一样，它正在重写历史记录，在这种情况下仅用于最后提交。因此，你可以在干净的历史和丰富的信息之间找到民谣。我自己只在功能分支上使用rebase最后一次提交来压缩一次提交中的修复：
git rebase -i --autosquash HEAD~2
使用merge --squash合并功能分支的另一个选项。它是最"干净"的，但你释放了你所有的承诺。有时它是有用的。