1

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

所以，这就是我想象的提交历史的样子（箭头表示子提交，分支之间的箭头是隐含的）：

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

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

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

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

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

4

2 回答 2

3
  1. 为每个功能创建新的分支。Git 中的分支非常便宜（实际上只是将 41 个字节写入文件）并且易于管理。

  2. 这取决于，但没有你想象的那么多。无论哪种方式，您最终都会得到相同的代码。问题是你希望你的历史图表是什么样子。一直变基会导致线性历史；这很容易推理。使用合并提交进行分支会保留有关您何时启动功能以及何时将其相对于其他分支合并的信息。有时这些信息很有用，有时只是噪音。为了让事情变得更加混乱，默认设置git merge仅有时会创建合并提交（如果可能，它将进行快进合并）。

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

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

    我在这里唯一的具体建议是，您不应该重写（变基）您与他人共享的历史记录。

于 2013-05-19T17:17:20.813 回答
2

我们在我的工作地点使用这个模型，我认为它效果很好： http: //nvie.com/posts/a-successful-git-branching-model/

因此，以下是该链接的一些假设：

Master 始终始终 100% 稳定。

当开发稳定并完成时，大师从开发中获得合并。

对于每个功能，您从开发中创建一个分支。

当功能稳定时，您将功能分支合并到开发中。

您测试添加到开发中的所有功能，以确保您添加的所有内容与您完成的其他功能保持稳定。

然后在全部 100% 时合并回 master。

1：如果“特征”A 和 B 显着重叠，或者相互高度依赖，那么在同一个分支中开发两者可能是明智的。如果他们不这样做，并且您在开发测试中遇到问题，您可以在调试时将功能剔除作为一种诊断方法。它是你的电话。但是，如果开发超出您的想象，您可能必须将开发合并到您的功能分支中，主要是因为如果您让其他人加入，其他人将提交可能与您当前分支冲突的内容。

我个人喜欢每个分支都有一个功能，只需一点点工作就可以将开发中的东西重新放到您的分支中。有时这确实需要一些工作，因为您必须从开发中获得更改。这是一个权衡，真的。

至于让一个功能并行运行：您可以拥有任意数量的功能分支。因此，如果您对当前正在开发的功能感到厌烦，只需从开发中创建一个新分支并继续开发。您在开发中解决任何合并问题，然后再进入主控。

2：我们不能在您指定的上下文中使用 rebase，因为我们正在与其他人共享我们的分支。我说只是使用合并，所以如果您确实将其他人带入混合中，瞧，没有麻烦。还有这个：

http://www.jarrodspilers.com/2009/08/19/git-merge-vs-git-rebase-avoiding-rebase-hell/

我希望这是有帮助的。

于 2013-05-19T17:24:55.020 回答