在github上跟蹤fork上游的最佳實踐

Question

摘要：如果要維護一組本地更改，處理上游存儲庫的長期運行跟蹤的最佳做法是什麼？

我想保持github上的fork與上游同步，但仍然允許明確跟蹤fork的唯一更改。 （對於這個討論，假定upstream點主體工程庫和origin指的是我的存儲庫叉）

想象我有這樣的事情，我一個分叉倉庫時，上游/大師在E.

Upstream: 
A-B-C-D-E-F 


Fork:  
A-B-C-D-E ----- P ------T 
     \-L-M-/ \-Q-R-/ 

分叉倉庫後，我創建了兩個特徵分支（LM和QR）來添加我需要的新特徵，並將它們合併回我的原點/主。所以現在我的分支有上行不存在的改進。

我發現上游有一些有趣的修復，所以我想回到與上游同步。根據我發現的大多數參考文獻（git hub fork），推薦的方法是將上游/主文件合併到您的原點/主文件夾中，然後繼續。所以我會發出如下命令：

git checkout master 
git fetch upstream 
git git merge upstream/master 
git push 

那我就結束了倉庫，看起來像這樣：

Upstream: 
A-B-C-D-E-F 


Fork:  
A-B-C-D-E ----- P ------T-F' 
     \-L-M-/ \-Q-R-/ 

有一對夫婦的我雖然這個問題看。

1. 我實際上沒有在我的回購中提交F，我有F'具有相同的內容，但不同的散列。所以我不能輕易地引用這兩個倉庫之間的提交，並知道我有一個改變。 （當考慮到上游可能有多個更改並且它自己已經合併的一組特徵分支時，它變得更加複雜）

2. 隨着我向前邁進並繼續這樣做，我越來越難以知道我的存儲庫中有什麼變化超出了上游的變化。舉例來說，我可能會將這些變化中的一部分提交回上游，同時繼續添加我自己的改進。經過幾次迭代後，如何看待我的存儲庫知道它與上游有什麼不同？ （是否有git命令來查找這些更改？）

3. 與＃2類似，如何找到上游的修復程序並檢查是否包含修復程序？

我想這個問題的根源是沒有辦法，我保證我的倉庫是在「同步」在任何給定的點上游，因爲代碼和哈希值是不一樣的。那麼，我該如何準確地追蹤變化並保持自己不會瘋狂地嘗試保持同步？

注意：我曾經考慮過使用rebase來繼續將我的存儲庫重新綁定到上游，但這有一組完全不同的問題。例如，如果任何人通過子模塊，分支等引用我的respository，那麼歷史重寫將會破壞它們的引用。另外，我不認爲我的分支歷史能夠在rebase存活下存活下來，所以我不能完整查看我所做的所有功能分支和相關的歷史記錄。

其他人怎麼處理？我應該研究哪些最佳實踐？

---

更新：

基於來自賽斯的反饋，我創建了一組測試庫，以顯示我在談論它是如何工作了，他說的方式。

的倉庫是：

• upstream
• fork

他們應該更清楚地顯示瞭如何從上游合併時有局部的變化，以及外觀。

Answer 1

你在你的假設是不正確的。您在文本示例中說過您將運行git merge命令。如果你真的是這個意思，而不是git cherry-pick（和記錄，git合併是在這種情況下的最佳做法），那麼你沒有得到F`在你的分支，你會得到F.也許一張圖片：

After抓取但在合併之前，你的回購協議是這樣的：

Upstream: 
A-B-C-D-E-F [master] 


Fork: /-F     [upstream/master] 
A-B-C-D-E ----- P ------T  [master] 
     \-L-M-/ \-Q-R-/  [Other branches] 

合併完，你的回購看起來就像這樣：

Fork: /-F-------------\ [upstream/master] 
A-B-C-D-E ----- P ------T-U [master] 
     \-L-M-/ \-Q-R-/  [Other branches] 

新承諾「U」在您的回購將合併提交，就像提交「P」和「T」一樣。

git cherry-pick將創建「F」，如您在示例中所示。不要這樣做。 git rebase有時可以支持分期付款分支git rebase -p，但它並不總是有效。此外，這是重寫公共歷史，這是一個壞主意。

我有一個關於git最佳實踐的文檔：Commit Often, Perfect Later, Publish Once您可能特別想調查工作流部分以獲取更多靈感。