How to maintain Git

コミュニケーション (45%)

インテグレーション(統合) (50%)

自身の開発作業 (5%)

機能リリースには vX.Y.0 の番号が付けられており、機能、パフォーマンス、使いやすさなど、あらゆる分野でのバグ修正と機能拡張が、デグレ無しで含まれることを目的としています。

メンテナンス・リリースには vX.Y.Z という番号(但し (0 < Z))が付けられており、 対応する vX.Y.0 機能リリースと以前のメンテナンスリリース vX.Y.W (但し W<Z)の、 バグ修正のみが含まれていることを意味します。

「masterブランチは、 次の機能リリースの準備に使用されます。 言い換えると、 vX.Y.0 が最新の機能リリースである場合、 ある時点で「master」ブランチの先端が vX.(Y+1).0 としてタグ付けされます。

「maint」ブランチは、次のメンテナンスリリースの準備に使用されます。 機能リリース vX.Y.0 が作成された後、「maint」ブランチの先端がそのリリースに設定され、バグ修正がブランチに蓄積され、ある時点で、ブランチの先端に vX.Y.1, vX.Y.2, 等のタグが付けられます。

「next」ブランチは、 (1) 価値のある目標を持ち、 (2) 日常使用に適したかなり良好な状態にあり、 (3) ただしデグレがないことがまだ証明されていない変更(機能強化と修正の両方)を公開するために使用されます。 メーリングリストでの貢献者からのレビューが、 この判断を助けます。 トピックが「next」にマージされた後、 少なくとも7日間(7 calendar days)テストされ、 その後「master」にマージされます。

「seen」ブランチは、 「next」に設定された基準(上記参照)をまだ満たしていない他の提案された変更を公開するために使用されますが、 「seen」にすべての変更が含まれるという保証はありません。 レビュアーからの反応がないトピックは取り上げられない場合があります。

新しいトピックは、 明らかに正しくて緊急の場合を除き、 最初に「seen」にマージされます。 その場合、 直接「next」や「master」にマージされることがあります。

「seen」に取り込まれたトピックが、 3暦週にわたって活動がなく、 「next」に進むのに十分な明確な合意が得られていない場合、 そのトピックは「seen」から破棄されることがあります。 関係者は依然としてそのトピックを復活させることができます。 このガイドラインの目的において、 「活動がない」(inactive)とは、 誰もそのトピックについて議論していない、 かつ、 新しいバージョンのトピックが投稿されていない、 かつ、 レビュー・コメントへの返答がない状態を指します。

「master」と「maint」ブランチの先端は、人々がそれらの上に独自のカスタマイズを構築できるようにするために、巻き戻されることはありません。 新しい開発サイクルの早い段階で、「next」は「master」の先端に一度巻き戻されますが、それ以外の場合は、サイクルが終了するまで巻き戻されません。

通常、「master」には「maint」のすべてが含まれ、「next」には「master」のすべてが含まれます。 「seen」には「next」にマージされたすべてのトピックが含まれていますが、「master」で直接再構築されています。

「master」の先端は、タグ付けされたどのリリースよりも安定していることを意味しており、ユーザーはそれに従うことをお勧めします。

「next」ブランチは新しいアクションが行われる場所であり、新しいトピックが「master」にマージされる前にデグレとバグが見つかるように、ユーザーはそれをテストすることをお勧めします。

「next」にあるトピックに問題が見つかった場合、 そのトピックは「master」にマージされないようマークされます。 フォローアップのパッチはメーリングリストで議論され、 レビュー後にトピックに適用され、 その後トピックは(再度)「next」にマージされます。 「next」での通常のテストを経た後、 (修正された)トピック全体が 「master」にマージされます。

機能リリースのための1つのリリース・サイクルは、 8〜10週間続くことが予想されます。 最終リリースの前に、 約1週間間隔でいくつかの「リリース候補」(release candidate)がタグ付けされ、 最初のリリース候補がタグ付けされる約1週間前に「プレビュー」(preview)リリースがタグ付けされます。

プレビュー・リリースがタグ付けされた後、 十分にレビューされたトピックは、 通常の7暦日を「next」で過ごすことなく「master」にマージされることがあります。 これは、 最終リリース前にリリース候補でバグが見つかり修正されることが期待されるためです。

最初のリリース候補(release candidate)がタグ付けされた後、 貢献者は、 そのサイクル中に導入された新しいデグレ(regressions)を見つけて修正することに重点を置くよう強く推奨されます。 これは、 既存の古いバグや新機能の対応よりも優先されます。 トピックは「next」から「master」へのマージが停止し、 新しいトピックも「next」へのマージが停止します。 ただし、 サイクル中の新しいデグレに対する修正はこの限りではありません。

機能リリースが行われた直後、 「maint」の先端はリリースを指すように早送り(fast-forward)されます。 「next」に保持されていたトピックは「master」にマージされ、 新しい開発サイクルが開始されます。

メーリングリストを走査します。 レビューコメント、提案などで返信します。あちこちの議論にクチバシを突っ込みます(Kibitz)。 メーリングリストから潜在的に使用可能なパッチを収集します。 1つのトピックに関するパッチは1つのメールボックスに送信されます(私はGnusでメールを読み、\C-o と入力して、メッセージをmbox形式のファイルに 保存/追加 します)。

メーリングリストで提起された、 誰も解決に名乗り出ていない問題に対応するパッチを自身で書き、 提出します。 他の貢献者と同じようにパッチを送信し、 他の貢献者からのパッチと同様にそれらを取り込みます(上記参照)。

保存したメールボックスのパッチを確認します。タイプミス修正と、プログラムをキレイにするために提案されたログメッセージを編集し、リストから収集した対応を追加します。 パッチを編集して、ディスカッションからの「ええっと、これはこのようになっているはずです」な修正を組み込みます。

収集されたパッチを分類し、 master と maint の更新を処理します:

「What’s cooking」メッセージの最後の号を確認し、マージの準備ができているトピックを確認します(topic→master と topic→maint)。 このステップを支援するために、 Meta/cook -w スクリプト( Meta/ には「todo」ブランチのチェックアウトが含まれています)を使用します。

$ Meta/cook -w last-issue-of-whats-cooking.mbox

$ git checkout master    ;# or "git checkout maint"
$ echo ai/topic | Meta/Reintegrate -e ;# "git merge ai/topic"
$ git log -p ORIG_HEAD.. ;# final review
$ git diff ORIG_HEAD..   ;# final review
$ make test              ;# final review

$ Meta/cook -w last-issue-of-whats-cooking.mbox

$ git checkout master    ;# or "git checkout maint"
$ echo ai/topic | Meta/Reintegrate -e ;# "git merge ai/topic"
$ git log -p ORIG_HEAD.. ;# final review
$ git diff ORIG_HEAD..   ;# final review
$ make test              ;# final review

残りのパッチを処理します:

「What’s cooking」メッセージを更新して、既存のトピック、新しく追加されたトピック、および段階的なトピックの更新を確認します。

$ Meta/cook

$ Meta/cook -w

4つ(5つ)すべての統合ブランチをコンパイル、テスト、およびインストールします。 Meta/Dothem スクリプトは、このステップで役立つでしょう。

master ブランチが更新された場合は、ドキュメントをフォーマットします。 Meta/dodoc.sh スクリプトがこのステップに役立つでしょう。

統合ブランチを公共の場所にプッシュします。 Meta/pushall スクリプトがこのステップに役立つでしょう。

各トピックは個別にテストされ、他のトピックと一緒に、最初に「seen」、次に「jch」、それから「next」で調理(cooking)されます。 それが成熟するまで、その一部は「master」にマージされません。

すでに「next」にあるトピックは、「next」にある間に修正を取得できます。 このようなトピックには、「next」への多くのマージがあります（つまり、 git log --first-parent next は、同じトピックに対して多くの「nextへマージする ai/topic ブランチ」(Merge branch ai/topic to next)を表示します。

maint の明白でない修正は、 next で調理され、 master にマージされて、それがOKであることを確認してから、 maint にマージされます。

next が空になった場合(つまり、すべてのトピックが安定して master にマージされ、 git diff master next が空の場合)でも、next には、 master には決して存在しない大量のマージコミットがあります。

原則として、 git log --first-parent master..next はマージのみを表示するべきです(実際には、マージではない fixupコミット と revert があります)。

next にないトピックブランチの先端近くのコミットは、破棄または置換または書き換えのいいカモ(fair game)です。 next にすでにマージされているコミットはそうではありません。

next ブランチにあることは、そのトピックが次の機能リリースに含まれることを保証するものではありません。「master」ブランチにあるのは通常、次の機能リリースに含まれます。

「SQUASH???」修正の性質上、元の作成者が提案された変更に同意する場合は、次のラウンドで適切なパッチにそれらを押しつぶして(squash)もかまいません(提案された変更が十分に小さい場合、作成者は「Helped-by」を気にする必要はありません)。元の作者が提案に同意しない場合は、次のラウンドからそれらを削除することもできますが、作者は議論のどこかで理由を述べることが期待されます。