Git合並-如果合並一個舊分支，舊問題會合並到master中嗎？

Question

我將Git用作開發的版本控制，並且相對較新。

在開始該項目的工作后不久，我創建了一個名為updateCards的分支，以解決項目中的特定錯誤。

但是，在進行此操作時，在我將更改推送到服務器之前，還引發了其他一些錯誤，需要緊急解決。 結果，我將更改提交到updateCards ，然后針對其他每個更緊迫的bug切換到新的分支。

我已經解決了這些其他錯誤，將我為它們創建的分支合並到master ，並將對它們的更改推送到服務器中。

我現在想回到舊的updateCards分支，將其與master合並並推送到服務器。 當我從updateCards分支查看項目時，我可以看到該分支創建的錯誤已解決，因此很高興可以將其推送到服務器。

但是，我不確定的是，考慮到自創建updateCards以來，我已經在服務器上對master進行了其他一些更改，如果現在將updateCards合並為master ，是否會合並updateCards中存在但仍存在的所有舊錯誤？現在在master解決了又回到master ，因為在master上修復了這些錯誤的文件將不同於updateCards上的相同文件？ 還是Git會發現這些文件在master上的更改比updateCards上的更改更新，因此不合並這些更改？

我運行了一個git diff master..updateCards ，它顯示了有關兩個分支之間差異的輸出：

diff --git a/buying/templates/buying/update_card_numbers.html b/buying/templates/buying/update_card_numbers.html
index 6cc5938..5f6a8f3 100644
--- a/buying/templates/buying/update_card_numbers.html
+++ b/buying/templates/buying/update_card_numbers.html
@@ -25,8 +25,8 @@
            <table class="left">
                    <thead>
                            <tr>
-                                       <th>Cardholder</th>
                                    <th>card no</th>
+                                       <th>Cardholder</th>
                            </tr>
                    </thead>

diff --git a/buying/views.py b/buying/views.py
index 08d2fd6..c777020 100644
--- a/buying/views.py
+++ b/buying/views.py
@@ -1555,6 +1555,8 @@ def update_card_numbers(request):
                                            cardholder = data['id']
                                            cardholder.card_no = data['card_no']
                                            cardholder.save()
+                                               #cardholder.card_no.save()
+                                               #data['travis_card_no'].save()
                                            print cardholder, cardholder.card_no

                            HttpResponseRedirect(reverse('buying:update_card_numbers'))
diff --git a/costing/templates/pdf2_base.html b/costing/templates/pdf2_base.html
index 3826a98..c139068 100644
--- a/costing/templates/pdf2_base.html
+++ b/costing/templates/pdf2_base.html
@@ -83,8 +83,6 @@
                                            <td>
                                                    <span class="project-name">{{project.project_name|upper}}</span>
                                            </td>
-                                               <!--ERF(07/12/2016 @ 1615) Display today's date in the header -->
-                                               <td> {% date_to_display %}</td>
                                    </tr>
                            </table>
                    </div>  
diff --git a/costing/views.py b/costing/views.py
index 902f9ff..f8a3f77 100644
--- a/costing/views.py
+++ b/costing/views.py
@@ -2438,9 +2438,6 @@ def pdf2_master(request, project_id):
            """ Save to the current budget (no version number), as versions not used once deposit is received """
            budget = get_current_budget(project_id)

-               #ERF(07/12/2016 @ 1615) Create a date variable to displays today's date on the PDF when it's generated
-               date_to_display = datetime.now()
-
            if not budget:
                    Budget.objects.create(project=project, current_marker=1)

但是我不確定如何解釋此輸出...這些行以-開頭存在於updateCards ，但在master不存在，而這些行以+開頭於master ，但在updateCards不存在，或Vice反之亦然？

如果運行merge ，將朝哪個方向復制哪些更改？

Answer 1

您永遠都無法期待一個差異的合並

要查看合並將執行的操作，您需要兩個差異。 ^1個

您還需要找到合並基礎 （或讓Git為您完成）。 這是因為合並是合並變更 ，而要合並兩個人的變更，我們必須找到他們兩個共同的出發地。 這個起點使我們（或Git）能夠找出“我們做了什么”和“他們做了什么”。

然后，您可以運行兩個diff： git diff merge-base tip1和git diff merge-base tip2 。 進行合並（這是作為動詞的“合並”）然后將這兩個差異組合為一個適用於合並基礎的重大更改。

同樣，您可以這樣認為：在第二個差異中找到第一個差異中尚未存在的內容，並將它們添加到應用第一個差異的結果中，即，添加到tip1 。 假設您將要進行新的合並作為擴展tip1的提交。

例如，如果您位於分支main tip1上，並且要合並到分支fix ，則tip1是main解析的commit-ID，而tip2是fix ID解析的東西。 合並（作為動詞）完成后，您將在main上進行新的merge-commit-這是一個“合並”作為形容詞-這樣main現在可以命名您剛進行的新合並提交。 新合並的內容（作為名詞的“ merge”，意思是“ merge commit”）是通過合並兩個動詞的“作為一個詞的合並”過程來完成的。

---

¹在一些相當罕見，復雜的情況下，您需要兩個以上，但在這里我們將忽略它們。

---

如果這令人困惑，我不確定其余的內容是否會有所幫助。 但是最后有一個獎勵：運行git diff以獲得所需的兩個diff的快速方法。 :-)

定義

由於您是Git的新手，我們來定義一些項目。 他們可能已經足夠熟悉，但是最好有特定的定義。

樹是文件的集合。 您使用的樹是您的工作樹 （也稱為工作樹，工作樹等）。 您的工作樹中可以包含未提交的文件：這些是未跟蹤的文件。 您可以讓Git“忽略”（停止抱怨）一些未跟蹤的文件，也可以在使用git add .時不自動添加它們以進行跟蹤和提交git add . 或git add -A之類的。 （未跟蹤的文件對於差異和合並無關緊要，出於完整性考慮，我只提到它們。）

提交是一棵樹的永久性，不可更改的快照，並帶有一些同樣永久，同樣不可更改的元數據：某人的姓名和電子郵件地址，時間戳，日志消息以及“父”提交的概念-或者，對於合並提交，有兩個父母。 ²

要進行新的提交，請使用Git的index ，也稱為“臨時區域”和“緩存”。 基本上，這是您構建下一個提交的地方。 它開始包含當前提交，然后您使用git add更新其中的文件或放入新文件； 然后git commit將索引變成一個新的快照樹，添加提交元數據-添加您的姓名和電子郵件，“ now”作為時間戳以及您的日志消息。

每個提交都具有唯一的哈希ID，例如d5c49eb32e898663a8e2c396739d831733e945c2 。 它們對於人類來說太大而丑陋，所以我們要么縮短它們，要么給它們起名字。 名稱有很多形式，但關鍵是它們總是最終解析為哈希ID。 這些是“真實名稱”。

當前提交總有³個，您可以使用名稱HEAD來命名。 通常， HEAD實際上持有分支名稱而不是原始提交哈希ID，而分支名稱持有實際哈希ID。

任何新的承諾父是提交，這是目前的當您運行git commit 。 也就是說，新提交的父項是HEAD 之前的任何值，然后HEAD接受新提交的新ID。 即使對於新的合並提交也是如此，即使它們必須至少有兩個父母。 第一個也是“主要”父母來自HEAD ； 其他的則來自您合並的任何內容。

這就是Git形成真正分支的方式。 分支名稱是臨時的 ，僅在您希望保留它們的情況下才存在。 這些提交是永久性的，並且保持不變，並且每個提交都記錄其父對象（或多個父對象）...因此，我們可以從最新的提交開始，通過向后工作將這些提交串在一起。

---

²從技術上講，是兩個或多個 。 具有三個或更多父母的合並提交被稱為章魚合並 。 但是，它們不會執行常規合並無法完成的任何事情。

另外，提交具有兩個附加的name-email-timestamp三元組： author和committer 。 對於您自己進行的提交，並沒有太大的區別，但是對於作為基礎或合並或通過補丁程序發送或通過電子郵件發送的提交，這些單獨的“誰編寫了此提交，何時”與“實際將其放入存儲庫中”什么時候”。

³此規則有一個例外。 顯然，在一個新的空存儲庫中，根本沒有任何提交，因此不可能有“當前提交”。 Git將其概括為一個不一致的名稱，稱為“ 孤兒分支”或“ 未出生分支” ，其中HEAD包含分支名稱，但分支名稱本身在其他任何地方都不存在。 在這種狀態下進行新提交實際上會創建分支名稱。 新提交是一個根提交：一個沒有父母的提交。 之后，這個怪異的邊緣狀態得以解決，並且新的提交像往常一樣獲得父提交。

---

Git向后繪制圖形； 尋找合並基地

這一切都意味着Git（和我們）應該在“最新提交”端繪制帶有分支名稱的圖形，並指向每個分支的尖端提交。 當我水平繪制它們時，我會像這樣：

o <- o   <-- master

在這里，名稱master指向master分支上的第二個和最后一個 （“ tip”）提交。 該提交指向第一個提交。 當然，第一次提交沒有先前的提交，因此它是一個根提交，我們可以在這里停止。

內部的向后箭頭在大多數情況下幾乎沒有價值，因此，我將這些圖形繪制為：

o--o--*--o--o     <-- master
       \
        o--o--o   <-- fix

像以前一樣，較新的提交位於右側，因此master和fix這是分支名稱）指向其相應的分支圖片段的尖端提交。

現在，在這種情況下，我已經用*標記了一個特定的提交。 當我們從兩個技巧開始並向后工作時，這是最接近的常見提交。 就是說，這是第一個-在Git工作的倒向方式中-承諾在兩個分支上都存在 。 （用圖論的術語來說，它是有向圖中兩個頂點的最低共同祖先，盡管在這里，Git的圓弧也從通常的樣式向后傾斜。）

無論如何，此“最新共享提交”是merge base的實際定義。 在一些復雜的圖中，可能有多個合並基礎，但是在像這樣的簡單的分叉和重新加入的情況下，只有一個合並基礎。

如果您有一張清晰的圖形，查找合並基礎（一個或多個基礎）很容易。 復雜或混亂的圖形使其變得更加困難。 Git有一個命令來查找特定提交的合並基礎，但是：

git merge-base master fix

這樣做是將master節點解析為其提交（ master的尖端），並fix其提交（ fix的尖端），然后根據需要遍歷該圖以找到合並基礎。

（如果有多個合並庫，它將選擇一個並打印它。要查看所有合並庫，請添加--all 。通常無論如何都只有一個。）

查看基於合並的差異的快速方法

假設您想查看git merge在合並master和side時將合並哪些更改。 您可以這樣做：

$ git merge-base --all master fix
face0ff1234567...                   # some big ugly hash
$ git diff face0ff master           # see what we changed
$ git diff face0ff fix              # see what they changed

但是git diff具有內置的方式來自動查找合並庫，使用三個點分隔分支名稱：

$ git diff fix...master             # see what we did
$ git diff master...fix             # see what they did

這取決於合並基礎搜索過程是對稱的事實： master和fix的合並基礎與fix和master的合並基礎是同一提交。 因此，無論我們以哪種方式翻轉兩側，我們都將獲得相同的底數。 然后，Git將該基礎與此fix...master或master...fix表達式右側命名的提交進行比較。

值得注意的是，這種A...B語法也適用於git log 。 但是，在這種情況下，它的含義不同於git diff 。 通常， A...B意思是： 找到A可以到達的每個提交， B可以到達的每個提交，然后丟棄A 和 B 都可以到達的每個提交。 也就是說，這會產生對稱差異 （以集合論術語而言）。 但是git diff只能查看兩次提交，而不是整個提交。 因此它竊取了這種語法以表示不同的含義，這對於git diff很有用。

Answer 2

根據您的git diff輸出，可以將updateCards合並到master分支中。 由兩個分支比較的文件（ + for updateCards and – for master ），如下所示：

updateCards分支更新的文件 ，

update_card_numbers.html

views.py添加update_card_numbers（request）函數

master分支更新文件 ，

pdf2_base.html
views.py添加一些新行

所以實際上，他們修改了不同的地方。 您可以合並兩個分支，而對updatedCards分支和已合並到master的新分支上的固定錯誤沒有影響。

您可以在真正合並之前執行git merge updateCards --no-commit 。 它將顯示哪些文件有沖突，然后您可以使用git merge --abort停止。 當您運行git merge updateCards ，將有沖突文件，只需保存要保留的內容，然后為每個沖突文件和git commit使用git add filename 。