メンテナンススタッフ向けのワークフロー

このページはメンテナンスのために用意されています — 私たちの中で自分や他の人たちの変更を上流リポジトリに統合する人たち。

保守員としてあなたは完全に把握しています どのようにコード貢献をするか それがそうです。

手動統合変更

まず、確認してください astropy 貯蔵庫です。中の説明 GitがどこでAstropy開発バージョンの変更を検索するかを教えてください 上流の買い戻しに対して読み出し専用アクセス権限を持つリモコンを追加する.保守員として、あなたは読み書きアクセス権限を持っています。

上流のリモコンに恐ろしい名前を持たせてください読み書きリモコンです

git remote add upstream-rw git@github.com:astropy/astropy.git
git fetch upstream-rw --tags

何か変更があったら主幹に入る必要があるとしましょう (upstream-rw/master ）。

あなたが現在位置しているノードを変更します。例えば、以下のように、誰かの変更を見ています。

git remote add someone git://github.com/someone/astropy.git
git fetch someone
git branch cool-feature --track someone/cool-feature
git checkout cool-feature

したがって、あなたはもう支店にいて、このような変更は上流に統合されるだろう。本節の残りの部分は、あなたがこの枝にいると仮定します。

いくつかの約束

いくつかの提出しかない場合は、基準を上流に再設定することを考慮してください：

# Fetch upstream changes
git fetch upstream-rw

# Rebase
git rebase upstream-rw/master

Rebaseを実行してプッシュする場合、GitHubが変更が統合されたことを検出できないので、GitHub要求を手動でオフにしなければならないことを覚えておいてください。

長い列に提出する.

一連のより長い関連提出がある場合は、統合を考慮してください。

git fetch upstream-rw
git merge --no-ff upstream-rw/master

統合はGitHubによって検出され、関連する任意の引き出し要求が自動的にオフにされなければならない。

注意してください --no-ff 上です。これは、これらの提出分岐が主幹から離れ、その後、主幹上で直接行われているように見えるのではなく、統合によって主履歴に再追加されるように、早送りではなく、gitに統合提出を迫る。

歴史的記録を見る

今、いずれの場合も、履歴が合理的かどうかをチェックし、正しい提出権限を持っているかどうかをチェックしなければなりません。

git log --oneline --graph
git log -p upstream-rw/master..

上の1行目は単に歴史をコンパクトに表示し，履歴図形をテキストで表示しているだけである.2行目は、バックボーンからアクセス可能な提出は含まれていない提出されたログを表示する (upstream-rw/master), and including those that can be reached from current HEAD (implied with the .. 最後に)。したがって，本幹に比べてこの枝特有の提出を示している.♪the -p オプションは，これらの提出の違いをパッチ形式で表示する.

中継にプッシュする

git push upstream-rw my-new-feature:master

これは my-new-feature このリポジトリに分岐して master 支店のある upstream-rw 貯蔵庫です。

マイルストーンとラベルを使います

本マニュアルは改編されました similar guidelines そしてIPythonです

  • 100%確認された問題および新しい機能は、マイルストーンの意味を持つべきです

  • 以下の条件のみが、問題をマイルストーンなしで終了させることができる。

    • 実際には問題ではない(ユーザエラーなど)

    • 既存の問題の写し

    • 代替実装を提供する新しいプル要求によって代替されるプル要求

  • 以下の場合にのみ、未解決の問題はマイルストーンが不足しなければならない。

    • もっと明確にする必要があります

    • どのマイルストーンに属しているのか議論する必要があります

  • 推論：問題がマイルストーンなしで終了した場合、これは、この問題が解決されないか、またはそれが真の問題ではないことを意味する。

  • 一般的に、次のような開放のマイルストーンがあるべきだ。

    • まだサポートされているバージョンの行の次のエラー修復バージョンは、例えば、0.4が開発されており、0.2.xおよび0.3.xが依然としてサポートされている場合、次の0.2.xおよび0.3.xのバージョンにマイルストーンがあるはずである。

    • 次のX.Yバージョン、すなわち次のサブバージョン；これは、一般に、MASTERにおけるすべての開発ターゲットの次のバージョンである。

    • 次のX.Yバージョン+1；例えば、0.3が次のバージョンである場合、重要であるが、次のバージョンで解決されない問題に対しても、0.4のマイルストーンがあるべきであることが知られている。

    • 未来-これはある時点で注目される必要があるが、今のところ直ちに解決策が見られないすべての問題に適用される。

  • エラー修復バージョンのマイルストーンは、次のサブバージョンでは修復されない問題を延期するためにのみ使用されるべきであり、またはメインラインの以前のバージョンにもはや適用されない問題のために使用されるべきである。

  • どのマイルストーンを使用して問題を解決するかが決定されない場合、次のサブバージョンを使用することができるが、リリース前により詳細な検討を経た後、それは常に移動可能である。

  • 特定のバージョンに関連するアクティビティのマイルストーン(例えば、V 0.3.0)は、バージョンラベルがリリースされた実際のタスクを表す少なくとも1つの問題を含むべきである(これはまた、GitHubの悩みを解決する、すなわち、オープン問題のマイルストーンが自動的にオフになることもない)。

  • メインラインで修復する必要がありますが、サポートされている安定バージョン行にも適用されることを確認する問題は、1つまたは複数としてマークされるべきである 'backport-*' 問題のあるv 0.X.Y枝ごとのラベル.

    • 場合によっては、エラー修復をより古い発行に移植するための簡単な統合に加えて、追加の作業が必要となる可能性があり、そのような追加の作業が必要である場合、適切なv 0.X.Yマイルストーンで“Backport#nnn to v 0.X.Y”問題を開くことは悪い考えではない。

ログの更新と保守変更

Astropy“ChangeLog”はファイルに保存されている CHANGES.rst リポジトリのルートディレクトリの下にあります。ファイル拡張子が示すように、これは再構築されたテキストファイルである。このファイルの目的は、技術的であるが、Astropyが各公開バージョン間でどのように変更されたかを示すユーザ(および開発者)の概要を示すことである。我々の考えは，完全なGITログを読もうとするよりも急所を突いており，理解しやすいということである.これは、ユーザが機能を追加する際にChangeLogを読むことによって容易に見つけることができるように、バージョン間に追加されたすべての新しい機能を示している。同様に、すべての変更(およびどのように変更されるか)または削除された機能またはAPIを示す。それはまたすべての間違った修復をリストしている。私たちは付属パッケージが似たような変更ログを維持することを奨励する。

ChangeLogに追加する

ChangeLogに新しいエントリを追加するには2つの方法があり，各方法にはそれぞれ長所と短所がある.この2つの具体的な方法を説明する前に all ChangeLogへのコンテンツ追加はまず“master”ノードで行うべきである.これは、Astropyの各バージョンがChangeLogのコピーを含み、Astropyの各以前のバージョンにおけるすべての変更をリストすべきであるからである。例えば、Astropy v 0.3.0が発行された場合、ChangeLogは、そのバージョンの新しい変更に加えて、それまでに発行された各v 0.2.xバージョン(および以前のバージョン)のすべての変更を含むべきである。

新しい機能またはエラー修復を含むChangeLogエントリの2つの方法は、

  • ChangeLog更新を変更と同じ引き出し要求に含める.すなわち，この変更はPull要求で行われており，正確なChangeLog更新を含むことができると仮定する.

    賛成：ChangeLogに追加することは、任意の他の文書更新のように、ソフトウェアの任意の原子変更の一部であるべきです。それは残りの変更と一緒にマスターに引き込むことができる。

    欠点：多くのPull要求にChangeLog更新も含まれていれば，それらはすぐに衝突する可能性があり，基本アドレスを再設定する必要がある.唯一の衝突がChangeLogであれば、これは難しくないが、それは依然として面倒かもしれないが、特に新しい貢献者のために。

  • 変更をメインファイルにマージした後(引き込み要求の有無にかかわらず)，ChangeLogに追加する.

    賛成：合併衝突問題は大きく回避された。

    欠点：“原子地”が合併提出に含まれていないことは，追跡の後方移植をより困難にする.新たな貢献者が2つ目のPull要求を出すか，メインライブラリにアクセス権限を持つ開発者に提出させる必要がある.

第一の方法は、特に核心貢献者のためにもっと望ましいかもしれない。しかし，後者の方法も受け入れられる.

ChangeLogフォーマット

現在，ChangeLogコンテンツの適切なフォーマットはやや緩い(ただし，ChangeLogをめぐってより多くのツールを開発しようとすると，より厳しくなる可能性がある).フォーマットは、主に以前のバージョンを見ることによって推定することができる。各バージョンには自分のタイトルがあります(使用) - タイトルタグ)およびバージョンとリリース日。まだ開発中のバージョンは (unreleased) まだ日付が発表されていないからです。

通常は最大3つの副題(使用)がある ^ タグ)：“新しい特性”，“API変更”，“エラー修復”，および“その他の変更および追加”.後者は基本的に様々な変化の総称であり，適切に見えるにもかかわらず，追加の副見出しを補完しない理由はない.

各サブタイトルでは、変更は、一般に、それらが属するサブパケットに従ってグループ化される。複数のサブパケットに適用されるか、またはサポートモジュールの変更にのみ適用される logging あるいは…。 utils “Misc”グループに格納することができる.

ChangeLogエントリの実際のテキストは通常1~3文しかありません-閲覧しやすいはずですほとんどのエントリは、四角括弧の発行/引き込み要求番号で終了します。

単一のChangeLogエントリはまた、複数の小さな変更を参照することができる。例えば：

- Minor documentation fixes and restructuring.
  [#935, #967, #978, #1004, #1028, #1047]

これに加えて、ChangeLogを更新する最適な提案は、以前のバージョンの既存エントリを見てフォーマットをコピーすることである。