開発フロー
ソースコードを扱うリポジトリでは、git-flow[13]やGitHub Flow[14]などの開発フローを採用するのが一般的です。
Gitの導入初期は、git-flowとGitHub Flowのいずれかを選択しているプロジェクトが多かったのですが、現在はGitHub Flowのpull request[15]を採用しているプロジェクトが多いようです。また、ブランチ管理はプロジェクトによってまちまちで、完全に自由であったり、バージョンごとのブランチを切っていたり、git-flowのブランチ管理を採用していたりします。
筆者が携わったプロジェクトでは、開発初期はあまりルールは決めず、開発が安定してきた頃から次のような開発フローに切り替えてきました。
-
GitHub Flowのpull requestを採用
- 個人のリポジトリにforkして個別開発
- コードレビューを通ったコミットのみ取り込まれる
- git-flowのブランチ管理を採用
-
JIRAチケットとの自動連携
- 「feat/JIRA-001/newfeature」というように、JIRAのチケット番号をfeatureブランチ／hotfixブランチに加えることで、JIRAとの連携を自動化（コミットすると自動的にJIRAのチケットに更新内容が反映される）
また、開発フローに合わせて、次のような他システムとの連携も行っています。
- pull requestを受け付けるとJenkins上で自動ビルドを実行
- リポジトリへの変更は全てHipchat上で通知
- リリースに伴うタグ付けはJenkins上から簡単実行
- リリースと同時にnpm[18]やmaven[19]の社内公開用リポジトリにモジュールをアップロード
[13] Vincent Driessen氏が提唱したブランチを活用したワークフロー。git-flowのルールに沿って開発を行うことで、効率的にバージョン管理ができます。詳しくはDriessen氏のブログエントリ『A successful Git branching model』とその翻訳版をご覧ください。
[14] 米GitHubがgithub.comの開発時にも利用しているワークフロー。git-flowに比べてシンプル。 詳しくはブログエントリ『GitHub Flow』 とその翻訳版をご覧ください。
[15] 元のリポジトリからfork（リポジトリの完全コピー）した別のリポジトリで変更を行い、変更内容の取り込みを依頼（Request）し、変更内容が確認できたら取り込む（Pull）という、GitHubで利用可能な変更取り込み機能です。
[16] git-flowで定義されている機能追加用ブランチ（feature）とバグ修正用ブランチ（hotfix）。
[17] git-flowでは、開発中の変更はdevelopブランチに反映し、リリース時にmasterブランチへの反映とタグ付けを行います。
[18] node.js用のパッケージ管理の仕組み、およびそのリポジトリ。
[19] Java用のパッケージ管理の仕組み、およびそのリポジトリ。
GitHub Enterprise導入のメリット
GHE導入によりリポジトリがGitに一元化されましたが、それ以外にも様々なメリットがありました。
ノウハウの共有が手軽
公開設定されているリポジトリは誰でも閲覧できるため、他のプロジェクトのコードを参考にできたり、ライブラリが共有されたりと、手軽にノウハウが共有されるようになりました。
コードレビューの機会が増えた
pull requestを採用すると、開発フローにコードレビューを行うタイミングが自然と入ってくるため、コードレビューを行うことが当たり前になってきます。コードレビューを行うことで、お互いのスキル向上や品質の担保などにつながっています。
モバイル環境でも快適な開発
アメーバ事業本部には、カフェで仕事ができる制度が用意されています。Gitはこうしたモバイル環境下での開発に非常に向いているため、筆者もたびたび利用しながら快適な開発を行っています。
社内プロジェクトのOSS化
GHE上で開発していたプロジェクトを、そのままGitHub上に公開するケースも出てきました（https://github.com/CyberAgentを参照）。Gitを利用していなければ、これほど簡単に公開することはできなかったと思います。
おわりに
このように、多くの社員の協力もあってスムーズに組織にGitが導入され、あっという間に標準リポジトリとして定着しました。 弊社の開発スタイルにも非常に合っていたのだと思います。
まだGit導入に踏み切れていない、あるいは導入してみたもののなかなか社内に定着しない、そんな環境の方に、本記事が何かしらの手助けとなれたら幸いです。
