如何在GitHub中將git dev分支與合併+壓扁PR進行同步後同步？

So GitHub has the ability to merge+squash commits for PR。如何在GitHub中將git dev分支與合併+壓扁PR進行同步後同步？

我們按照從dev - >master PR'ing代碼的過程。

以前，我一直在'合併'PR，但是會生成一個新的提交，它會顯示：「Merge Pull Request #1 from foo/bar」。 :(Boooo ...

所以我想我可能會嘗試新的Squash Commits啄與GH，這創造了我以前所有的提交壓扁。好了，到目前爲止，一切順利。

我然後一個新的提交回到我的dev分支（在我的開發者機器上）..拉下upstream/master（這是公關和壁球合併發生的地方）），現在增加了另一個致力於我的本地歷史！它沒有去「哦，哇，你是waaay不符合...讓我們同步」。它只是做了合併。

所以壁球+合併按鈕壓扁4個提交，並用1取代它... 拉upstream/master我的本地機器上現在顯示的是4個提交仍然存在，壓扁提交的PR做了一個新的承諾是「Merge branch master .. blah ... noise ..spam」承諾:(:(:(

有一個特殊的技巧/工作流程我應該做後發生合併，壁球..確保我dev分支正確同步時間？象。。是不是每個人在刪除本地主機dev分支之前都要先將upstream/master退回到他們的本地主機，並將其分配到（新創建的）dev分支中？

請記住：這裏的目標是避免那些糟糕的「Merge Pull Request＃2 ..」merge bubble消息。

或者，人們通過CLI只是在做這個暫且到GitHub上學會了如何做到這一點:(

來源

2016-07-25 Pure.Krome

最簡單的選擇是在CI通過時創建一個獨立的功能分支，並將主窗口合併回主窗口。然後刪除分支。 – osowskit

其實，整個「反而不是合併」的想法頗具誤導性。合併歷史是正確的。它具有該功能的發展歷史，該功能希望包含有關爲什麼進行更改的信息。它具有合併提交，它顯示合併功能的時間。重新合併或合併壓縮分支不以任何方式鏈接到原始分支，從而丟失重要信息。如果您不喜歡'git log'或UI如何顯示合併歷史記錄，那麼您應該修復_that_。例如使用選項'--first-parent' – max630

我認爲問題出在你的工作流程上：通常一旦你合併了一個拉請求（不管你使用哪種方法），你就可以完成這個分支。如果您想進行進一步的更改，則最好從當前的上游/主站中創建一個新功能分支，然後您可以打開另一個請求將其合併回去。

如果你真的要堅持一個長期分支的所有開發，還有你必須記住幾個注意事項（你叫開發一）：

如果你不是唯一一個在這個分支上工作的人，你必須避免任何一種歷史重寫。沒有重新設定，不壓縮，不重置，甚至不修改提交。這基本上排除了使用壁球合併。
如果你確定你是唯一的一個分支上工作，並且使用GitHub的壁球選擇合併引入請求像你一樣，那麼必須重置您的本地開發分行最新上游/大師前在那裏恢復你的工作。這也意味着稍後您需要強制推送到上游以創建新的請求。

最後一點是容易出錯，會影響以前的代碼評論，所以我個人會選擇使用短暫的功能分支。

來源

2016-10-21 10:31:08

沒有爲合併而無需額外提交稱「合併富分支擠壓你的提交一個更好的解決方案你應該總是更喜歡rebasing而不是合併，然後壓扁，因此rebase會幫助你合併兩個分支，而不需要額外的提交，你應該嘗試重新分支分支而不是合併，下面是相同的here的詳細解釋。

來源

2016-07-25 05:14:55 pjoshi

因此，Github需要'合併'按鈕來有一個新的選項：'確認rebase'（一邊'確認合併'，現在'確認壓扁和合並'）？ –

合併將始終創建一個新的提交。你可以通過UI或控制檯來完成。但是如果你想避免額外的合併提交，你應該改變基準。這個rebase選項現在不存在於UI中。 – pjoshi

如果你的dev分支被合併和壓扁，那麼你不再需要它了，只需將它重置爲upstream/master。

如果有一些更新的更改，您可以調用git rebase -i upstream/master來代替所有已合併的提交，重新綁定其餘的。

來源

2016-07-26 09:04:59 max630

如何在GitHub中將git dev分支與合併+壓扁PR進行同步後同步？

回答

相關問題