单用户开发的 Git 合并/变基策略答案

【问题标题】：Git merging/rebasing strategy for single user development单用户开发的 Git 合并/变基策略
【发布时间】：2013-05-14 06:41:19
【问题描述】：

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

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

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

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

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

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

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

【问题讨论】：

标签： c++ git branching-and-merging git-merge git-rebase

【解决方案1】：

为每个功能创建新分支。 Git 中的分支非常便宜（实际上只需将 41 个字节写入文件）并且易于管理。
这取决于，但没有你想象的那么多。无论哪种方式，您最终都会得到相同的代码。问题是你希望你的历史图表是什么样子。一直变基会导致线性历史；这很容易推理。使用合并提交进行分支会保留有关您何时启动功能以及何时将其相对于其他分支合并的信息。有时这些信息很有用，有时只是噪音。为了让事情更混乱，默认的 git merge 有时只会创建合并提交（如果可能，它会进行快进合并）。

如果你想要一个看起来像上面的图表的历史图表，你需要同时做：
```
git checkout feature/foo
git rebase master
git checkout master
git merge --no-ff feature/foo
```
我在这里得到的唯一具体建议是，您不应该重写（rebase）您与他人共享的历史记录。

【讨论】：

谢谢。那么，除了有一个可能“混乱”的历史树之外，在我的情况下一直使用合并对我来说没有问题吗？
git merge 很适合你。
当您说feature/foo 时，您只是在分支名称中使用正斜杠吗？还是您指的是某种分支？
前者； / 是分支名称中的有效字符。
谢谢。这很有帮助。

【解决方案2】：

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

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

Master 始终 100% 稳定。

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

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

特性稳定后，合并特性分支上去开发。

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

然后在 100% 的情况下合并回 master。

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

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

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

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

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

我希望这会有所帮助。

【讨论】：