使用rebase与merge将功能与master同步

Question

根据Atlassian的合并策略，最好使用--no-ff选项将功能分支合并回master。这在master上保持了一个干净的git历史记录，使您可以轻松地查看合并中所做的工作。考虑到这一点，当我将master合并到我的功能分支时，使用rebase或merge有关系吗？

---

数字合并

通常，我在处理master时会将其合并到我的功能分支中。这本质上是对master进行快照，并将这些更改放入我的分支中。(注意，我并不担心将功能合并回master，这里的重点是保持功能与master同步的工作流程(

---

数字重基础

将master重新绑定到特性分支中要干净得多，并添加了我在master头部的特性分支中所做的更改。

---

在这种情况下，重组与合并如何影响。。。

1. 将master同步到feature的过程
2. git在分支上工作时的历史记录
3. 分支与master合并并删除后的git历史记录

Answer 1

1. 使用rebase，您正在重新编写历史记录，因此您必须强制推送您的功能分支。如果您与其他人一起工作，请参阅(2(。

2. 每次运行rebase时，都有效地重写了该分支的历史记录。如果这是你自己的分支，并且没有人与你合作，这并不可怕，但如果多个开发人员对同一分支进行贡献，这可能会成为问题——特别是因为如果你重写了历史，他们的提交可能不会干净地推送。

3. 没有重新定基的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
   

   正如您所看到的，当您重新建立分支的基础时，历史可能会稍微不那么复杂，因此有些人更喜欢它。

---

一些额外的颜色：当我决定重新基础是否合适时，我经常会考虑我是否认为分支已经"发布"。"已发布"分支是其他开发人员可能已经完成工作的分支，并且可以合理地预期不会更改。"未发布"分支是我用来将更改组织为一个或多个提交的分支，并且尚未与其他开发人员共享。这是我作品的草稿。