c++ - 用于单用户开发的 Git merge/ rebase 策略

Question

我正在为一个 C++ 项目使用 git，而且我是唯一的开发人员。除了维护代码历史之外，我使用 git 是因为我希望能够在不修改原始代码的情况下测试新功能，直到我准备好将新功能 merge 到原始代码中。我正在使用 Github，但我是唯一的开发者。

所以，这就是我想象的我的提交历史的样子(箭头表示子提交，并且暗示分支之间的箭头):

         A1 ---> A2 ---> A3        B1 ---> B2
         /                \        /        \
X1 ---> X2  ----------->  X3 ---> X4 -----> X5 ---> (...)

在上面的历史中，A 和B 代表我所做的功能(或更改)。在这段历史中，我首先在 A 上工作，然后在完成 A 之后我开始了 B。显然，有时我会同时处理单独的新功能，但在这个假设的例子中(可能在我的实际开发中的大部分时间)，功能是以串行方式处理的。

在这种情况下，我有两个相关的问题。我认为将这两个问题 merge 到一个 SO 帖子中是合适的。

(1) 仅创建 1 个“新功能”分支(例如，测试)以与将用于开发 A 和 的 master 一起运行是否有意义B(以及后续的新功能)？(如果是这样，我将如何管理在 master 和测试之间切换，将测试 merge 或 rebase 回 master，然后再次切换到测试以继续工作的过程另一个新功能？)

(2) 鉴于我是唯一的开发人员，在将新功能 merge 到 master 中时 merge 或 rebase 是否更有意义？ 我是 git 的新手，所以请解释原因。如果答案是“视情况而定”，请解释如何在两者之间做出决定。

Answer 1

1. 为每项功能创建新分支。分支在 Git 中非常便宜(字面上只是将 41 个字节写入一个文件)并且易于管理。

2. 这取决于情况，但并不像您想的那么多。无论哪种方式，您最终都会得到相同的代码。问题是您希望您的历史图表看起来像什么。始终进行 rebase 导致线性历史；这很容易推理。使用 merge commits 进行分支会保留关于何时开始一项功能以及何时将其 merge 到其他分支的信息。有时这些信息很有用，有时只是噪音。让事情变得更加困惑的是，默认的 git merge 有时只会创建 merge 提交(如果可能，它会进行快进 merge )。

   如果您想要一个看起来像上面图表的历史图表，您需要同时执行以下两个操作:

   git checkout feature/foo
   git rebase master
   git checkout master
   git merge --no-ff feature/foo
   

   我在这里唯一的具体建议是您不应该重写( rebase )您与他人分享的历史。