維護者筆記¶
這是給那些對上游具有讀寫權限的人使用的。建議將上游遠端命名為提醒您它是讀寫的
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
以下假設您位於您自己或其他人的分支上，其中包含您想要推送到上游的變更。
變基 (Rebasing)¶
如果只有少數幾個提交，您可以進行變基以保持線性歷史記錄
git fetch upstream-rw
git rebase upstream-rw/main
但是，變基不會自動關閉提取請求（如果有的話），因此請不要忘記這樣做。
合併 (Merging)¶
如果有一長串相關的提交，那麼您會想要合併。 您可能會問自己，合併：快速轉送或不快速轉送？ 請參閱下文以取得有關此選擇的更多資訊。一旦決定，您可以執行
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
揀選 (Cherry-Picking)¶
假設您對另一個分支中的某個提交感興趣，但現在想保留其他提交。 您可以使用揀選來執行此操作。使用 git log –oneline 找到您要揀選的提交。 假設您要從 shiny-new-feature 分支中揀選提交 dd9ff35。您想要將此提交應用於 main。 您只需執行：
git checkout main
git cherry-pick dd9ff35
就是這樣。 此提交現在已作為 main 中的新提交應用。
合併：快速轉送或不快速轉送¶
預設情況下，git merge 是快速轉送合併。 這是什麼意思，以及何時要避免這樣做？
(來源 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