前后差异较大的分支维护和合并的正确策略是什么
What is the right strategy of maintaining and combining branches with big differences in behind and ahead
目前我正在维护两个分支。源分支及其派生。它们必须同步，因为将来它们将被合并。政策是每两周同步/合并分支。如您所见，'fork' 落后 97，领先 217。
我尝试先在团队资源管理器中将一个合并到另一个，反之亦然，但它们都是最新的。拉取请求有很多合并冲突。不是问题，因为我会解决它们。但是，当两个分支都是最新的时，我该如何解决合并问题。
What is the right strategy of maintaining and combining branches with big differences in behind and ahead
恐怕没有这样正确的策略来维护和合并前后差异很大的分支。
合并分支时代码冲突是不可避免的。如果一个分支中包含的behind和ahead之间存在冲突，我们必须手动解决。
为了减少解决冲突的时间，我们可以尝试提高开发的敏捷性，将合并周期提高到一周或更短。
tl;dr: 为了维护 Fork/development，如果可能的话，我更喜欢 rebase 策略，并在无法进行 rebase 的循环中回退到合并策略（可能永远如此）。
这是您典型的两周周期的细目分类。你总是可以开始于：
- 将
Fork/development 合并到 development。这可能最好通过使用 SCM 的 Pull/Merge 请求来完成，但如果不是，从概念上讲它类似于这些命令：
git checkout development
git pull
git merge --no-ff Fork/development # resolve conflicts if needed
- 现在从
development 中删除并重新创建 Fork/development，以便重新开始。这可以通过这些命令来完成（假设你的遥控器被称为“origin”）：
git fetch
git checkout Fork/development
git reset --hard origin/development
- 在步骤 2 之后，
development 和 Fork/development 是等效的（已同步）。现在在 Fork/development 中使用变基策略或合并策略在接下来的两周内工作。 （差异解释如下。）
在你的两周周期中，个人偏好选择哪种方式，但根据评论，作为唯一承诺 Fork/development 的人，我觉得你可以对待 Fork/development 就像一个恰好持续存在的常规功能分支。在这种情况下，我建议使用变基策略使其与 development 保持同步，直到下一次在两周内将其合并回 development。如果您能够使用此策略，您典型的一天可能是这样的：
git fetch
git checkout Fork/development
git rebase origin/development # resolve any new conflicts if there are any
# Commit
# Commit
# Commit
# etc.
请注意，这仅在您在 Fork/development 中没有您需要保留的任何新合并提交时才有效，但如果您直接提交到分支中，您通常不会有合并。只要保持经常变基，这样如果出现冲突，您就可以及早处理并更容易解决。当我有很长的 运行 特性分支时，我通常每天多次变基到（我们所说的）origin/develop。另一件有助于保持分支清洁的事情是定期进行交互式变基。在典型的一天中，我可能会创建 20 个提交，并且在一天结束时，我将使用交互式变基（rebase -i）来重新排序并将这些提交压缩到，比如说，在变基到 origin/develop。两周后，我可能已经提交了数百次，但到我创建拉取请求时，我的“完美”提交可能还不到 10 次。根据您的每个提交内容，这可能对您有用，也可能不适合您。变基策略的最大缺点是，如果您经常遇到冲突，则当变基到 origin/development 时，您将不得不更频繁地解决它们，并且可能在单个提交中，因为它会重播您在分支上的所有提交。在第 13 天标记处，如果您有 100 次修改相同文件的提交，您可能必须为单个 rebase 多次解决冲突（尽管可能首先在那里进行有意义的挤压可以减轻痛苦）。另一件有助于启用变基策略的事情是，当在分支变基过程中出现冲突时，解决它们，然后很快将您的分支合并回 development。显然，只有在允许您在 2 周标记之前同步分支的情况下，您才能这样做。
如果可以的话，我强烈建议使用分支和交互式变基策略，但如果由于某种原因你不能，那么你将不得不改为执行合并策略。合并策略与您的同事提供的类似，即定期将 development 合并到 Fork/development，然后每两周使用上面的 #1 和 #2 以相反的方式进行。
目前我正在维护两个分支。源分支及其派生。它们必须同步，因为将来它们将被合并。政策是每两周同步/合并分支。如您所见，'fork' 落后 97，领先 217。
我尝试先在团队资源管理器中将一个合并到另一个，反之亦然，但它们都是最新的。拉取请求有很多合并冲突。不是问题，因为我会解决它们。但是，当两个分支都是最新的时，我该如何解决合并问题。
What is the right strategy of maintaining and combining branches with big differences in behind and ahead
恐怕没有这样正确的策略来维护和合并前后差异很大的分支。
合并分支时代码冲突是不可避免的。如果一个分支中包含的behind和ahead之间存在冲突，我们必须手动解决。
为了减少解决冲突的时间，我们可以尝试提高开发的敏捷性，将合并周期提高到一周或更短。
tl;dr: 为了维护 Fork/development，如果可能的话，我更喜欢 rebase 策略，并在无法进行 rebase 的循环中回退到合并策略（可能永远如此）。
这是您典型的两周周期的细目分类。你总是可以开始于：
- 将
Fork/development合并到development。这可能最好通过使用 SCM 的 Pull/Merge 请求来完成，但如果不是，从概念上讲它类似于这些命令：
git checkout development git pull git merge --no-ff Fork/development # resolve conflicts if needed
- 现在从
development中删除并重新创建Fork/development，以便重新开始。这可以通过这些命令来完成（假设你的遥控器被称为“origin”）：
git fetch git checkout Fork/development git reset --hard origin/development
- 在步骤 2 之后，
development和Fork/development是等效的（已同步）。现在在Fork/development中使用变基策略或合并策略在接下来的两周内工作。 （差异解释如下。）
在你的两周周期中，个人偏好选择哪种方式，但根据评论，作为唯一承诺 Fork/development 的人，我觉得你可以对待 Fork/development 就像一个恰好持续存在的常规功能分支。在这种情况下，我建议使用变基策略使其与 development 保持同步，直到下一次在两周内将其合并回 development。如果您能够使用此策略，您典型的一天可能是这样的：
git fetch
git checkout Fork/development
git rebase origin/development # resolve any new conflicts if there are any
# Commit
# Commit
# Commit
# etc.
请注意，这仅在您在 Fork/development 中没有您需要保留的任何新合并提交时才有效，但如果您直接提交到分支中，您通常不会有合并。只要保持经常变基，这样如果出现冲突，您就可以及早处理并更容易解决。当我有很长的 运行 特性分支时，我通常每天多次变基到（我们所说的）origin/develop。另一件有助于保持分支清洁的事情是定期进行交互式变基。在典型的一天中，我可能会创建 20 个提交，并且在一天结束时，我将使用交互式变基（rebase -i）来重新排序并将这些提交压缩到，比如说，在变基到 origin/develop。两周后，我可能已经提交了数百次，但到我创建拉取请求时，我的“完美”提交可能还不到 10 次。根据您的每个提交内容，这可能对您有用，也可能不适合您。变基策略的最大缺点是，如果您经常遇到冲突，则当变基到 origin/development 时，您将不得不更频繁地解决它们，并且可能在单个提交中，因为它会重播您在分支上的所有提交。在第 13 天标记处，如果您有 100 次修改相同文件的提交，您可能必须为单个 rebase 多次解决冲突（尽管可能首先在那里进行有意义的挤压可以减轻痛苦）。另一件有助于启用变基策略的事情是，当在分支变基过程中出现冲突时，解决它们，然后很快将您的分支合并回 development。显然，只有在允许您在 2 周标记之前同步分支的情况下，您才能这样做。
如果可以的话，我强烈建议使用分支和交互式变基策略，但如果由于某种原因你不能，那么你将不得不改为执行合并策略。合并策略与您的同事提供的类似，即定期将 development 合并到 Fork/development，然后每两周使用上面的 #1 和 #2 以相反的方式进行。