はじめに

最近は C#実践開発手法 (マイクロソフト公式解説書) という本でアジャイル開発を軽く勉強しているaridaiです。
今回は git-flow を使い始めたり、プルリクエスト を使ってみたりしたのでメモしてみます。

git-flowとは

git-flow はブランチ運用モデル、また、そのためのプラグインを指す用語のようです。
役割ごとのブランチ分割がしっかりされているのが特徴らしいです。

ブランチの種類

機能ごとに作るブランチについてメモしたいと思います。

masterブランチ

リリースできる状態のものが置かれています。
タグの管理もここで行います。

基本的にはこのブランチに直接コミットはしません。
(ブランチのマージコミットが中心です。)

developブランチ

開発用ブランチです。
最新の開発状態を持っています。

このブランチも直接的なコミットはしません。
(ブランチのマージコミットが中心です。)

feature/...ブランチ

機能追加や変更、バグ修正などを行うブランチです。
作業ごとに細かく分けてこのブランチを作ります。

developブランチから派生し、作業終了後にdevelopブランチへマージします。
マージ時には non fast-forward な状態でマージします。
(マージコミットを残すためにあえてそうします。)
そして、マージ後はこのブランチを削除します。

hotfix/...ブランチ

リリース直後の臨時のバグ修正を行うためのブランチです。
リリース済みバージョンのバグを修正するためのものなので、masterブランチから派生し、masterブランチとdevelopブランチへマージします。

マージ後はマイナーバージョンアップをして、このブランチは削除します。

release/...ブランチ

リリース直前の作業を行います。
このブランチを切ることで、リリースしたい機能に開発中の機能が混じらないようになります。

developブランチから派生し、masterブランチとdevelopブランチにマージします。
マージ後はバージョンアップをして、このブランチは削除します。

GitHubでのIssueとプルリクエストについて

最近は何かと Issue を利用しています。
マークダウンをサポートしていたり、コミット や プルリクエスト などの参照機能もあってとても便利です。
今回は Issue に対して、実装をし、それを プルリクエスト として送ってみたので、その流れについてメモします。

1.ブランチを切る

まず、作業用のブランチを切ります。
git-flow の運用方式を採用するならば、feature/... という名前のブランチになるでしょう。

2.コミットする

次は実装作業です。

GitHubでは Issue や プルリクエスト に # で始まる番号が割り当てられています。
ここで、作業時のコミットメッセージに #{Issue番号} を含めることによって、該当する Issue のページで参照がされます。

3.GitHub上でプルリクエストを送る

サイトの方の New pull request からプルリクエストを送ることができます。
base側にマージ先のブランチ、compare側に先ほどの作業用ブランチを指定します。
ここでもメッセージに #{Issue番号} を含めると自動的に該当ページで参照がされます。

このような流れで プルリクエスト を送ることができます。

さいごに

私もまだまだGit初心者ですので、これからも積極的に使っていきたいと思います。
何かご指摘がありましたら教えてください。