Recent Changes

2016-04-25
2014-04-08
2013-02-16
2012-12-22
2012-11-25

Latest File Release

setucocms (1.6.1)2013-03-24 21:20

Wiki Guide

Side Bar

Gitリポジトリ運用ルール

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であれば、チェック担当者は差し戻して4~6を繰り返す。
OKになったら、7に進む。

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であれば、チェック担当者は差し戻して4~6を繰り返す。
OKになったら、7に進む。

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です。

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