Git master和开发不同步答案

【问题标题】：Git master and development out of syncGit master和开发不同步
【发布时间】：2019-10-22 03:39:35
【问题描述】：

我有一个 master 和 development 分支。主（服务器）存储库托管在 Azure Devops（本地）中。我为我的开发分支中的更改做了两个拉取请求（从功能分支到开发）。

PR1：feature-branch-1 -> 开发

PR2：feature-branch-2 -> 开发

然后我想，我需要将我的开发分支与我的主分支同步，所以我从我的开发分支向我的主分支发出了拉取请求，接受，提交。

PR3：开发 -> 大师

现在是说我的开发分支是“落后1，领先主人2”

将开发与 master 进行比较显示了我的两个功能 Pull Requests。将 master 与 development 进行比较显示我的合并 PR 以同步分支。

在我的过程中我做错了什么，我该如何解决这个问题 - 让它们同步？

【问题讨论】：

标签： git tfs azure-devops

【解决方案1】：

您所做的过程是正确的，但取决于您选择的以下情况之一。

执行 PR 合并时，您选择了“合并”，这将在目标（主）分支上创建合并提交。因此，Master 领先于开发 1。
当您执行 PR 合并时，您选择了“Squash”，在这种情况下，它将使用对目标（主）分支的更改创建一个新的提交。此 Master 提前 1 次提交，落后 2 次提交。
当您执行快进时，如果不需要合并，目标和源分支现在将是相同的。并且不会添加任何合并提交。
当您将开发重新定位到 master 上时，所有更改都将在 master 分支上重放，然后提交。在这种情况下，您必须强制推动开发。

为确保 develop 与 master 重新同步，您有几个选择：

合并 master 以进行开发。之后，develop 将在 master 之前进行 1 次合并提交。
将开发重新定位到主控并强制推送。开发将与大师相同+任何未完成的更改将在开发之上重播。
重置开发以掌握并强制推送。 Develop 将与 master 相同 + 任何未完成的更改都将丢失。
删除/重命名当前的开发分支并从 master 创建一个新分支。

【讨论】：

Azure DevOps 允许应用分支策略，并且 master 和 development 都有一个分支策略来“强制执行合并策略”的 Squash Merge。
在两个相关分支上进行 squash 合并会导致此类问题。
@jesshouwing 你有更好的设置我可以使用吗？我全神贯注，试图让这个标准化
在合并开发之前，我倾向于在本地或我的功能分支上进行大部分压缩。这样，拉取请求对 squash-merge 的需求就少了很多。然后，您可以从 master 到 development 进行正常合并。由于 Git 的工作方式，您通常最终会认为 master 是 1-commit-ahead（合并提交），除非您执行快进合并。这是意料之中的。

【解决方案2】：

现在它说我的开发分支是“落后 1 和领先 2” 大师”

将开发与大师进行比较显示了我的两个功能拉取请求。将 master 与 development 进行比较显示我的合并 PR 以同步分支。

你的操作没有错误，答案(1 behind and 2 ahead of master)也是正确的。

首先，您需要知道“Squash Merge”是什么意思。

让我们为这些提交命名：从 feature-branch-1 到 Development 的合并提交是 A。从 feature-branch-2 到 Development 的提交是 B。从 Development 到 Master 创建的合并提交是 C。

在使用Squash Merge 将 feature-branch-1 合并到 Development 时，它将创建新的提交 A'。事实上，与他们的内容相比，A 和 A' 之间没有任何区别。但是功能分支本身没有将其合并到默认分支的提交。

所以，遵循这个逻辑。当您执行合并开发到 Master 时，它将创建一个新的提交 C'。合并后，在 Master 分支中，它只是添加一个新的提交 C'，而不是 C。这就是为什么您以1 behind and 2 ahead of master 的身份排在后面|。

将比较分支改为Development，你会看到feature-branch-1和的behind|ahead feature-branch-2 是 2|1。这都是因为 Squash Merge。

Squash Merge 的优势在于保持您的默认分支历史干净且易于遵循，而无需对您的团队进行任何工作流程更改。

但如果您想让它们与历史同步，请将您的合并类型更改为 基本合并。

【讨论】：

我想保护我的主分支，以便需要通过拉取请求完成热修复，然后我会将其合并到开发中，但我希望开发和主同步。也许 PR 合并政策是不必要的，PR 只需要成为一种商业惯例。或者我需要在将 dev 合并到 master 时将其关闭
知道了。如果选择Basic Merge，您仍然可以设置分支策略来保护master或其他分支。只需在完成pr时选择基本合并即可。
分支策略设置为 Merge Strategy Squash Merge，当我完成 PR “Squash changes when merging”被选中并禁用（我无法更改）。或者您可能是说在 PR 之外以某种方式执行此合并？
不，如果您想在完成 pr 时使用基本合并，则必须修改分支策略，更改限制合并类型并选择基本合并（无快进）。另一种方式，如果你可以改变权限设置，你可以去项目设置->存储库->（项目名称）->主分支->设置完成拉取请求时绕过策略为允许（这个可以绕过分支策略的限制）。
对不起，不适合我。我将安全设置为覆盖两个分支。合并 dev -> master，覆盖，未经检查的壁球。 master 领先 dev 2。然后将 master 合并到 dev，相同的设置，dev 现在领先 master 1。