在github上分叉，那麼我如何管理我的貢獻？

Question

我有點不清楚在github上跟隨fork的forkflow。

如果我在原始存儲庫中有幾個小型獨立修復程序，那麼中型項目OpenGrok會怎樣？

• 是否爲每個相對較小的不相關的錯誤修正創建單獨的分支？

• 我是否從master創建了每個分支，還是我可以從下一個分支一個不相關的分支？我是否修復master？

我的意思是，隨着時間的推移，我還是希望保留歷史和所有，但我只是擔心，經過一段時間就會有問候一塌糊塗了很多無意義的分支相對修正了一些小錯誤。

我計劃爲一個給定的項目貢獻一些非相關的修補程序，並試圖對開發方法進行一些規劃。

Answer 1

在github上分支項目並計劃向上遊提交更改時，有幾種可能的工作流程。這是我的工作流程通常傾向於遵循（我會打電話給我從中已經分叉爲遠程source回購，回購我作爲origin）之一：

• 叉主枝通過source使用，讓我們假設master爲origin/my-dev。
• origin/mydev是我所有的改變和主要發展。
• 我經常將remote/master重新編號爲origin/master（這一步是多餘的，但有時候我很容易在一個遙控器中找到所有東西）。
• 只要您想從上游獲取更改，請合併source/master或重新設置的origin/master到origin/my-dev。
• 如果我想向上遊提交補丁或bugfix，我會啓動一個新的功能分支，可以用於拉取請求。我會稱之爲origin/my-feature-1。我創建了此分支origin/master（或source/master）
• 我將這項功能的更改轉換爲origin/my-feature-1，並將origin/my-dev中的此功能更改爲origin/my-feature-1。完成此步驟後執行任何測試。
• 從origin/my-feature-1
• 提交pull請求，如果你的拉請求被批准，修改將被合併到source/master（和origin/master太）。
• 執行從origin/master（或source/master）到origin/my-dev的合併。
• 就分支機構的生命週期而言，我通常傾向於在我將它合併到上游之後擺​​脫短期主題或功能分支（分支只是git中引用特定提交的輕量級指針）。

不斷重複此工作流程。

的核心思想是，你拉的請求應該不會構成對上游維護者或他的任何嚴重衝突/她要盲目地拒絕了貢獻。

我舉例說明了一個例子，當您想從origin/my-dev上游貢獻D2和D3。 D2'和D3'被重訂的D2和D3版本。與U犯有上游提交的source，D在origin您下游的提交。與M後綴的是合併。

在視覺上，這是它會是什麼樣子：

source/master    origin/my-dev 
    U1 
    U2 Initial-fork 
    U3-----------\ 
    |    \ 
    |    \------------D1 
    |       D2 
    U4 Sync up from upstream | 
    U5-----------\    D3 
    |    \    | 
    U6    \------------DM4      origin/feature-1 
    |       | 
    |       |  Starting point of feature-1 
    U7------------------------------------------------------------D2' (Rebased version of D2) 
    |       |         D3' (Rebased version of D3) 
    |       D5        /
    U8       D6  Pull-request   /
    |       |  getting merged upstream/
    UM9--------------------------------------------------------/ 
    |       | 
    |    Resync  | 
    |-------------\ my-dev  | 
    U9    \   | 
    U10    \-----------DM7 
    |       | 
    |       |