上拉合併提交請求

進行開源開發時，在主題分支上執行任何更改時，在一段時間內跟蹤上游是正常的。我注意到將上游返回時的一個事情是創建了一個合併提交。如果我然後創建一個pull請求，這個合併提交最終成爲PR的一部分。上拉合併提交請求

我的問題是，這有什麼害處嗎？我讀過一些人覺得他們沒用，但我喜歡這樣一個事實，即他們在上次與上游同步時作爲時間戳。是否有一種公認的做法來跟蹤上游並引入合併提交。

來源

2014-11-04 McDonnellDean

將上游返回時創建合併提交。

這就是爲什麼它是最好：

git rebase master（重訂更新的遠程跟蹤分支的頂端的分支）
git push -f（力推你的分支到你的GitHub叉：現有PR將相應地更新）

行之有效如果：

你的公關在自己的分公司做
沒有其他人正在積極地使用你的分支

來源

2014-11-05 09:29:12 VonC

雖然我可以從視圖中刪除多餘提交的點理解上面，我真不知道我除了一些希望修改提交流的願望外，請參閱刪除它的要點。也許你可以詳細說明爲什麼這是必要的？ – McDonnellDean 2014-11-06 22:10:58

@McDonnellDean是：http://stackoverflow.com/a/23285782/6309和http://stackoverflow.com/a/14681796/6309。 GitHub中的PR被強制推送：它們會爲你更新。我們的想法是讓您的公關保留在自己的分支中，並且始終將其更新到最新的遠程跟蹤分支上，以確保最終的合併（在原始回購中完成）將是一件微不足道的事情。 – VonC 2014-11-06 22:14:08

上拉合併提交請求

回答

相關問題