GitHubEnterpriseでの開発フロー

Question

新規プロジェクトが立ち上がり、GitHub Enterpriseでの開発を行おうとしています。
その際の開発フローとして、

1. 一般的なOSS開発のような、各開発者がそれぞれForkをして開発→PRでマージ
2. GitHubフローのような、Forkをせず一つのリポジトリ使い、各自作業ブランチを切って開発→PRでdevelopブランチにマージ

のどちらを採用しようか（またはもっと良い方法があるか）迷っています。

以前GitHubフロー的アプローチを試したとき、作業ブランチが乱立しごちゃごちゃした印象があったため、他に良いアプローチがないか模索している状況です。Forkをつかった開発は実戦経験がありません。

開発メンバーは15名くらいになる想定です。
またGitの経験が浅いメンバーが多いです。

両方のメリット・デメリット、また経験談などお聞きして参考にさせていただきたいなと思っています。
よろしくお願いします。

Answer 1

こんにちは。

私自身Gitの経験が浅いので申し訳ないのですが、回答させて下さい。

作業ブランチが乱立しごちゃごちゃした印象

GitHub Flowはmasterへマージ（リベース）したブランチは削除すると理解してます。
つまり、作業が完了したらブランチはなくなるので、作業中の項目についてごちゃごちゃするのは仕方がないし、逆に各作業の進捗をチェックしやすいというメリットもありそうです。

オープンソースで各貢献者の進捗管理を行わないのであれば、Forkすることで管理対象から外れるので好ましいと思います。逆に、プロジェクト・チームとしての開発の時は各メンバーがForkすると管理し辛くなりそうです。

ところで、仕様Fix→リリース準備→リリースの工程が必要なプロジェクトについては、Git FlowやGitLab Flowのようにリリース用のブランチを設ける必要があると思います。（Bug Fix反映の手間が余分にかかるのでできるだけ避けたいです。）
また、GitHub Flowのmasterをいつでも「デプロイ可能」にすると言う方針は、プロジェクトによると感じてます。
オンラインなプロジェクトなら妥当ですが、ダウンロードして使うようなプロジェクトの場合は、masterにタグを付けてリリース・バージョンを管理するのが妥当な気がしてます。

ところで、私は経験が浅いため、いきなりGitHubへpushすることがちょっと心配です。
なので、ローカルにベア・リポジトリを作って、作業用リポジトリはそのローカルなベア・リポジトリをorign指定し、更にそのベア・リポジトリのoringをGitHubのリポジトリにすることで、ワンクッションおいて運用してます。
そのベア・リポジトリへのpush時になにかやらかしても、再度GitHubと強制的に同期すれば被害はないのでちょっと安心感があります。

Comments

[nesheep5]

コメントありがとうございます。

ブランチはmerge後の消し忘れ（または不安感から意図的にしばらく残しておく）ことが多かったように思います。
各作業の進捗をチェックしやすいというのはたしかにおっしゃるとおりですね。
きちんとルールを定めた上で、GitHub Flowで運用していくのが良さそうかなと感じました。

ローカルにベア・リポジトリを作成する、というのは目からウロコでした。
試してみようと思います。
丁寧なコメントありがとうございました、大変参考になりました。

[Chironian]

> ブランチはmerge後の消し忘れ（または不安感から意図的にしばらく残しておく）ことが多かったように思います。

なるほど。確かに「あるある」ですね。

GitHubならIssueとブランチをリンクしてIssueでステータス管理できないでしょうか？
そもそもGitHubでmaster以外のブランチを作ったことがないので分かりませんが、GitHub Flowと言うくらいだからできそうな気もします。