Gitを使った開発ワークフロー

2,137 views

Published on

A successful Git branching modelを邦訳してちょっとわかりやすくしました!
gitのブランチモデルで悩んでるひととか参考にしてみてください!

Published in: Technology
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,137
On SlideShare
0
From Embeds
0
Number of Embeds
34
Actions
Shares
0
Downloads
22
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

Gitを使った開発ワークフロー

  1. 1. Git中心の開発ワークフロー
  2. 2. 資料概要 • Gitブランチモデル • モデルに従ったワークフロー の順番で進めていきます。まず開発モデル を策定し、それに従ったフロー及びインフ ラを構築していきたいと思います。
  3. 3. Gitブランチモデル
  4. 4. 1-1 ブランチ一覧 ここでは色を覚え ておいて下さい。 本番 テスト 開発
  5. 5. 1-2 メインブランチ • • Master Develop Developは『次期リリースのための最新の開発 作業の変更を常に反映する、最新ソースコー ド置き場』 developのソースコードが安定しリリース準備 ができたとき、 developの全変更は『masterへ マージ』され、『リリース番号をタグ付け』す る 『masterへ変更がマージされる』=『新しい製 品リリース』 masterにコミットがあるときは毎回Gitのフック スクリプトで自動ビルドを行い、本番サーバに ロールアウトする
  6. 6. 1-3 サポートブランチ Master・developのメインブランチの隣で、チームメンバ間の平行開発(下記) を助ける様々なサポートブランチを用いる。 1. 機能追加 (feature branches 1-3-1) 2. 製品リリースの準備 (release branches 1-3-2) 3. 製品問題をすばやく修正 (Hot-Fix branches 1-3-3) メインブランチと異なり、サポートブランチは寿命が決まっており、『使い終 わったら削除』される。
  7. 7. 1-3-1 feature branches 分岐元: develop マージ先: develop ブランチ名の慣習: master, develop, release-*, hotfix-* 以外なら全 てOK Feature branchesは次期リリースに入る、または遠い将来のリ リースに入るような『新機能を開発する』のに使われる。 ある機能を開発し始めるとき、その時点ではその機能を含めるべ きリリースがどれなのか不明である。 feature branchesの本質は、 機能を開発している限りは存在しているが、結局は   developにマージされる(新機能を次のリリースに追加すると決める) 捨てられる(実験が期待はずれの場合) ということ。 feature branchesは『開発者のリポジトリにだけ存在』し、『オ リジナルには存在しない』。
  8. 8. 1-3-2 realease branches (その一) 分岐元: develop マージ先: develop と master ブランチ名の慣習: release-(リリース日)-* release branchesは『新しい製品リリースの準備をサポート』す る。 リリース最後の詰めをしっかりと行うための場所。マイナーバ グフィクスや、リリースのメタデータ(バージョン番号、ビルド日時、 他)の準備をする。 これら作業をrelease branches上で行うことで、『developは次期 リリースのための機能を受け取るために、キレイな体でいられ る』。 developから新しいrelease branchesを分岐するタイミングは、 developが新しいリリースの望ましい状態を(ほぼ)反映してい るとき。 少なくともそのリリースのビルドのターゲットとされる全ての 機能は、この時点で developにマージされていなければならない。 機能開発中のソース(feature branches)のリリースが先になる場 合、release branchesを分岐させるまではdevelopにマージしない で待つこと。
  9. 9. 1-3-2 release branches (その二) release branchesを終える release branchesが本当にリリースされても良い状態になったら、 いくつかの儀式を実行する必要がある。 最初に、 release branchesは masterにマージされる(masterにあるコ ミットは全て新しいリリースだということ)。 次に、マージコミットにはタグをつけて、後で簡単に見直せる ようにする。 最後に、 release branchesで行われた変更を developにマージす る。 releaseでやったバグフィックスなどを将来のリリースに含 めるため。 完全にリリースが終わったら、もう必要が無いのでrelease branchesを削除する。 まとめ 1. 2. 3. 4. リリースが決まった時点で、 release branchesを作成 テスト中のバグフィックスは、 release branchesのみに マージ リリース後、 release branchesをdevelopにマージ release branchesを削除する
  10. 10. 1-3-3 Hot-Fix branches (その一) 分岐元: master マージ先: develop と master ブランチ名の慣習: hotfix-* Hot-Fix branchesは、新しい製品リリースへの準備であるという 意味でrelease branchesに似ているが、計画されて行われるわけ ではない。 それは、現在の製品バージョンの望まざる状態への必要性から発 生する。製品バージョンにあるクリティカルなバグがすぐに解決 されなければならないとき、 Hot-Fix branchesはそのバージョン のタグがつけられているmaster コミットから分岐されることにな る。 その本質は、(develop上で)作業しているチームメンバーが作業 を続けられながら、別の人間が製品のすばやい修正を準備できる ことにある。 masterよりHot-Fix branchesを切り、バージョン番号を増加させる。 それからバグを修正して、コミットを行う。
  11. 11. 1-3-3 Hot-Fix branches (その二) Hot-Fix branchesを終える 修正が終わった時、そのバグフィックスを次のリリースにもちゃんと含 められるために、 『masterにマージ』されるだけでなく『developにも マージ』される必要がある。これはrelease branchesを終える時ととて もよく似ている。 最初に、masterをアップデートして、タグをつける。 次に、バグフィックスをdevelopにも含めさせる。 ※ここで一つルールの例外があり、修正タイミングでreleaseが存在して いたら、『Hot-Fix branchesの修正を developの代わりにreleaseにマー ジ』しなくていけない。 release branchesにバグフィックスをマージすると、release branches を終えたときにdevelopにも含まれることになる(developでの作業にこの修正 がすぐに必要で、releaseを終えるのを待てないなら、今ここでも develop にマージする 場合もある)。 最後に、Hot-Fix branchesを削除する。 まとめ 1. 2. 3. 4. 5. 6. masterからHot-Fix branchesを切る バージョンを増加させる バグ修正はHot-Fix branchesのみに反映 Masterをアップデートしてバージョンアップタグ付けする 修正内容をdevelopにも反映 Hot-Fix branchesを削除
  12. 12. 参考 A successful Git branching model • http://nvie.com/posts/a-successful-gitbranching-model/
  13. 13. ワークフロー
  14. 14. 2-1 ロール 2種類! スタッフ リーダー     プロジェクト責任者 ソースレビュー デプロイ 1プロジェクト1人! Main / Release / HotFix / Develop branch     コーディング ソースアップ要求 テストとか いっぱいいる Future branch
  15. 15. 2-2 ワークフロー テスト完了後、 テスト環境に自動デプロイ(Cap) テス ト ・継続的インテグレーション 自動監視して、変更があればテスト実行 Develop branch Git Capestrano Jenkins Pull(Merge) request ステージン グ Release branch Hot-Fix branch Develop Master branch Fork clone clone 本番 ステージング・本番 は管理者がCapデプロ イ リーダーはPull requestを精査し 問題がなければ取り込む Pull/Push 開発者同士のpull,pushは自由

×