是確定總的git拉--rebase主分支

我們是一個團隊使用Git的工作，我們有一箇中央存儲庫（單源），我們用它來push和pull從（與Capistrano的使用它來部署分支主）是確定總的git拉--rebase主分支

我們做的提交，並定期部署（10〜20部署了一天），這意味着我們有很多合併的提交和git blame成爲一場噩夢

我讀過，有一個簡單的歷史，我們可以使用git pull --rebase以避免這種情況。在master分支上做這件事總是一個好主意嗎？

如果是我想建議將其設置與配置：

git config branch.master.rebase true

是否有任何問題與此？

來源

2013-10-03 Mathieu

完全沒問題。事實上，這是首選。它是更好地變基的變化。如果沒有時間

99％，開發人員可以隨時中止底墊和手工合併他們的更改。

替代方案（合併拉）會導致大量的小方提交和合並，這些提交和合並不會產生任何意義。

一般來說，我並不經常看到合併本地更改的要點。它意味着開發者開始的確切修訂有一些特殊之處，並且以某種方式重定向到不同的修訂版本會導致信息的丟失（也許「我在Bob的功能之前開始了這個，並且我希望在沒有修改的情況下進行通信」與鮑勃玩得很好，我受到指責「或某事......）。實際情況並非如此，乾淨的直線提交歷史記錄更容易遵循。

來源

2014-01-09 18:02:32

-4

你永遠不應該改變其他存儲庫中存在的任何修訂版本，並且可能會根據它進行其他工作，因爲該工作不需要重新設置。

如果您推送一個分支並重新綁定它，則必須使用-f選項才能進行下一次推送。所以如果你從不使用這個選項，你永遠不會遇到有問題的情況，並且可以自由地重新綁定。但是，如果您將-f推向功能分支，那麼當其他人也可能在該分支上工作或者與他們協調rebase時，小心不要重新綁定。

因此，對於你自己的開發工作，通過一切手段，rebase（和rebase -i，合併和拆分變更等，使他們更合理）。但是，如果不止一個人在某個特徵上工作，那麼重新分配將需要協調，這可能不再是值得的，並且重新分配已發佈的分支基本上是不受限制的。

來源

2013-10-03 08:38:32

因爲我們只從中央存儲庫中拉出/推送，沒有人可以從_my_ master分支拉出來，所以我不能通過'git pull --rebase master'來重定位其他存儲庫中存在的工作。我可以嗎？當然功能分支只有在沒有發佈的時候纔會發生rebase。我只是在談論這裏的主人 – Mathieu

@Mathieu：沒有人可以拉你的主人，但是如果你把主人推到中央存儲庫的開發分支中，那麼別人可以使用它，那麼你就不應該重新分配它。 –

這個答案是錯誤的，除非你用-f和/或將它推到不同的上游存儲庫，而這些存儲庫永遠不會與主存儲庫重新同步。如果你不這樣做，那麼被重寫的歷史根據定義限於未共享的本地提交。 –

在默認情況下進行pull rebase是可以的（不一定是「好主意」，也不一定是「壞主意」）。你只需要記住它實際上會改變你的工作。如果你已經取得了一系列的提交，那要看什麼是回購前鮑勃改變了它，衍合（對Bob的變化上），可能會迫使你解決了所有這些提交的時候它可能已經更容易修復只有最後的合併提交。

我更願意手動執行此操作：運行git fetch，然後git rebase或git merge視情況而定，我可以發現，一旦我做了取。

有一個優勢，git pull --rebase（和/或設置branch.master.rebase true）不過，在那是額外的智能「與拉底墊」，可以處理一些情況下，遠程做得變基太。

「鮑勃」在這裏表示使自己變爲「消化不良」，因爲它是人誰取得了一定的變化（並擊敗你的push步驟）。

來源

2013-10-03 09:21:59 torek

它總是在我的經驗研究細pull.rebase。如果你不想合併衝突，你可以在本地分支工作，如果你想使用最新的代碼，你總是希望在推動當前工作之前有任何未被改變的改變。

由於git pull而在分支中合併幾乎總是毫無意義的，如果合併將是有意義的，那麼分支應該是不同的（並且合併顯式）。請參閱http://stevenharman.net/git-pull-with-automatic-rebase。

來源

2013-10-03 09:59:06 TuteC

是確定總的git拉--rebase主分支

回答

相關問題