Gitリポジトリ運用ルール - 【discontinue development 】SetucoCMS Wiki - 【discontinue development 】SetucoCMS...

Gitリポジトリ運用ルール

Outline

• バージョン番号の構成
• githubのリモートリポジトリのブランチ
• 各自のローカルリポジトリのブランチ
• 開発の流れ
  • シナリオ1　次リリースに向けた変更（過去のリリースへのフィードバックが必要ない場合）
  • シナリオ2　次リリースにも過去のリリースにも反映するバグ修正/リファクタリングの場合
  • シナリオ3 過去のリリースにのみ反映するバグ修正/リファクタリングの場合
• ちょっとした修正の場合は

Gitの操作方法について Git_Git導入／操作まとめ

バージョン番号の構成

書式は「x.x.x」で、左からメジャーバージョン、マイナーバージョン、パッチバージョン。それぞれ半角数字で、桁数の制限はない。

• メジャーバージョン

大幅な機能追加または変更、UIの変更などがあったときにインクリメント。

• マイナーバージョン

ちょっとした機能追加または変更、UIの変更などがあったときにインクリメント。

• パッチバージョン　

仕様に変更がなく、バグ修正やリファクタリングが行われたときにインクリメント。

githubのリモートリポジトリのブランチ

• master

メインのブランチ。常に最新の（作業済みのissxxxがマージされた）内容。

• issxxx　

各自にアサインされた開発チケット一枚につき一つ作る。xxxはチケットNo。作業用のトピックブランチ。開発作業およびレビュー用に使う。

• x.x　　

リリース毎にmasterから作成されるリリースブランチ。パッチバージョンを含めたバージョン番号はこのブランチ上にタグで記録していく。※

※あくまでもブランチ名は 「メジャーバージョン.マイナーバージョン」 であり、パッチバージョンまで含めたバージョン番号はタグでつけていく。

各自のローカルリポジトリのブランチ

• master　

リモートの同名ブランチとおなじ。

• issxxx　

同上

基本的に、ソースコードの変更が生じるものは

1. チケットxxxが登録される
2. issxxxブランチを作って作業
3. commit、push
4. masterまたはリリースブランチにmerge
5. チケットクローズ

の流れになります。 ちょっとした修正の場合は も参照してください。

開発の流れ

以下の3パターンがありうる。

• シナリオ1

次リリースのみに反映する（過去のリリースへのフィードバックが必要ない）変更/追加の場合

• シナリオ2

次リリースにも過去のリリースにも反映するバグ修正/リファクタリングの場合

• シナリオ3

過去のリリースにのみ反映するバグ修正/リファクタリングの場合

シナリオ1　次リリースに向けた変更（過去のリリースへのフィードバックが必要ない場合）

masterブランチからトピックブランチを切って開発を進め、開発が完了したらトピックブランチをmasterブランチにマージする。
次リリースバージョンに向けた変更とは、機能の追加/変更、リリース済みの過去のバージョンには反映しないバグ修正/リファクタリングを指す。

1）担当者はリポジトリから最新版（master）を取得

$ git checkout master
$ git pull origin master

2）担当者はRedmineでチケット起票（チケットNoが372だったとする）

3）担当者はローカルリポジトリでトピックブランチ"iss372"を作る

$ git checkout master
$ git checkout -b iss372

4）担当者は、iss372ブランチで作業を進める

※このiss372ブランチでの作業中に他の開発者によってmasterブランチが更新された場合は、

$ git checkout master
$ git pull origin master
$ git checkout iss372
$ git rebase master

として、最新のmasterの状況をiss372ブランチに取り込んでください。
git-rebaseについては、詳しくはこちらを参照してください。
http://www8.atwiki.jp/git_jp/pub/Documentation.ja/user-manual.html#using-git-rebase

5）担当者は、作業が終わったら（=テストが通り、ブラウザ上で機能が確認できたら）iss372ブランチをgithubにpush

$ git checkout iss372
$ git push origin iss372

※push後、githubにiss372ブランチが反映されていることを確認すること

6）チェック担当者は、iss372ブランチを取得して修正確認

$ git pull origin iss372:iss372

NGであれば、チェック担当者は差し戻して４～６を繰り返す。
OKになったら、７に進む。

7）開発者は、チェックOKになったらiss372ブランチをmasterブランチにマージし、masterブランチをgithubにpush

$ git checkout master
$ git pull origin master
$ git merge --no-ff iss372

※このとき、自分以外のメンバーが行った変更とコンフリクトが起きたら解消すること
※masterにマージ後、テストが通ること、振る舞いが正しいことを確認すること

$ git push origin master

※push後、githubのサイトにmasterブランチの更新が反映されていることを確認すること

8）開発者は、ローカルとリモートのトピックブランチを削除する

$ git branch -d iss372
$ git push origin :iss372

※githubのサイトからiss372ブランチが消えていることを確認すること

9）開発者は、Redmineのチケットをクローズする

シナリオ2　次リリースにも過去のリリースにも反映するバグ修正/リファクタリングの場合

機能追加ではないが、バグ修正/リファクタリングを行い、次リリースとリリース済みの過去のバージョン両方に反映させる必要がある場合。

1）シナリオ1の1〜7までと同じ流れで作業する

※ただし、作業中に他の開発者によってmasterブランチが更新されても、
　git rebase によるトピックブランチへの取り込みはしなくてOKです。
　（過去のリリースに含んではいけない変更がmasterブランチから取り込まれる可能性があるため）

2）過去のリリースブランチに変更を反映する

リリースブランチ 1.0 に変更を反映するとする。

$ git checkout 1.0
$ git merge --no-ff iss372

3）リリースブランチ上にタグを付ける

$ git checkout 1.0
$ git 1.0.1

タグ名は、同ブランチ上で一番新しいパッチバージョンをブランチ名の後ろに付けたものにする。

4）githubにリリースブランチとタグをpushする

$ git push origin 1.0
$ git push origin 1.0.1

※githubのサイトで、ブランチ1.0が最新になっていて、タグ1.0.1が選択できることを確認すること。

5）開発者は、ローカルとリモートのトピックブランチを削除する

$ git branch -d iss372
$ git push origin :iss372

※githubのサイトからiss372ブランチが消えていることを確認すること

6）開発者は、Redmineのチケットをクローズする

シナリオ3 過去のリリースにのみ反映するバグ修正/リファクタリングの場合

※基本的にシナリオ1の「masterブランチ」を「リリースブランチ」に置き換えた流れになる

修正対象のリリースブランチからトピックブランチを切って開発を進め、開発が完了したらトピックブランチをリリースブランチにマージする。

1）担当者はリポジトリから該当リリースブランチの最新版を取得。ここではブランチ1.0とする。

$ git pull origin 1.0:1.0
$ git checkout 1.0

2）担当者はRedmineでチケット起票（チケットNoが372だったとする）

3）担当者はローカルリポジトリでトピックブランチ"iss372"を作る

$ git checkout 1.0
$ git checkout -b iss372

4）担当者は、iss372ブランチで作業を進める

※このiss372ブランチでの作業中に他の開発者によって該当のリリースブランチ1.0が更新された場合は、

$ git checkout 1.0
$ git pull origin 1.0:1.0
$ git checkout iss372
$ git rebase 1.0

として、最新の1.0の状況をiss372ブランチに取り込んでください。
git-rebaseについては、詳しくはこちらを参照してください。
http://www8.atwiki.jp/git_jp/pub/Documentation.ja/user-manual.html#using-git-rebase

5）担当者は、作業が終わったら（=テストが通り、ブラウザ上で機能が確認できたら）iss372ブランチをgithubにpush

$ git checkout iss372
$ git push origin iss372

※push後、githubにiss372ブランチが反映されていることを確認すること

6）チェック担当者は、iss372ブランチを取得して修正確認

$ git pull origin iss372:iss372

NGであれば、チェック担当者は差し戻して４～６を繰り返す。
OKになったら、７に進む。

7）開発者は、チェックOKになったらiss372ブランチをリリースブランチ1.0にマージする

$ git checkout 1.0
$ git pull origin 1.0:1.0
$ git merge --no-ff iss372

※このとき、自分以外のメンバーが行った変更とコンフリクトが起きたら解消すること
※1.0にマージ後、テストが通ること、振る舞いが正しいことを確認すること

8）開発者は、タグで新しいパッチバージョンを付ける

$ git checkout 1.0
$ git tag 1.0.2

※タグ名は、同ブランチ上で一番新しいパッチバージョン（ここでは".2"とする）をブランチ名"1.0"の後ろに付けたものにする。

9）開発者は、リリースブランチとタグをgithubにpushする

$ git push origin 1.0
$ git push origin 1.0.2

※githubのサイトで、ブランチ1.0が最新になっていて、タグ1.0.2が選択できることを確認すること。

10）開発者は、ローカルとリモートのトピックブランチを削除する

$ git branch -d iss372
$ git push origin :iss372

※githubのサイトからiss372ブランチが消えていることを確認すること

11）開発者は、Redmineのチケットをクローズする

ちょっとした修正の場合は

ちいさいバグ見つけて直したとか、ちょっとしたリファクタリングとか、
ドキュメントの文言を直したとか、そういう大したことのない修正のときは
トピックブランチを切らずに、とりあえずmasterブランチで作業・pushしてしまってOKです。

ただしその場合も、後からでいいので、レビューしてもらうために
チケットは必ず作り、チェック担当者にチェックを頼んでください。