Question

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

所以，这就是我想象我的提交历史可能看起来的方式（箭头表示子提交，并且隐含了分支之间的箭头）：

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

在上述历史记录中，A和B代表我所做的功能（或更改）。在此历史记录中，我首先使用A，然后在完成A后，我开始B。很显然，有时候我会并行处理单独的新功能，但在这个假设的例子中（可能大部分时间在我的实际开发中），功能都是以连续的方式进行的。

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

（1）仅创建1个“新功能”分支（例如，测试）以与将用于开发A和B的主服务器一起运行是否有意义（（以及后续的新功能）？（如果是这样，我将如何管理在主设备和测试之间切换，将测试合并或重新设置回主设备，然后再次切换到测试以处理其他新功能的过程？）< / p>

（2）鉴于我是唯一的开发人员，在将新功能合并到master中时合并或更改会更有意义吗？我是git的新手，所以请解释原因。如果答案是“取决于”，请解释如何在两者之间作出决定。

Answer 1

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

如果您想要一张与上图相似的历史图表，则需要同时执行以下操作：
```
git checkout feature/foo
git rebase master
git checkout master
git merge --no-ff feature/foo
```
我在这里提出的唯一具体建议是，你不应该重写（改变）与他人分享的历史记录。

Answer 2

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

所以这里有一些来自该链接的假设：

Master始终保持100％的稳定。

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

对于每个功能，您从develop开始分支。

当该功能稳定时，您将功能分支合并为develop。

您测试为开发添加的所有功能，以确保您添加的所有功能都是稳定的你已经完成了彼此的功能。

然后在完全100％的情况下合并回主人。

1：假设'特征'A和B重叠，或者高度依赖于彼此，那么在同一分支中开发两者可能是明智的。如果他们不这样做，并且您在开发测试中遇到问题，您可以在调试时敲出功能作为诊断方法。这是你的电话。但是，如果比你想象的更进一步，你可能必须将开发合并到你的功能分支中，主要是因为其他人会提交可能与你当前分支冲突的东西，如果你带上其他人的话。

我个人喜欢每个分支都有一个功能，只需要做一些工作就可以将这些东西从开发回到你的分支。这确实需要一些工作，因为你必须从开发中获得变化。这是一个权衡，真的。

至于一个并行运行的功能：您可以拥有任意数量的功能分支。因此，如果您对目前正在处理的功能感到厌倦，那么只需从开发和创建新分支开始。您可以在开发之前解决开发中的任何合并问题。

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

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

我希望这有用。

针对单用户开发的Git合并/重新定位策略

2 个答案: