维护者笔记¶
这是为那些对上游具有读写访问权限的人准备的。建议将上游远程命名为能提醒你它是读写权限的名字：
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..
显示了从当前HEAD可以到达的提交日志，但不包括那些可以从upstream-rw/main到达的提交。也就是说，这些是相对于upstream-rw/main而言，这个分支独有的更改。有关在日志中使用点和使用Pydagogue进行更多信息，以及使用点与diff的信息。
推送你的特性分支¶
所有的更改看起来都好吗？你可以在合并或变基后推送你的特性分支，方法是：
git push upstream-rw shiny-new-feature:main
Cherry-Picking¶
假设你对另一个分支中的某个提交感兴趣，但暂时不想处理其他提交。你可以使用cherry-pick来实现这一点。使用git log –oneline来找到你想要cherry-pick的提交。假设你想要从shiny-new-feature分支中获取提交dd9ff35。你希望将这个提交应用到main分支。你只需执行以下操作：
git checkout main
git cherry-pick dd9ff35
就是这样。这个提交现在作为新的提交应用在主分支上。
合并：快进还是不快进¶
默认情况下，git merge 是一个快进合并。这是什么意思，以及何时需要避免这种情况？
（来源 nvie.com，文章 “一个成功的Git分支模型”）¶
快进合并不会创建合并提交。这意味着特性分支的存在在历史记录中丢失了。快进是Git的默认设置，基本上是因为分支成本低廉，因此通常是短期的。另一方面，如果你有一个长期存在的特性分支，或者在特性分支上遵循迭代工作流（即合并到主分支，然后回到特性分支并添加更多提交），那么只包含主分支中的合并，而不是特性分支的所有中间提交是有意义的，因此你应该使用：
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
发布¶
查看主分支：
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"使用主分支中的最后一次提交。
查看标签：
git checkout tags/v0.10.0rc1构建一个源代码分发包（sdist）以确保构建过程是干净的：
python -m build --sdist .重要的是，tar.gz文件上的构建与标签相同。它不能是脏的
如果在一个新的次要版本（major.minor.micro 格式）上开始一个新的维护分支，例如：
git checkout -b maintenance/0.10.x任何针对下一个小版本发布的错误修复和维护提交应像往常一样提交到主分支，但应标记为目标小版本的里程碑。然后像往常一样合并到主分支。当准备进行backports时，使用文件
tools/backport_pr.py来识别需要backports的PR，并将它们应用到维护分支。发布标签应在维护分支中创建。将源代码分发上传到 PyPI：
twine upload dist/*您可能想先上传到测试：
twine upload --repository-url https://test.pypi.org/legacy/ dist/*返回到主分支，并添加一个空提交：
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