Git 发布分支上的流程混乱
Git Flow Confusion On Release Branch
我想了解 git 流程中的一件事。假设我们有这样的分支树
在这种情况下，我通过分别向 master 和 dev 打开 PR 来合并我的发布分支。我将 PR 与 using
合并
git merge --squash
命令。合并结束时，我有两个不同的提交 ID
master有D1234
开发者有 C4567
我的困惑从这里开始。如果 master 和 dev 没有相同的提交哈希，在从发布分支到 master 的下一个 PR 中，我将在 PR 中看到 C4567。我不得不合并一个没有差异的空提交。我哪里做错了？ master 和 dev 合并后如何获得相同的 HEAD？
解决方案：挤压合并不是合并
How can I get same HEAD for master and dev after merge?
你不能。 Well, technically you could, but you probably don't want to.
A branch in git points to a commit; that commit points to other commits, back through history. Each of those commits is identified by a unique hash; if two different commits had the same hash, everything would be horribly broken. That hash covers both the contents of the repository, and all the metadata of the commit, including what parents it has.
So if two different branches point at the same hash, those branches are identical - not just identical in their current content, but identical in their entire history.
The only way for that to happen is to always use "fast-forward" merges, everywhere, so that all your branches are actually just pointers in a single line of commits. In practice, that means rebasing things, a lot - for instance, every hotfix will probably require rebasing the whole of develop, and then rebasing all open feature branches onto that new develop.
That's a lot of work, and a lot of things that can go wrong, to avoid this:
I had to merge an empty commit with no diff.
Git was smart enough to recognise that no actual changes were needed, even though you'd merged two unrelated commits (remember: a squash merge throws away all history on the feature branch). That is it solving the problem for you.
The other solution, as pointed out in comments, is not to merge the feature to two places in the first place. Merge release to master, and then merge master to develop.
你的图表是错误的。壁球合并 不是合并 。它会导致一个新的提交凭空出现，没有记录如何或为什么。如果你对 master 进行挤压合并，对 dev 进行挤压合并，则 master 和 dev 是两个完全独立的提交，彼此不相关且与功能分支无关。因此，从功能分支末端指向 master 和 dev 末端的箭头是错误的，应该删除。
如果您希望这些东西之间存在某种关系，至少要使用真正的合并。并且不要走捷径。以正常方式执行此操作：PR 到开发，合并到开发，然后 看看如何将它（dev 上的合并提交）放到主服务器上。
一个发布分支（这似乎是你所问的）就像一个普通的开发分支，除了（1）它阻止所有功能被合并到开发中，以及（2）正如你所说的那样，这里的目标是合并到 master，当然我们也必须合并回 dev。您可能想查看原始文档，https://nvie.com/posts/a-successful-git-branching-model/，它比您引用的 atlassian 页面更简单明了。
我想了解 git 流程中的一件事。假设我们有这样的分支树
在这种情况下，我通过分别向 master 和 dev 打开 PR 来合并我的发布分支。我将 PR 与 using
合并git merge --squash
命令。合并结束时，我有两个不同的提交 ID
master有D1234 开发者有 C4567
我的困惑从这里开始。如果 master 和 dev 没有相同的提交哈希，在从发布分支到 master 的下一个 PR 中，我将在 PR 中看到 C4567。我不得不合并一个没有差异的空提交。我哪里做错了？ master 和 dev 合并后如何获得相同的 HEAD？
解决方案：挤压合并不是合并
How can I get same HEAD for master and dev after merge?
你不能。 Well, technically you could, but you probably don't want to.
A branch in git points to a commit; that commit points to other commits, back through history. Each of those commits is identified by a unique hash; if two different commits had the same hash, everything would be horribly broken. That hash covers both the contents of the repository, and all the metadata of the commit, including what parents it has.
So if two different branches point at the same hash, those branches are identical - not just identical in their current content, but identical in their entire history.
The only way for that to happen is to always use "fast-forward" merges, everywhere, so that all your branches are actually just pointers in a single line of commits. In practice, that means rebasing things, a lot - for instance, every hotfix will probably require rebasing the whole of develop, and then rebasing all open feature branches onto that new develop.
That's a lot of work, and a lot of things that can go wrong, to avoid this:
I had to merge an empty commit with no diff.
Git was smart enough to recognise that no actual changes were needed, even though you'd merged two unrelated commits (remember: a squash merge throws away all history on the feature branch). That is it solving the problem for you.
The other solution, as pointed out in comments, is not to merge the feature to two places in the first place. Merge release to master, and then merge master to develop.
你的图表是错误的。壁球合并 不是合并 。它会导致一个新的提交凭空出现，没有记录如何或为什么。如果你对 master 进行挤压合并，对 dev 进行挤压合并，则 master 和 dev 是两个完全独立的提交，彼此不相关且与功能分支无关。因此，从功能分支末端指向 master 和 dev 末端的箭头是错误的，应该删除。
如果您希望这些东西之间存在某种关系，至少要使用真正的合并。并且不要走捷径。以正常方式执行此操作：PR 到开发，合并到开发，然后 看看如何将它（dev 上的合并提交）放到主服务器上。
一个发布分支（这似乎是你所问的）就像一个普通的开发分支，除了（1）它阻止所有功能被合并到开发中，以及（2）正如你所说的那样，这里的目标是合并到 master，当然我们也必须合并回 dev。您可能想查看原始文档，https://nvie.com/posts/a-successful-git-branching-model/，它比您引用的 atlassian 页面更简单明了。