https://bitbucket.org/xxx/yyy Git合併分支'主'

Question

我們在使用SVN好幾年後有時候會混淆，我必須承認，這很混亂。以下面的示例 -

• User1對a.java進行更改並將其推送到遠程服務器。
• User2對b.java進行了更改。他不能馬上推（SVN的偏差，但沒關係）。他需要先從遠程服務器拉出，然後將其更改推送到遠程服務器。這將顯示爲單獨的合併提交，並在here on stackoverflow itself
• 中得到了很好的解釋。現在是有趣的部分。如果我們推斷這是多個文件，那麼與User2更改的其中一個可能會發生衝突。這一次，git無法進行自動提交。用戶2將不得不解決衝突，然後提交此合併。

這令人困惑，因爲沒有對這麼多文件進行更改的用戶會對將它們作爲此合併提交（特別是SVN背景）的一部分進行提交持懷疑態度。如果此用戶現在只提交他解決衝突並推送到遠程的文件，Git將停止提供他未推送的最新版本的文件。這帶來了我在團隊其他人中失去了工作的感覺。

這段漫長的故事後，我的問題是，爲什麼它這樣做？爲什麼GIT不應該保留其他文件的最新版本？作爲自動合併的一部分，git是否應該知道用戶沒有提交所有帶給用戶機器的文件？有沒有可以避免犯這個錯誤的機制？

Answer 1

首先，讓我澄清一下，git pull不會在本地提交未觸及的文件中導致合併衝突。所以用戶只需要處理他實際上碰到的文件。

如果這些合併提交對您來說是個問題，您應該考慮切換您的工作流程。與git進行交互的方式並未陷入困境，並且已建立的工作流程存在很大差異。例如，PostgreSQL project完全沒有任何合併提交與git一起工作。另一方面，有一個workflow that uses merge commits in a meaningful way。要獲得類似於SVN工作流的行爲，請將--rebase傳遞給git pull，但在此之前，請仔細閱讀man git-rebase以瞭解其含義。或者，您可以在提交前使用git stash來提取遠程更改，但這些選項中的任何一個都只是將衝突解決步驟置於不同的位置。

要檢查您的最後一個問題：Git將工作樹視爲您項目的快照。如果它將較新的文件與較舊的文件混合在一起，則不同的文件將具有不同的版本，這對git來說是陌生的。如果你想要這樣的功能，你需要尋找CVS（沒有玩笑）。這裏有一個權衡：任何版本控制系統都必須做出能夠跟蹤文件移動或能夠跟蹤不同版本的不同文件的決定。 Git選擇了前者。