Gitflow、Squash 合並和 AzDO 分支比較

Question

我們目前正在使用 Git 流作為分支策略，我們正在將我們的功能分支壓縮到develop中。 我們還將我們的發布分支壓縮到main中。

AzDO 分支頁面顯示了develop -> main之間的提交差異，這是我所期望的，但它也顯示了文件中的主要差異，當在 git CLI 中雙重檢查時，這些差異是錯誤的。

有誰知道AzDO如何比較分支？ 更重要的是它可以配置嗎？

我期待看到提交差異但沒有文件更改。

Answer 1

我相信 Azure DevOps (AzDO) 比較分支屏幕使用與 Pull Request 視圖相同的 diff，它將兩個分支的合並基礎與源分支進行 diff。 因此，例如，如果您在分支屏幕上比較develop和main ，則差異將與您創建develop到main的 PR 時看到的視圖相同（您可能不會在 Git Flow 中這樣做），並且將是等效於以下命令（使用 Git Bash）：

git diff $(git merge-base develop main) develop

等效的簡寫3 點 diff 語法是：

git diff main...develop

大概您正在使用（並且更喜歡）的命令行差異語法是 2 個點（相當於零個點）：

git diff main develop

據我所知，無法更改 AzDO 在分支頁面上使用的差異，因此您必須使用命令行或您最喜歡的 UI 來查看該差異。

我相信此時您的具體問題已經得到解答，但如果不討論您喜歡無點差異的原因以及 AzDO 使用 3 點差異的原因，這個答案將是不完整的。

三點語法背后的動機

事實證明，大多數人在大多數時候更喜歡 Pull Request 中的 3 點差異。 可以說，分支比較屏幕旨在用於准備合並（或 PR），因此在該屏幕上顯示相同的差異也是有意義的。

不過，這可能不是您描述的場景的最佳視圖，因為您的默認視圖會很嚇人； 看起來您將要更改許多您知道實際上並未更改的文件。 在 PR 視圖中有一個“查看合並提交”的選項，如果您在生成合並提交的那一刻完成 PR，它會告訴您實際會發生什么變化。 一旦源或目標分支發生變化，合並提交將需要重新計算，如果需要，也有一個選項。 ¹目標分支的變化是大多數人更喜歡 3 點語法的原因。 這是一個例子：

認為，

1. 您從最新的develop創建一個新的分支feature 。 此時feature和develop是相同的，這意味着它們指向同一個提交。
2. 您在您的功能分支上工作了幾個小時，當您完成后，您有兩個漂亮的提交，您可以將它們合並到develop中。 您推送您的分支，並在 AzDO 中創建一個 PR 以將feature合並到develop中。
3. 在過去的幾個小時里，另外 5 個 PR 使用擠壓合並策略完成develop ，現在develop有 5 個你的分支不知道的新提交。

PR 使用 3 點語法差異，它僅向您顯示自develop分支以來feature發生的變化。 這應該與您所做的更改相匹配，並且可以輕松進行代碼審查。 如果 PR 使用常規 diff 語法，您會看到feature和develop之間的直接差異，其中包括其他 5 個提交中的所有更改，這些更改與您所做的更改無關。 這會令人困惑，並且很難進行代碼審查。

現在，我猜您同意上一段關於將feature分支合並到develop的場景，並且在分支“比較”頁面上比較feature與develop時您會看到相同的內容。 但是為什么develop （或release ）與main的比較顯示許多已經在main上的變化？ （當你在main中創建release的 PR 時也是如此。）

您遇到此問題的原因是您的工作流程存在輕微缺陷：

我們還將我們的發布分支壓縮到 main 中。

根據經驗，您永遠不應該重寫共享分支。

在 Git Flow 中，共享分支是develop 、 main 、 release和hotfix 。 所以這意味着任何時候 Pull Request 的源分支是這些分支之一，你不應該重寫分支。 在 AzDO 中，完成 PR 時有 4 種合並策略可供選擇：

1. 合並（無快進）
2. 擠壓提交
3. 變基和快進
4. 半線性合並（又名 Rebase，合並）

除了策略#1 之外的所有策略都可能重寫源分支，這意味着當執行源分支是特殊共享分支之一的 PR 時，您應該使用的唯一策略是#1（合並）來完成 PR。 因此，在將功能分支完成為develop時使用壓縮策略很好，在將錯誤修復分支完成為release或hotfix時也可以使用壓縮策略，但是當將這 4 個共享分支中的任何一個 PR 到另一個分支時，你不應該壁球，或變基。 因為您一直在release壓縮到main中，所以您每次都在重寫所有這些提交，這意味着develop上的許多提交從未登陸main 。 因此，“自從我從main分支出來后我在develop上做了什么改變？”的 3 點語法。 其中有很多提交 - 因此出現了更多已經存在的更改。 每次將release分支合並到main時，情況可能會變得更糟。

修復

您應該做的第一件事是通過常規合並將main合並到develop中。 如果您使用 PR，那么您應該選擇合並策略 #1，因為源分支main是一個共享分支。

從那時起，遵循經驗法則，這個問題應該大多²消失。

邊注

Git Flow 建議對每次合並使用--no-ff ，但實際上只有在超過 1 個提交中合並的 PR 才需要這樣做。 如果您不關心單個提交，壓縮與 Git Flow 兼容，只要您從不使用它來合並任何共享分支。 在我在 Azure DevOps 中的一個 Git Flow 項目中，我們在develop 、 release和hotfix上設置了一個分支策略，只允許“半線性合並”（它執行一個變基，然后強制使用--no-ff進行合並提交） . 如果您更喜歡 Squash，您可以在這些分支上執行相同的操作，但將其鎖定為 Squash。 但是，無論何時我們在源分支是共享分支之一的情況下進行合並，例如release到develop ，然后我們使用覆蓋功能，以便某些人可以使用常規“合並”策略完成這些合並。 我還沒有想出一個干凈的方法來為某些共享分支執行該規則，但如果可能的話會很好。

---

¹在 AzDO Pull Requests 中，只要源分支發生變化，就會自動重新計算合並提交，但不會在目標分支發生變化時重新計算。 如果您希望在目標分支更改后重新計算它，您可以。 在您完成 PR 的那一刻，如果需要，它也會重新計算它。 請注意，這意味着如果自上次生成合並提交以來目標分支已更改並導致新的合並沖突，則可能在您嘗試完成 PR 之前不知道存在合並沖突。

²在不違反永遠不重寫共享分支的經驗法則的情況下，在正常情況下仍然有可能出現相同的問題。 例如，假設某人完成了對develop的 PR，然后很快意識到更改確實應該進入release分支。 因此，更改被精心挑選到release release 現在有 2 個不同的提交，其中有相同的更改，當release合並回develop時，即使它們已經在develop中，PR 也會顯示這些更改，僅僅是因為它們（有意）在兩個不同的提交中。 這是 Git 中另一個經驗法則的原因之一：“如果可以通過合並來實現相同的事情，請避免擇優選擇。” 如果您事先知道您需要對develop和release進行更改，那么您可以將其合並到release中，然后將release合並到develop中，因為您可以隨時這樣做。 或者，如果可能的話，更改可以從develop和release的合並基礎分支出來（甚至是引入錯誤的原始提交），然后新提交可以合並到develop和release中。