github-flowを使っての開発(3) －1つのプロジェクトを複数人で開発－

今まで2回ほどgithub-flowをもとにした開発の流れを書きました。
今回は、複数人で開発をする時の流れを書いてみます。

github-flowでの開発

githubを使っての開発(1)　－実践github-flow－ | PPl@ce
githubを使っての開発(2)　－masterブランチにマージ－ | PPl@ce

　前提

• プロジェクト管理システムを使っている(trac、redmine、JIRA)
  • チケットでタスクを管理している

　最初にproject用ブランチを作成

まず作成するブランチにチケットのナンバーもつけておきます。

• git checkout master
• git checkout -b 134_project_name

このブランチで何かしらの作業はしません。
このブランチは、PullRequestのときのmerge先とします。

　開発サイクル

　プロジェクト用のブランチから各チケット単位でブランチを作成

チケット単位でタスクを管理しているので、そのタスク単位でブランチを作成します。

• git checkout 134_project_name
• git pull
• git checkout -b 145_new_task_name

　各ブランチで開発をおこない終わったらPullRequest

作成したブランチで開発をおこない、適宜コミットをしていきます。
完成したら、最初に作成したproject用のブランチにPullRequestを投げます。

　レビュー＆merge

ソースコードレビューをgithub上でおこない、修正＆レビューを繰り返します。
問題なくなったら、project用ブランチにmergeします。

　チケットを閉じる

mergeされたらチケットをcloseします。

プロジェクト用のブランチは、このプロジェクトにおける最新の状態にしておき、できればテスト環境にデプロイをします。
常に最新の状態をテスト環境で試せるようにします。

　注意点

　masterブランチに何かがmergeされたら？

このプロジェクトを開発している間に、新しい機能がリリースされmasterにmergeされるケースもあります。
その場合は、masterにmergeされた段階でプロジェクト用のブランチに組み込みます。
影響範囲を知るためにも早めにとりこみます。

　merge後に問題がおきたら？

何かの機能をmerge後に問題がおきて動かなくなったらどこで修正するか？というのがあるかと思います。
これは、ケースバイケースですが、そのmergeしたブランチを一回外して、そのブランチで修正してから再度mergeするのが良いです。

プロジェクト用のブランチは各チケット単位のブランチのmergeされただけの状態にします。
つまり、プロジェクト用のブランチで修正作業などはしません。
これは、仮にある機能がいらなくなった場合に対応しやすいようにするためです。