有沒有這樣做多次提交，並推

Question

獨推V/S每次提交沿之間的差額是否有混帳回購的差異，如果我們做了以下2種情況：

• 案例1：做10個提交和在結束
• 殼體2的單個推：做一個提交和一推，重複步驟10次，每次提交

Answer 1

在最終結果是：號在此期間，所述多個推將使中間人更早提交。但在第10次推出vs單曲結束時，您將推出10次提交。

這很容易測試自己。

但是，如果您的計算機在進行單次提交之前崩潰，那麼與增量推送相比，您將失去更多工作。
或者，另一位貢獻者可能會遇到更多合併衝突，或者至少在獲取您的增量更改時遇到更大的延遲。

如果您進行了10次更改，每次提交一次提交，而單次提交更改爲10次，那麼您將有什麼區別。

Answer 2

這取決於貢獻者的數量和遠程存儲庫的合併策略。

1. 只有一個貢獻者和政策允許直接推送。

   不同之處在於您運行push命令的時間。最終的代碼和歷史在兩種方式中都是相同的。

2. 不止一個貢獻者和政策允許直接推送。

   如果您通過一次推送推送10次提交，則由於快進推送或由於非快進推送導致的失敗而導致成功。如果您推送一次提交，由於非快速推送，您有更多機會失敗。在兩次推送之間，遠程分支可能會被其他貢獻者更新，這會使您的本地分支與遠程分支分離，並且在您執行提取和合並/重新綁定之前，您的下一次推送將失敗。 「獲取和合並/重新分配」可以在單個命令git pull或git pull --rebase中完成。

3. 合併策略僅允許合併/重新綁定請求。

   如果只有一個貢獻者，那麼採用這樣的策略是不太可能的。所以我們只是談論一個團隊。如果您的團隊正在使用Gerrit等評估工具，您將面臨這種情況。推後，新的提交不會立即合併到遠程分支中。每個提交都保存在由Gerrit使用的ref中，例如refs/changes/34/12234/1之類的引用。審查人員審查您的更改並批准後，這些參考文件將被合併到真實分支中。如果評審人員認爲它不合格，那麼裁判將被拒絕。您必須修改它或重置爲先前的提交，進行新提交併再次推送。新的參考將被創建以進行審查。 Github中的拉取請求並不完全相同，但非常相似。

   在這種情況下，即使它是非快進推送，您的推送也會始終成功，因爲您實際上並未推送到真正的分支。 Gerrit帶領你推動創造其他裁判。如果您一次推動10次提交，則會創建10次引用，並且全部都是依賴的。您可以將它們從最老的到最年輕的一個接一個地合併。如果有任何衝突，你可以修復它，或者跳過它並重新設置他們的繼任者。

   如果您在先前批准併合並後推送一個提交併推送下一個提交，則其他團隊成員可以在兩次推送之間推送併合並它們的提交。同樣，你可能會有更多的機會失敗，因爲你的下一次合併總是有可能引發衝突。兩次推動之間的時間間隔越長，失敗的機會就越多。當然，在每次推送之前，一個git pull或git pull --rebase會降低可能性，因爲大多數潛在的衝突都可以在本地修復。但並非所有的東西都可以避免，因爲無論何時需要合併ref，真正的分支可能在第二個之前被其他人更新。

   真實情況比較複雜，差異可能很大。