Git集中式工作流程

Question

假設開發人員正在使用git集中式工作流，並且github有2個文件a.txt和b.txt。

現在dev1成功推送了c.txt。 現在，如果dev2推送d.txt，則它是非快進的，並且他不能正確推送，因為他必須先在本地合並dev1的更改，然后再推送。

現在是另一種情況，假設dev1創建分支FeatureC並在其中包含文件c.txt以及a.txt，b.txt和push。 類似的dev2將創建分支FeatureD，並在其中包含文件d.txt以及a.txt，b.txt和push。

現在，發出拉動請求以將featureC與master合並，並且成功。 再次發出拉動請求以將featureD與master合並，這不應成功，但它是成功的。 不可能！ 怎么會這樣？ 它不符合上述情況嗎？

Answer 1

您描述的情況

DEV1：

a---b - master
     \
      c - featureC

DEV2：

a---b - master
     \
      d - featureD

集中式回購：

a---b - master

在您的第一個場景中（您似乎同意），似乎兩個開發人員都試圖將其直接推入集中化回購的同一分支：

在dev1將其本地master推送到集中式master之后：

a---b---c - master

然后，如果DEV2有當地a---b---d - master ，並試圖推，要master對集中式回購， git抱怨。 應該怎么辦？

這個：

a---b---d - master #nope

因為c被丟棄將是錯誤的。

這個：

a---b---c    #nope
     \
      +---d

也會錯， master應該指向哪里？ git沒辦法知道。 因此， master的抱怨有所分歧。

現在到第二種情況。

我假設拉請求導致集中式回購中的拉。

“發出了將featureC與master合並的請求，並且成功”：

集中式回購：

      c - featureC
     / \
a---b---x - master

然后“發出請求以將featureD與master合並”：

      c - featureC
     / \
a---b---x---y - master
     \     /
      +---d - featureD

我沒有理由不這樣做！ 由於在集中式回購， featureD在合並master是先進的日期， master並沒有分歧。

Answer 2

推和拉之間有很大的區別。 當您要將提交推送到遠程分支時，本地存儲庫需要來自遠程的所有提交，當然也需要您要推送的提交。 當dev2推送d.txt的提交而又不了解先前引入c.txt的任何提交時，情況並非如此。

現在，對於請求請求，情況有所不同。 您總是可以輕松地拉出任何不沖突的內容，這是當提交僅影響不同文件時的情況。

實際上，在第一種情況下，這是一個請求請求，當git告訴dev2在其推送之前進行請求（合並）時。

在沒有沖突的情況下，您始終可以拉（快進或合並），但是只有當分支與要推送到的遠程分支是最新的時，才可以推送。

對於本地存儲庫中的開發人員而言，查看提交實際請求的更改非常容易。 假設dev1分支到了featureA，以便於今天早上從master開發一些功能。 晚上，他想查看自己所做的所有更改，簽入時，他願意

git format-patch master..featureA

按順序編號的所有提交都將寫入文件NUMBER-TITLE.patch 。

所有這些補丁可以合並到origin/master ，不管國家的origin/master （如果已經有新的變化去origin/master ，或沒有），如果沒有補丁未申請原產/主，由數量排序。