How to maintain Git

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

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

自身の開発作業 (5%)

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

機能リリースのリリースサイクルは、8〜10週間と想定されています。

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

「master」ブランチは、次の機能リリースの準備に使用されます。 つまり、ある時点で、「master」ブランチの先端に vX.Y.0 のタグが付けられます。

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

「next」ブランチは、 (1)価値のある目標があり、 (2)日常の使用に適したかなり良好な状態であり、 (3)デグレがないことがまだ実証されていない変更(拡張と修正の両方)を公開するために使用されます。 新しい変更は、「master」にマージされる前に「next」でテストされます。

「seen」ブランチは、「next」に設定された基準をまだパスしていない他の提案された変更を公開するために使用されます。

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

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

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

「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

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

必要に応じて、maint を master にマージ:

$ git checkout master
$ git merge maint
$ make test

必要に応じて master を next にマージ:

$ git checkout next
$ git merge master
$ make test

「What’s cooking」の最後の号をもう一度レビューし、「next」にマージする準備ができているトピックがまだ良好な状態であるかどうかを確認します(たとえば、このシリーズのリストに新しい問題が提起されていませんか？)

jch ブランチを準備します。これは、 master と seen の間のどこかを表すために使用され、多くの場合、 next よりわずかに進んでいます。

$ Meta/Reintegrate master..seen >Meta/redo-jch.sh

$ Meta/Reintegrate master..jch >Meta/redo-jch.sh

「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」を気にする必要はありません)。元の作者が提案に同意しない場合は、次のラウンドからそれらを削除することもできますが、作者は議論のどこかで理由を述べることが期待されます。