Git rebase衝突理解

在我的工作流程中，我有兩個主要分支，master和development。Git rebase衝突理解

我們最近決定在master上重新配置development，因爲我們在master上做了很多修復，我們繼續開發development上的功能。

我們的目標是在年底前完全去除development，並保持一個分支來改變我們的工作流程，因爲它是不完美的爲我們的使用...

所以我們有一些衝突（7個月的開發後正常型動物分支機構），但有些人退出怪異......

例如，很多的時候，我們有這樣的事情：

$ git status 
# On branch master 
# Unmerged paths: 
# (use "git add/rm ..." as appropriate to mark resolution) 
# 
#  added by them:  X 
#  added by us:  Y

但對於added by us，該文件存在於master和我n development提交。你要知道，有關的文件都至少10個月老....

我的問題在這裏：什麼是added by us的確切含義是什麼？

和是rebase是一個很好的做法嗎？

來源

2013-07-12 Pierre Fourgeaud

當要摺疊提交的，你沒有分享過，曾經你的個人資料庫; rebase是個好主意。如果你想摺疊團隊其他成員使用的提交併希望獲得他們的仇恨，rebase是個好主意。 – tjd

我假定us表示您當前的分支，而them表示您正在進行重新綁定。但是，這實際上是一個非常小的點，因爲：

你不應該重訂7個月工作價值！

衍合應該差不多隻能在本地代碼中使用，也就是還沒有推。如果你用它來做別的事情，你可能做錯了什麼。這是其中的一次。

的默認答案是合併，墊底的是特殊情況。所以你也應該在這種情況下合併。墊底的後果：

你要做100合併，而不是1和照顧衝突，而不是100次一次（在底墊中的每一步都是一個合併）
你的歷史是一個total lie。我確實認爲你沒有徹底地測試每一個重新提交的提交（因爲這顯然會很瘋狂）。其結果是，稍後沒有任何代碼可能實際工作，甚至是有意義的。有關衝突解決的信息也會丟失（如果您合併，則不會丟失 - 您可以通過與父母雙方進行區分來獲得）。

來源

2013-07-12 08:11:43 Chronial

在重大分支重寫的情況下，重新生成是一種有效的工具，即使對於大量的歷史記錄也是如此。 –

我也認爲這是完全有效的，你可以在rebase之前「擠壓」那些提交，以使事情變得更容易。所以它就像「rebase -i commitBeforeBranchCreation」，做所有的壁球，修復必要的，然後「rebase masterBranch」......這樣衝突就少得多了。 – mjsr

Git rebase衝突理解

回答

相關問題