1
我們分叉了一個Github項目並對其進行了更改。對於每項任務，我創建一個單獨的分支，然後我將它合併到叉子中的master。將分叉推送爲多個拉取請求
所以現在我有一個master工作，就像原始回購中的master之前的20個提交。
該項目的規則是create pull request for each task。
雖然，我知道怎麼做git，但我不確定這個過程。
我不確定的是我如何創建第二個提交中的任務1的拉取請求，然後是第五個提交中的任務2等。
我犯了一個錯誤，現在只能同時爲多個修復創建拉取請求嗎？
我是不是應該做這樣的：
修復任務
上叉
創建叉主拉請求，原來的主用主控合併嗎？
編輯
@OliverCharlesworth你的建議是我在過去的工作方式，但它帶來了許多問題。由於我首先解決了一些任務，然後爲每個任務創建PR，但它與主人創建了很多衝突（徒勞）。所以每次我創建PR時，我都會收到一條消息，說它不能自動合併，但我必須先解決衝突。然後，對於90％的PR，我必須處理合並，並且僅在合併時損失幾個小時。
這就是我認爲我做錯了的原因。
所以當我切換到規則「修復1任務，然後合併爲主人」，我避免了所有這些愚蠢的衝突，並保存我們的合併。
既然你說「從分公司做公關」是正確的路要走，如何避免愚蠢的衝突並且不會在愚蠢的合併過程中失去幾個小時？
注意：當我說「愚蠢」時，這意味着所有的衝突都會回到相同的代碼片段中去。當我遵循新規則時，永遠不會發生的事情。傻乎乎的意思是「沒有很好的理由就會失去合併時間」。
如果您將更改推送到您的主分支（這是一個分支），您在上游回購中所做的pull請求將更新並顯示您主分支中的所有提交。 AFAIK沒有辦法避免這種情況，除非你爲每個任務創建一個額外的分支並承諾這一點，併爲它們製作一個PR。 – CoDEmanX
解決方案是不合併到您的叉子上的主。從分支中創建一個PR回原始的回購。 –
@OliverCharlesworth請檢查編輯。評論太長了。 – sandalone