糾正Git中舊的合併混亂

我們是一個使用Git的小型應用程序，我們所有人都是新手。在這個月，我們已經使用Git和開始與功能分支試驗和釋放分支機構或兩個，我們遇到了一點麪條事件這樣一個引起的合併衝突等：糾正Git中舊的合併混亂

enter image description here

黑線是我的發展分支。忽略紅色的。你會看到單個提交如何從該開發樹中分離出來，然後再合併回來。通過展開樹來清除一些舊的蜘蛛網是否可能？我的頭現在大約有500多個提交。

我讀過這可以通過rebasing而不是合併來避免。

儘管這是一件小事，但如果可能的話，我想解決這個問題，因爲這兩者都是OCD和清晰度的問題。

謝謝。

來源

2011-09-01 Mridang Agarwalla

git的git的一大優點就是能準確記錄提交的地方以及它們是如何合併的。你確定要壓扁你的歷史嗎？重寫500次準確的歷史提交以僞造歷史來替代它們對我來說是錯誤的。 –

我不太瞭解重新佈局/過濾或任何需要完成此操作的知識。我已經展示的例子只是現在分散在我們的回購庫中的衆多例子之一。如果有簡單的方法來平坦化這些，那將是很好的，但除此之外，如果它需要幾個小時坐在文本編輯器上並解決衝突，我寧願跳過它。雖然清理提交樹會很棒，但如果可能的話，我不介意刪除提交，因爲其中很多都沒有發生很大的變化。謝謝。 –

如果你真的想線性化歷史上的主分支提交A後，你總是可以做：

git checkout master 
git rebase A

但是，這意味着，你重寫你的master分支的歷史，所以如果您（強制）推送這個新版本，則必須向團隊中的每個人介紹如何獲取新版本並重置其主分支以匹配重寫版本。否則，人們可能會拉動，這會將改寫的分支與現有的分支合併，從而擊敗練習的對象。

這些小差異通常發生在有人在其主分支上創建提交時，但服務器上的主服務器已在平均時間內移動 - 這意味着當它們再次拉出時，需要合併提交。您可以在未來或者通過類似的措施避免這種情況：

鼓勵人們使用git pull --rebase
告訴人們使用branch.<name>.rebase和branch.autosetuprebase配置選項，讓他們不要忘記添加--rebase
添加鉤到refuses pushes of non-linear history

不過，我個人不介意看到在歷史上的這些合併的服務器 - 具有良好的瀏覽器的歷史，它仍然很清晰w ^帽子正在發生。

來源

2011-09-01 13:12:15

如果500+提交，這只是許多例子中的一個，我會保留原樣，並使用Mark的一些想法，以防止它在將來發生...重寫公共歷史通常不是一個好主意... – johnny

嗨馬克，我試圖重新裝訂它，這並不容易。我只是跳過它，並使用分支鉤子。 .rebase'和'branch.autosetuprebase' - 在本地還是在服務器上？兩者有什麼區別？（希望我不會在這裏問這個問題）。我並沒有想要平坦化我的功能分支提交。這只是爲了防止這些非線性提交。我是否仍然需要啓用這些選項？謝謝。 –

這些選項在文檔中描述（http://www.kernel.org/pub/software/scm/git/docs/git-config.html#_variables）。總之'branch.autosetuprebase'會導致分支。 .rebase'在某些情況下爲新創建的分支設置。這兩個設置都將在每個開發人員的存儲庫中本地應用。該鉤子應該被添加到裸機存儲庫中，這樣您即使有人未使用這些設置或忘記重新綁定，嘗試推送也會失敗並顯示一條有用的錯誤消息。 –

糾正Git中舊的合併混亂

回答

相關問題