在不同的發展方向情況下Git叉的工作流程

情況是我們有一個我們爲大衆建造的產品，我們在GIT回購庫（可以稱之爲upstream）上有這個產品。我們的客戶之一想要定製版本的產品，因此我們將其分叉並將其保存在差異GIT回購庫中（讓我們稱之爲origin）。在不同的發展方向情況下Git叉的工作流程

想法是引導原產地回購在自己的發展方向爲客戶定製，但仍然從上游接收更新。

我已經添加了上游作爲我的本地回購的遠程，我開發它，我知道我可以從上游拉動更新，合併它們或任何似乎很好，但我想聽到誰有誰做到這一點或做到這一點，使工作流程順利和任何可能的陷阱，以避免？

編輯：fetch-merge工作流程的處理能否像兩個repos中的相同更改一樣？就像這個工作已經開始在fork中，以及我在源代碼中固定的一些東西，但是我也需要對上游進行相同的修復。那麼我應該在上游進行另一次提交以解決此問題，並且git在下次更新叉時可以檢測相似性，或者我應該將該修復作爲單獨提交提交，即使它符合我提交的工作提交的條件？我的關注更像是如何使這個過程以最小的摩擦進行工作。

另一個問題：使用櫻桃挑選似乎是一個小改變的好主意。思考？

來源

2012-08-01 Ashfame

這聽起來很像你說的。你保持從上游的'取/合併'到你的原點。有時候，你會遇到需要解決的衝突。 – Shahbaz 2012-08-01 10:06:55

@Shahbaz我添加了一個問題，你能檢查嗎？ – Ashfame 2012-08-01 10:15:55

避免櫻桃採摘如果可能的話，因爲未來的合併問題（如「How to merge a specific commit in git」提到）

採摘櫻桃的提交從一個分支到另一個主要涉及生成補丁，然後將它，從而也失去了歷史。

提交ID的這個變化打破了Git的除其他事項外

嘗試合併功能來隔離你知道你將需要申請其他回購在自己提交的變化，爲了只應用這些更改。
然後一個git fetch，然後是rebase你的分支，是在你的分支歷史中包含來自上游的提交的最好方法。
這與「git workflow and rebase vs merge questions」中所述的工作流程類似（請參閱更新部分）。

來源

2012-08-01 10:26:17 VonC

謝謝！我將讀取所有內容並返回:) – Ashfame 2012-08-01 10:58:21

如果我已經完全正確，那麼每次我想要修改時，我都應該重新修改上游主節點上的修改。正確？我是否應該照顧一切，以便儘量減少碰撞的可能性？ – Ashfame 2012-09-11 22:14:26

Rebase是最好的（如果你還沒有推動你的工作）：如果你的提交按照正確的順序進行，你可以重新綁定那些位於提取的上游之上的提交。這會使你的具體變化變得微不足道。 – VonC 2012-09-12 06:07:31

爲避免採摘櫻桃，您可能需要仔細查看系統的設計/架構。它越多地被分成功能模塊，使用插件機制等，其更容易可能是添加功能和更新到兩個分支。

如果系統沒有整齊地分割成模塊，那麼在合併和合並期間沒有git工作流將解決您的問題將變得越來越複雜。

來源

2012-08-01 10:56:04

是的，它完全是:) – Ashfame 2012-08-01 10:58:28

在不同的發展方向情況下Git叉的工作流程

回答

相關問題