长时间停顿后恢复功能开发

Question

我正在开发一个系统作为一个小团队（3 人）的一部分。该开发已经运行了几年，可能还有一年左右的时间。我们使用 git 进行版本控制，一般在master 上进行开发，使用pull 和push。

大约六个月前，当我大约 75% 完成了一项新功能的开发时，项目优先级发生了变化，我需要开始开发第二个功能。在开始新的开发之前，我将大部分未完成的开发提交给了一个新的分支 - parked。第二个功能变成了第三个和第四个 - 我相信你对这个场景很熟悉。

我们现在几乎准备好恢复第一个功能的开发，我想恢复停放的代码。同时，我们已经向部分不需要（原始）首发功能的用户预发布了该系统。

我的直觉是将主干中的更改合并到 parked 分支上

$ git checkout parked
$ git merge origin/master

以便在我们支持master 上的外部用户的同时有地方继续/完成开发并解决任何问题。最终（我希望很快）我会将更改从 parked 合并回 master。

我在 stackoverflow 上发现了其他几个似乎处理类似问题的问题。 Version control - which way to git merge 建议最初从parked 合并到master，以便允许使用git log --first-parent；我们目前没有广泛（任何）使用这个命令——我们是否遗漏了一些可能有用的东西？ Which way to merge with git 推荐使用git rebase；另一个我们目前不使用的命令 - 我们应该使用吗？

在开始这个项目之前我从未使用过 git，但我相信我熟悉版本控制概念。

我仍然倾向于遵循我的第一直觉，从master 合并到parked 开始；在那里完成开发，然后将更改合并到master，但我看到有有效的替代方案。我目前不了解替代方案的优缺点 - 请有人解释一下。

Answer 1

您的问题与您链接的问题之间的区别在于parked 尚未完成。当一个特性完成后，按照问题的建议去做：将你的特性分支合并到主分支。另一方面，当您想使用 master 中的所有功能更新您当前的工作时，您应该采取另一个方向：将 master 合并到功能分支中。这使您可以确保您的工作与现有功能兼容。它还可以让您尽早管理可能的合并冲突。

我们使用 git 进行版本控制，通常在 master 上进行开发，使用 pull 和 push。

我建议您为将来的开发创建功能分支。这有助于隔离工作，直到它被认为“完成”。完成该功能后，将其合并到master。有关功能分支的一种可能用途，请查看我们姊妹网站 Software Engineering 上的 this Q&A。

Answer 2

所以你是从这种情况开始的：

A - B - H - I - J - K - L - M - N - O master & origin/master
      \ C - D - E - F - G parked

现在通过合并parked，您将创建这种情况：

A - B - H - I - J - K - L - M - N - O - P master, origin/master & parked
      \ C - D - E - F - G -------------/

这意味着您的开发分支master 中将有未完成的、不可发布的工作，如果它要持续很长时间，这并不理想，因为它使从门。这种方法的一大优势是消除了进一步合并冲突的风险，并允许您立即使用parked 中可能在代码库其他地方有用的任何组件。处理不可发布代码的一种方法是feature flag。

或者，通过将 origin/master 合并到 parked 现在您将创建这种情况：

A - B - H - I - J - K - L - M - N - O  master & origin/master
      \ C - D - E - F - G -----------\ P parked

您将在最新的代码库中使用您的功能 1，但会给您留下稍微混乱的历史记录，尤其是当您将 parked 分支合并回 master 时：

A - B - H - I - J - K - L - M - N - O - Q --- S master
      \ C - D - E - F - G -----------\ P - R /

这真的不算太糟糕，但我们可以通过重新定位到 origin/master 而不是合并来使它更整洁，这将导致：

A - B - H - I - J - K - L - M - N - O ------------------/ U master & origin/master
                                     \ P - Q - R - S - T parked

这种方式不需要任何特征标记，并保持所有特征1在单个合并中一起工作，可以使用git log --first-parent在日志中折叠。如果您知道要查看（或不想查看）哪个功能，那么有时可以更轻松地阅读历史记录。

变基的不利之处在于您正在改写历史，您不再能够准确反映所发生的事情。您的 feature1 提交将被重写，实际上将是新的提交；之后每个人都必须git reset --hard origin/parked 以获得一致的历史记录，并且他们需要注意不要在此过程中丢失任何未提交/未推动的工作。

最终，正确的方法取决于你的工作方式、有多少人在使用 repo，以及你对 git 的熟悉程度。