GitHub で Pull-Request を送るためにレポジトリを fork すると、オリジナルと同一のレポジトリが自分の管理下に作成されます。 Pull-Request の入門記事では、Pull-Request がマージされた後、この fork したレポジトリをどう扱うべきかを述べている記事は少ないように思えます。 そのため、そのようなレポジトリをどう扱ったらよいか分からない人もいるのではないでしょうか。
この記事では、fork したレポジトリを扱う際に生じる疑問について解説をしようと思います。
なお、この記事では OSS に Pull-Request を送る一般的な場合を想定して書いていますが、業務で fork 型の開発を行っている場合なども同様の結論が得られると思います。
また、Pull-Request を送る際に想定する詳細な手順などは GitHub で Pull Request を送る際の流れ - pockestrap に書いてあるので、もし興味があればご覧ください。
TL;DR
- Pull-Request を出した際のブランチを消す必要はあるか？
- 必須ではないが、どちらかというと消しておいたほうが良い
- fork したレポジトリを消す必要はあるか？
- ない
- fork したレポジトリの master を upstream に追従させる必要はあるか？
- ない
以下では、上記の結論が導き出される理由を述べます。
Pull-Request を出した際のブランチを消す必要があるか？
必須ではないが、どちらかというと消しておいたほうがよいです。 気がついたら消しておく、ぐらいの感覚で良いと思います。
消した場合のメリット
- ブランチ一覧がスッキリする
消した場合のデメリット
特に無し。
同じ機能を続けて同じブランチで開発する場合には、ブランチを消さない運用もありかも知れません。
fork したレポジトリを消す必要はあるか？
消す必要はありません。
消した場合のメリット
- レポジトリ一覧がスッキリする
- スッキリさせる必要を、私は感じたことがありません。
消した場合のデメリット
- 消すのがめんどい
- もう一度同じレポジトリに Pull-Request を送る際には、再度 fork する必要がある
fork したレポジトリの master を upstream に追従させる必要はあるか？
追従させる必要はありません。
master の参照は origin/master を参照すれば良いため、fork したレポジトリの master を参照する機会は殆どありません。 そのため、fork したレポジトリの master を更新することは、殆どの場合に置いて意味がありません。
追従させた場合のメリット
特に無し
特殊なケースとして、CIの設定(例: .travis.ymlの編集)などを試すために、forkしたレポジトリの master を参照する必要があることもあります。
追従させた場合のデメリット
- 管理が煩雑
- origin/master が更新される度に fork した master にも push しなければいけない
