質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

ただいまの
回答率

90.09%

GitHubEnterpriseでの開発フロー

解決済

回答 1

投稿

  • 評価
  • クリップ 0
  • VIEW 758

nesheep5

score 48

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

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

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

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

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

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

  • 気になる質問をクリップする

    クリップした質問は、後からいつでもマイページで確認できます。

    またクリップした質問に回答があった際、通知やメールを受け取ることができます。

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

回答 1

checkベストアンサー

0

こんにちは。

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

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

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

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

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

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

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2016/12/03 13:29

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

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

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

    キャンセル

  • 2016/12/03 15:18

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

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

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

    キャンセル

15分調べてもわからないことは、teratailで質問しよう!

  • ただいまの回答率 90.09%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる