メンテナーノート¶

これは、アップストリームへの読み取り/書き込みアクセス権を持つユーザー向けです。アップストリームリモートには、読み取り/書き込み可能であることを示す名前を付けることをお勧めします。

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

Git ワークフロー¶

他のユーザーからの変更の取得¶

他のユーザーからの変更をプッシュする必要がある場合は、次の操作でリポジトリにリンクできます。

git remote add contrib-name git://github.com/contrib-name/statsmodels.git
get fetch contrib-name
git branch shiny-new-feature --track contrib-name/shiny-new-feature
git checkout shiny-new-feature

以下の残りの部分は、アップストリームにプッシュする変更を含む、自分または他のユーザーのブランチにいることを前提としています。

リベース¶

コミットが数個しかない場合は、リベースして線形履歴を維持できます。

git fetch upstream-rw
git rebase upstream-rw/main

ただし、プルリクエストがある場合、リベースしても自動的に閉じられないため、忘れずに閉じてください。

マージ¶

一連の関連するコミットが長い場合は、マージする必要があります。「マージ: ファーストフォワードするかしないか」と自問自答するかもしれません。この選択肢の詳細については、以下を参照してください。決定したら、次のことができます。

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

マージすると、GitHubのプルリクエストが自動的に閉じられます。

履歴の確認¶

これは非常に重要です。繰り返しますが、リポジトリにプッシュする前に、すべての修正をローカルで行う必要があります。

git log --oneline --graph

これは、現在のブランチの履歴をコンパクトな方法で表示します。この

git log -p upstream-rw/main..

upstream-rw/main から到達できるコミットを除外したコミットログと、現在の HEAD から到達できるコミットログを表示します。つまり、このブランチに固有の変更と upstream-rw/main との差分です。ログでドットを使用する方法、および差分とドットを使用する方法の詳細については、Pydagogueを参照してください。

機能ブランチのプッシュ¶

すべての変更は問題ありませんか？マージまたはリベース後に、機能ブランチをプッシュできます。

git push upstream-rw shiny-new-feature:main

チェリーピック¶

別のブランチのコミットに興味があるが、他のコミットは今のところ残しておきたいとします。これは、チェリーピックで実行できます。チェリーピックするコミットを見つけるには、`git log --oneline`を使用します。`shiny-new-feature`ブランチからコミット`dd9ff35`が必要だとします。このコミットをmainに適用します。単純に次のようにします。

git checkout main
git cherry-pick dd9ff35

以上です。このコミットは、mainの新しいコミットとして適用されます。

マージ: ファーストフォワードするかしないか¶

デフォルトでは、`git merge`はファーストフォワードマージです。これはどういう意味で、いつこれを避けたいのでしょうか？

git merge diagram — (出典 nvie.com, 投稿 “成功するGitブランチモデル”)¶

ファーストフォワードマージでは、マージコミットは作成されません。これは、機能ブランチの存在が履歴に失われることを意味します。ファーストフォワードは、ブランチが安価であり、したがって*通常*は短命であるため、基本的にGitのデフォルトです。一方、長寿命の機能ブランチがある場合、または機能ブランチで反復的なワークフローに従っている場合（つまり、mainにマージしてから機能ブランチに戻ってコミットを追加する場合）、機能ブランチのすべての中間コミットではなく、マージのみをmainブランチに含める方が理にかなっているため、次を使用する必要があります。

git merge --no-ff

プルリクエストの処理¶

fetchおよびmergeを使用してプルリクエストを適用できます。メインリポジトリのローカルコピーで

git checkout main
git remote add contrib-name git://github.com/contrib-name/statsmodels.git
git fetch contrib-name
git merge contrib-name/shiny-new-feature

マージが正常に適用され、履歴が適切であることを確認します。マージメッセージを編集します。ブランチで行われたことの簡単な説明と「Closes gh-XXX」という文字列を追加します。これにより、プルリクエストが自動的に閉じられ、チケットとクローズコミットがリンクされます。課題を自動的にクローズするには、次のいずれかを使用できます。

gh-XXX
GH-XXX
#XXX

コミットメッセージ内。次を実行する前に、すべての問題をローカルで解決する必要があります。

git push origin main

リリース¶

mainをチェックアウト
```
git checkout statsmodels/main
```
次のコマンドで作業ツリーをクリーンアップします。
```
git clean -xdf
```
ただし、最初にドライランを実行することをお勧めします。
```
git clean -xdfn
```
**ローカルで**リリースにタグを付けます。たとえば、リリース候補の場合は
```
git tag -a v0.10.0rc1 -m "Version 0.10.0 Release Candidate 1" 7b2fb29
```
または単に
```
git tag -a v0.10.0rc1 -m "Version 0.10.0 Release Candidate 1"
```
mainの最後のコミットを使用します。
タグをチェックアウト
```
git checkout tags/v0.10.0rc1
```
ビルドがクリーンであることを確認するために、sdistをビルドします。
```
python -m build --sdist .
```
tar.gzファイルのビルドがタグと同じであることが重要です。**ダーティ**であってはなりません。
新しいマイナーリリース（major.minor.micro形式）の場合は、新しいメンテナンスブランチを開始します。たとえば、
```
git checkout -b maintenance/0.10.x
```
次のマイクロリリースを対象としたバグ修正とメンテナンスコミットは、通常どおりmainに対して行う必要がありますが、対象となるマイクロリリースのマイルストーンでタグ付けする必要があります。次に、通常どおりmainにマージします。バックポートの準備ができたら、`tools/backport_pr.py`ファイルを使用して、どのPRをバックポートする必要があるかを特定し、メンテナンスブランチに適用します。リリースのタグは、メンテナンスブランチで作成する必要があります。
ソースディストリビューションをPyPIにアップロードします。
```
twine upload dist/*
```
最初にテストにアップロードすることをお勧めします。
```
twine upload --repository-url https://test.pypi.org/legacy/ dist/*
```

mainブランチに戻り、空のコミットを追加します。

git checkout statsmodels/main
git commit --allow-empty -m "Start of 0.11.0 development"
git tag -a v0.11.0.dev0 -m "Start of 0.11.0 development"

すべてをstatsmodelsにプッシュします。
```
git push --tags
```
新しいブランチが作成された場合
```
git push --set-upstream origin maintenance/0.10.x
```
アナウンスを行い、ホイールビルダーのメンテナーに通知します。
利益？

メンテナンスブランチからのリリース¶

パッチがメンテナンスブランチにバックポートされたら、リリース手順は次のとおりです。

ブランチをチェックアウト
```
git checkout maintenance/0.10.x
```
徹底的にクリーンアップ
```
git clean -xdf
```
**ローカルで**リリースにタグを付けます。
```
git tag -a v0.10.0 -m "Version 0.10.0"
```
タグをチェックアウト
```
git checkout tags/v0.10.0
```
ビルドがクリーンであることを確認するために、sdistをビルドします。
```
python -m build --sdist .
```
tar.gzファイルのビルドがタグと同じであることが重要です。**ダーティ**であってはなりません。
ソースディストリビューションをPyPIまたはPyPIテストにアップロードします。
```
twine upload dist/*
```
または
```
twine upload --repository-url https://test.pypi.org/legacy/ dist/*
```
タグをstatsmodelsにプッシュします。
```
git push --tags
```
アナウンスを行い、ホイールビルダーのメンテナーに通知します。

コミットコメント¶

メイン共有リポジトリのメインブランチのコミットメッセージには、次のプレフィックスを付けます。

ENH: Feature implementation
BUG: Bug fix
STY: Coding style changes (indenting, braces, code cleanup)
DOC: Sphinx documentation, docstring, or comment changes
CMP: Compiled code issues, regenerating C code with Cython, etc.
REL: Release related commit
TST: Change to a test, adding a test. Only used if not directly related to a bug.
REF: Refactoring changes

最終更新日: 2024年10月3日