サイトリポジトリの運営

サイトリポジトリは、他のサイトの開発を壊す心配なくコミットが可能ですが、それでも複数人で無秩序にコミットすると、後で大変な マージ作業が待っているので、きちんとルールを決めて運用することが必要です。
原則はフィーチャーブランチを使ったプルリクエスト方式です。Git以前のSCMには存在しなかった概念なので、しっかりとした理解が大切です。

以下では、各チームに合わせたサイトリポジトリの運営方法を説明します。

サブシステム開発チームでの運営

開発チームには、今までGitを触ったことがなかったり、そもそも開発未経験であったりと、さまざまな状態が考えられます。 そのような中で、いきなり手順がやや複雑なプルリクエスト方式を定着させるにはそれなりの学習コストがかかる恐れがあります。 そこで、開発チームの運用ルールはメンバーのGitの習熟度に応じて段階的に変更してくことをお勧めします。

以下で、メンバーのGitの習熟度、および開発工程のフェーズによる段階的な運用ルールの変更例を紹介します。

■ 導入初期（中央管理型方式）

開発工程の初期、かつ、Git初学者がメンバーのほとんどを占めている状態を想定しています。 開発工程の初期はソースコードも新規のものがほとんどで、プロトタイプを実装することが多いため開発のスピードが重視されます。 この段階でやや複雑なルールであるプルリクエスト方式を取り入れた場合、他者の修正の取り込みが追い付けず競合する恐れがありますので masterブランチに対するpush/pullという基本的なコマンドのみ(中央管理型方式)で運用 していきます。また、Git初学者にとってはSubversionと同様の考え方で開発ができるため学習コストが抑えられます。

start-up

  1. ローカルにサイトリポジトリのmasterブランチを複製します。
    $ git clone [サイトリポジトリURL]
  2. 実装します。
  3. コミットします。
    $ git add [ファイル名]
$ git commit -m "コミットメッセージ"
  4. サイトリポジトリの最新のソースを複製したローカルのmasterリポジトリに反映させます。
    $ git pull origin master
  5. 動作確認後サイトリポジトリのmainブランチにローカルのmaserブランチの修正内容をpushします。
    $ git push origin master

■ 成長期（フィーチャーブランチ方式）

開発工程の初中期、かつ、メンバーがgitのpush/pullを問題なく扱えている状態を想定しています。 開発工程の初中期は実装が完了している機能がいくつかmasterブランチにコミットされていますので、実装が完了しているものの修正と新規機能の開発とが並走していると考えられます。 ここで、各作業者が作業単位のブランチを作成して実装していく運営ルール（フィーチャーブランチ方式）に変更します。
これにより作業者はブランチというカテゴライズされたスペースで自由に実装を試したり、捨てたりすることができます。 コミットコメントやコミットポイントなどの修正も、ローカルの自分のブランチ内であればmasterにpushをしない限り、 何をしても他メンバーに影響を与えません。また、Gitは作業者が行ったすべてのコマンドを記録しているため、 ブランチがどういう状態かわからなくなってしまったとしても、いとも簡単には元に戻すことが可能です。これはGit（分散型バージョン管理システム）の強みの一つといえます。
ここでもなおプルリクエスト方式にしない理由は、やはりプルリクエスト方式は複雑であるため、チームの開発リズムが安定していない状態で行うとかえって混乱と競合を招く可能性があるためです。 この時期にしっかりとブランチの考え方を身に付けてから次のステップに進むことをお勧めします。

growing

  1. ローカルにサイトリポジトリのmasterブランチを複製します。
  2. ローカルに複製したmasterブランチからフィーチャーブランチを生成し、移動します。
    $ git checkout -b [ブランチ名]
  3. 実装します。
  4. コミットします。
  5. サイトリポジトリの最新のソースを複製したローカルのmasterリポジトリに反映させます。
    $ git checkout master
$ git pull origin master
  6. ローカルのフィーチャーブランチに最新のmasterの状態を取り込みます。
    $ git checkout [ブランチ名]
$ git merge master
  7. 動作確認後サイトリポジトリのmasterブランチに対してローカルのフィーチャーブランチの修正内容をpushします。
    $ git push origin [ブランチ名]:master
    ※「:」の左にはpush元となるローカルブランチ、右がpush先のリモートブランチを指定します。

■ 安定期（プルリクエスト方式）

開発工程の中期～末期、かつ、メンバーがgitに対して難なく作業が行える状態を想定しています。 開発工程の中期から、masterのソースはバグ一つないクリーンな状態にし、メンバーはそれを守りながら残りの機能の開発を行う必要があります。 この状態になって初めて後述する定期マージ方式が可能になり、ベースリポジトリへのマージ準備が整うことになります。 成長期の運用フローを行ってきたメンバーであれば既にフィーチャーブランチの切り方やローカルとサイトリポジトリの関係がしっかり理解できていると思われますので、プルリクエスト方式を導入します。
まず初めに、チームの管理者はサイトリポジトリのmasterブランチからmainブランチを複製してください。このmainブランチはこれまでのmasterブランチの役割を担い、各プログラマの修正分の取り込み先になります。つまり、各プログラマが今後masterブランチに対して何かすることは原則なくなります。
成長期ではローカルのフィーチャーブランチから直接サイトリポジトリのmasterにpushしていたのに対して、 プルリクエスト方式では一度サイトリポジトリにそのフィーチャーブランチをpushし、GitBucketの機能であるプルリクエスト機能を用いてフィーチャーブランチの修正分をmainブランチへ取り込みを依頼することになります。
プルリクエストはGitBucketの機能の一つで、プルリクエストの単位でのコミットログ、修正ファイル数、差分が表示されるのでレビューアは容易にレビューを行うことが可能になります。

stability

branch model

  1. ローカルにサイトリポジトリのmainブランチを複製します。
  2. 作業のかたまり毎にmainブランチからフィーチャーブランチを作ります。
  3. 実装します。
  4. コミットします。
  5. サイトリポジトリの最新のソースを複製したローカルのmainリポジトリに反映させます。
  6. ローカルのフィーチャーブランチに最新のmainブランチを取り込みます。

  7. 動作確認後サイトリポジトリにローカルのフィーチャーブランチをpushします。

    $ git push origin [ブランチ名]

    ※ push元となるローカルのブランチ名とpush先のリモートブランチ名が一致する場合、「:」は省略が可能です。

  8. GitBucketでフィーチャーブランチからmainブランチへのプルリクエストを送ります。

オフショアの開発などmainブランチにマージする前に、受け入れテストやコードレビューを実施したい場合は、直接mainブランチから フィーチャーブランチを作るのではなく、mainブランチからdevelopブランチを作り、developブランチからフィーチャブランチを作る ようにするとよいでしょう。

チームの体制によってはプルリクエスト方式には移行せず、中央管理型方式のまま開発を進めてしまった方がよい場合があります。
判断基準としては、例えば以下があげられます。
　・各チームに運用方式を理解し、手引く人間がいない
　・拠点が離れており、チームメンバーの前でデモができない
　
プルリクエスト方式にしたものの、プルリクエストが放置され続けたりすることは競合などの問題を引き起こし、かえって対応コストがかかってしまいます。あるチームはプルリクエスト方式で、またあるチームは中央管理下型方式で運用するのも一つの手ではないかと思われます。