図解驳颈迟飞辞谤办蹿濒辞飞蝉(7)
- 2. gitworkflows(7)とは? Gitプロジェクト自体で使われているワークフローで す。 詳細はGitとともに配布されているオンラインマニュ アル gitworkflows(7) にあります。
- 3. なぜgitworkflowsなのか? ● 統合ブランチにpush -fできる ● トピックを気軽にマージできる ● masterを安定させ、綺麗な歴史を残せる ● 開発者の人数に対してスケーラブル Gitをつかうとコミットやトピックブランチを好きなよう に修正できますが、gitworkflowsを使うと統合ブラ ンチに対しても好きなように修正できるようになりま す。
- 12. ‘pu’ はその使い捨て統合ブランチの名前です。puは ‘Proposed Update’ の略です。 pu
- 13. ‘pu’ は使い捨てでない、最も進んだブランチの先端から分岐させ ます。今回の場合 ‘master’ が適切でしょう。 (git branch pu masterでできます)
- 14. トピックブランチをマージしていきます。Aと… (checkout pu および merge topic-A) merge
- 15. 続いて B ... merge
- 16. それから C を ‘pu’ にマージします。 merge
- 18. ちなみに ‘pu’ は、必要があれば公開リポジトリにpushして構い ません。(push origin pu) 例えばCIサーバがテストを走らせるのに公開リポジトリを監視し ていて、そこにpushしたい場合などです。
- 22. ひきつづき ‘pu’ にマージする? いいえ。 ‘pu’ は使い捨て統合ブランチです。
- 23. ですから、‘pu’ を ‘master’ にリセットします。 (checkout pu および reset --hard master を実 行) reset
- 29. 全ての開発者は ‘pu’ の上で作業できないことに注意してくだ さい。全てのトピックは ‘master’ から分岐する必要がありま す。
- 30. リセットしない場合、結果として得られるブランチ / コミットグラフ は、同じツリーにも関わらず少しややこしくなります。 この2つのコミットのツリーは同一 - with reset - without reset
- 32. 一度古い ‘pu’ をpushしていた場合、新しい ‘pu’ はoriginにある 古い ‘pu’ の直接の子孫ではないので、push -f origin pu または push origin +pu する必要があります。
- 33. テストの後、A と B の機能は良く出来ていて安定していること、C はそうでもないことがわかりました。
- 34. A と B は十分安定しているので ‘master’ にマージすることにし ます。
- 35. トピック A と… (checkout master と merge topic-A を実行) merge
- 36. トピック A と B を ‘master’ にマージします。 merge
- 37. # トピック A, B はこのスライドではもう重要ではないので # グレーアウトします
- 39. 再び ‘pu’ を ‘master’ にリセットします (checkout pu と reset --hard master を実行) reset
- 40. ‘pu’ リセットするということは、古い ‘pu’ を捨てることになりま す。
- 41. その后...
- 42. C をマージしたら、 ‘master’ と ‘pu’ を push します。 ‘pu’ は強制 push が必要なので、次を実行します: git push origin master +pu (ブランチ名の前の ‘+’ は強制pushを意味します) merge
- 45. v1.0.0 リリースタグの名前は ‘v1.0.0’ です。その後pushします (tag -a ‘v1.0.0’ master および push origin v1.0.0) tag
- 47. リリース作成の後、新しく作成されたトピックを受け取りまし た。 それらは ‘master’ から分岐しているはずです new topics
- 52. 心配事とは: - 実装は安定しているか - 良い設計になっているか - そもそもその機能は必要なのか 等です
- 53. 一見よさそうでしばらく変更もしないトピックを ‘pu’ に保持して おくのは面倒ですが、もしかしたら変更?削除する可能性もあ るので、 ‘master’ にマージするのもためらわれます。
- 56. ‘next’ は ‘master’ から分岐させます。 (branch next master)
- 57. 古いアクティブトピックのCからマージして... (checkout next and merge topic-C) merge
- 60. というわけで今回は ‘pu’ を ‘next’ の上に再構築します (checkout pu and reset --hard next) reset
- 62. その后...
- 64. そうしたら ‘next’ と ‘pu’ をpushします (push origin next +pu)
- 65. 統合マネージャを含め、全ての開発者は ‘next’ の上で作業 できないことに注意してください。全ての機能ブランチは ‘master’ から分岐させるべきです。
- 66. ところで ‘next’ と ‘pu’ の違いは何でしょうか?
- 69. その場合、単に ‘pu’ を ‘next’ にresetして… (checkout pu and reset --hard next) reset
- 72. ‘next’ はresetできないので、この場合は現在の ‘next’ の上 にそのトピックの新しい先端をマージします…
- 73. こんな感じです merge
- 74. そして ‘pu’ を新しい ‘next’ の上に再構築します reset and merge
- 75. トピックDの新しいブランチヘッドは、必要があればまず ‘pu’ にマージすることもできるという点に注意してください。(例え ば ‘next’ にマージするにはインパクトが大きい変更だったり とか) まず ‘pu’ にマージ (+ push and test) よさそうなら次に ‘next’ にマージし ‘pu’ を再構成。 これで前ページのコミットグ ラフと同一です
- 77. ‘pu’ にあるトピックEが完全に壊れていることがわかりまし た。Eの開発者はすぐには対応できません。こんなときは、単 に壊れているブランチを無視して ‘pu’ を再構成します。 Broken
- 83. ブランチ全体をrevertすべきです (revert -m 1 <merge commit>) revert revert commit reverted merge
- 84. もちろん ‘pu’ を再構築して ‘next’ 共々pushします reset and merge
- 87. ‘pu’ を再構築して ‘next’ と ‘pu’ をpushします reset and merge
- 88. 繰り返しますが、 ‘next’ は ‘pu’ほど簡単にはresetするべきでな いことに注意してください。‘next’ 上で何かをやり直したいのであ れば、かわりにrevertするか再マージします。
- 90. また、 機能リリース後に ‘next’ をresetする機会があるので、後 で見てみます。今は2回目のリリースに向けて開発を続けましょ う
- 91. ‘next’ にマージされたトピックが安定している / 良い設計だとわ かったら、そのトピックを ‘master’ にマージします。 Good enough to be merged into ‘master’
- 92. ‘next’ にマージされたトピックが安定している / 良い設計だとわ かったら、そのトピックを ‘master’ にマージします。 Good enough to be merged into ‘master’
- 93. 次のリリースに十分な機能が ‘master’ にマージされるまで ‘pu’ - > ‘next’ -> ‘master’ のサイクルを反復します new topic
- 94. 次のリリースに十分な機能が ‘master’ にマージされるまで ‘pu’ - > ‘next’ -> ‘master’ のサイクルを反復します merge
- 95. 次のリリースに十分な機能が ‘master’ にマージされるまで ‘pu’ - > ‘next’ -> ‘master’ のサイクルを反復します good enough for master
- 96. 次のリリースに十分な機能が ‘master’ にマージされるまで ‘pu’ - > ‘next’ -> ‘master’ のサイクルを反復します merge
- 97. 次のリリースに十分な機能が ‘master’ にマージされるまで ‘pu’ - > ‘next’ -> ‘master’ のサイクルを反復します good enough for next
- 98. 次のリリースに十分な機能が ‘master’ にマージされるまで ‘pu’ - > ‘next’ -> ‘master’ のサイクルを反復します merge reset and merge
- 99. 次のリリースに十分な機能が ‘master’ にマージされるまで ‘pu’ - > ‘next’ -> ‘master’ のサイクルを反復します new topic
- 100. 次のリリースに十分な機能が ‘master’ にマージされるまで ‘pu’ - > ‘next’ -> ‘master’ のサイクルを反復します merge
- 101. 次のリリースに十分な機能が ‘master’ にマージされるまで ‘pu’ - > ‘next’ -> ‘master’ のサイクルを反復します good enough for next
- 102. 次のリリースに十分な機能が ‘master’ にマージされるまで ‘pu’ - > ‘next’ -> ‘master’ のサイクルを反復します merge reset and merge
- 103. この ‘pu’ -> ‘next’ -> ‘master’ 順のマージ、つまり機能の下流へ の伝搬は ‘graduate’ と呼ばれています。(訳すと「送り出し」で しょうか)
- 104. 残念ながら ‘master’ にマージされたトピックでさえ、バグが見つ かることがあります。 これはそのトピック上で直すのでしょうか？ いいえ、 a bug found
- 105. 一旦 ‘master’ にトピックがマージされたら、それはもう ‘master’ の一部だと考えます。したがってそのバグの修正ブランチを ‘master’ の上に作ります。 fix-branch for the bug
- 106. 修正ブランチはまず(必要に応じて ‘pu’ と) ‘next’ にマージし… merge reset and merge
- 110. でもその後 ‘master’ を ‘next’ にマージして、修正が ‘next’ にも 含まれるようにするのを忘れないでください。(‘master’ にマージ されたトピックは ‘next’ にもマージされているので、きっとそのバ グもあるはずだからです) merge reset and merge
- 113. つまりバグ修正のためだけの統合ブランチが必要です。 ‘maint’はそのようなブランチです。これは最新の機能リリース、 つまりv1.0.0から分岐させます maint create branch
- 115. もし‘master’ から‘maint’用修正ブランチを分岐させると... *悪い例* fix-branch for the bug *WRONG*
- 119. ‘maint’用の修正ブランチも、基本的にはいつものとおり、まず ‘next’ (または ‘pu’)にマージします。‘maint’は決してresetできな いからです。 merge reset and merge
- 121. しかしながら...
- 134. コードをフリーズするには、単に‘master’への機能トピックのマー ジをやめ、‘maint’を含む修正トピックのみマージするようにすれ ば良いです。 フリーズ中は修正ブランチ のみマージする
- 154. タグを打つ前に、‘maint’が完全に‘master’にマージされているこ とを確認します。これには‘master’でgit merge maintすれ ばOKです。 もしマージしなければ、新しいリリースからいくつか の修正が漏れることになります。 この場合はすでにmaster にマージされています。
- 165. これには‘maint’上でgit merge --ff-only masterを実 行します。 もしこれが失敗するようなら、‘maint’には‘master’に ないコミットがあるということですから、前回のリリースは修正が いくつか入っていないことになります。 Fast-Foward to master
- 169. まとめ (1/2) ● puのような使い捨て統合ブランチを使う ● まず使い捨て統合ブランチ(TA)にマージ ● masterにマージする前にTAでテストする ● nextのような、TAとそうでないブランチのハイブ リッドな統合ブランチの使用も可能 ● nextはアナウンスしてresetして良い ● masterとmaintはresetできない
- 170. まとめ (2/2) ● puまたはnext上で作業してはならない ● topicは最終的にマージされる統合ブランチのう ち、もっとも古いものから分岐させる ● 統合ブランチを上流側へマージする ● 機能リリースはmasterにタグをつけて実施 ● 修正リリースはmaintにタグをつけて実施
- 171. 参考文献 ● gitworkflows(7) ● Gitソースツリーの Documentation/SubmittingPatches ● git.gitの‘todo’ブランチにあるMaintNote ● 濱野氏のブログ the Git Blame blog
- 172. Q and A
- 174. Q: {‘pu’, ‘next’, ‘maint’}を使わないといけない？ A: その必要はありません 必要な場合に作ればOKです。しかし、最低でも使い捨てブランチ は使うことをオススメします。使い捨てブランチはローカルリポジト リに閉じても良いです (つまりテストに通るのを確認してから masterをpushする) ‘master’と’pu’だけ使うプロジェクトや、’master’, ‘master-pu’, ‘maint’, ‘maint-pu’ の4つを使っているプロジェクトを見たことがあ ります。
- 176. Q: 同じブランチを何度もマージしないといけない？ A: そうです。 同じコンフリクトの解消に飽き飽きしたら、git-rerere(1)を有効にし ましょう。’rerere’は Reuse Recorded Resolution の略で、一度 解消したことのあるコンフリクトを解消するのを支援してくれます。
- 177. Q: gitworkflowsでGitHubのプルリクを使える？ A: もちろん使えます。 git.gitではGitHubプルリクエストは単に無視されますが、これは、 そうすることがプロジェクトのポリシーであるというだけのことで す。 GitHubユーザにはオンラインマニュアルgitworkflows(7)に書いて ある“Merge 奥辞谤办蹿濒辞飞”が适切でしょう。
- 178. Thank you