根据Atlassian的merge strategy，最好使用--no-ff选项将feature branches合并回master。这将在master上保留干净的git历史记录，使您可以轻松查看在合并中完成的工作。考虑到这一点，在将master合并到功能分支中时是否使用rebase或merge 是否重要？
通常，我在处理母版时将其合并到功能分支中。这本质上是制作master快照并将这些更改放入我的分支中。 （请注意，我不必担心将功能重新合并到主机中，这里的重点是保持功能与主机同步的工作流程）
将master迁移到Feature分支的方法更加简洁，并在master的顶部添加了我在Feature分支中所做的更改。
在这种情况下变基还是合并会如何影响...
答案 0 :(得分：1)
通过重新设置基础，您正在重写历史记录，因此您必须强制按下功能分支。如果您正在与其他人一起工作，请参阅（2）。
每次运行基准库时，实际上都是在重写该分支的历史记录。如果这是您自己的分支，并且没有人与您合作，这并不可怕，但是如果多个开发人员在同一个分支中做出贡献，则可能会出现问题-特别是因为如果您重写了历史记录，他们的提交可能不会干净地推送
Git历史记录，无需重新设置基础
* master
|\
| * branch commit 2
|/|
* | simultaneous commit on master
| * branch commit
|/
* previous commit on master
与重新定基：
* master
|\
| * branch commit 3
| * branch commit 2
| * branch commit
|/
* simultaneous commit on master
* previous commit on master
如您所见，重新设置分支基础时，历史记录可能会稍微复杂一些，因此有些人喜欢它。
一些其他颜色：当我决定是否适合使用变基时，我经常会考虑是否认为该分支已经“发布”。 “已发布”分支是其他开发人员可能已经完成的工作，并且可以合理地期望不会改变。 “未发布”分支是我用来将更改组织到一个或多个提交中的分支，尚未与其他开发人员共享。这是我的工作草稿。