Git 和 GitHub 工作流程#

贡献 sktime 仓库的首选工作流程是在 GitHub 上 fork 主仓库，然后克隆并在新分支上进行开发。

工作流程主要包括两个部分：

首次设置：创建 fork 并克隆仓库：本节将帮助您设置您自己的 sktime fork 副本

仓库在 GitHub 上以及 fork 的仓库在您机器上的本地副本。这只需要在您开始贡献 sktime 时做一次。

每次工作流程：开发新功能：这是开发新功能的过程，例如，bug 修复或新的评估器。

每次您想贡献一个新功能时都需要这样做。

注意

也可以使用基于 GUI 的解决方案来执行以下工作流程步骤。例如，管理分支和提交，您可以使用

GitHub Desktop。这是官方的 GitHub GUI 客户端，也集成了您的浏览器。
Visual Studio Code，配备合适的 git 扩展。
pycharm (本地安装)。

这些解决方案在底层执行相同的步骤，但提供了图形界面。即使您使用 GUI，我们仍然建议理解其底层命令，并至少在终端中尝试一次。

创建 fork 并克隆仓库 - 首次设置#

通过点击页面右上角的“Fork”按钮来 fork 项目仓库。这会在您的 GitHub 用户帐户下创建一个代码副本。有关如何 fork 仓库的更多详细信息，请参阅此指南。
将您的 sktime 仓库 fork 从您的 GitHub 帐户克隆到您的本地磁盘
```
git clone git@github.com:<username>/sktime.git
cd sktime
```
其中 <username> 是您的 GitHub 用户名。

配置并链接您的 fork 的远程仓库到上游仓库

git remote -v
git remote add upstream https://github.com/sktime/sktime.git

验证您为您的 fork 指定的新上游仓库

git remote -v
> origin    https://github.com/<username>/sktime.git (fetch)
> origin    https://github.com/<username>/sktime.git (push)
> upstream  https://github.com/sktime/sktime.git (fetch)
> upstream  https://github.com/sktime/sktime.git (push)

注意

步骤 1 每个 GitHub 帐户只需要执行一次，并且只有在使用第二个 GitHub 帐户或有意重置 fork 时才需要重复。

步骤 2-4 每台本地机器只需要执行一次，并且只有在您在新机器上工作或重置本地设置（例如，重装操作系统后）时才需要重复。

开发新功能 - 每次新功能重复#

将您的 fork 的 main 分支与上游仓库同步

git fetch upstream
git checkout main
git merge upstream/main

从 main 分支创建一个新的 feature 分支，用于存放您的更改，并使用描述性的名称，将 <feature-branch> 替换为该名称
```
git checkout main
git checkout -b <feature-branch>
```
始终使用 feature 分支。永远不要在 main 分支上工作是好的实践！将 feature 分支命名为您的贡献名称。

注意

我们建议永远不要在您的 fork 的 main 分支中进行更改，而应始终为特定任务使用单独的专用分支。

在您的 feature 分支上开发您的贡献。使用 git add 添加更改的文件，然后使用 git commit 提交文件以在 Git 中记录您的更改
```
git add <modified_files>
git commit
```
完成后，使用以下命令将更改推送到您的 GitHub 帐户：
```
git push --set-upstream origin my-feature-branch
```
按照这些说明从您的 fork 创建一个 pull request。如果您的工作仍在进行中，请打开一个草稿 pull request。

注意

我们建议尽早打开 pull request，以便其他贡献者了解您的工作并能尽早给您反馈。

要添加更多更改，只需重复步骤 3 - 4。如果您将新更改推送到同一分支，pull request 会自动更新。

注意

如果上述任何步骤对您来说像是魔法，请查阅 Git 文档。如果您遇到困难，请在 Discord 上与我们聊天，或加入 Discord 上的社区会议。

在您创建 pull request 到准备合并到 main 分支之间，sktime 仓库的 main 分支可能已被其他贡献者用新更改更新，并可能导致合并冲突。为了使您的 feature 分支与 sktime 仓库的 main 分支保持最新，您可以执行以下操作：
```
git fetch upstream
git checkout main
git merge upstream/main
git checkout <feature-branch>
git merge main
```
这将首先使用 sktime 仓库 main 分支的最新更改更新您 fork 的 main 分支，然后用这些更改更新您的 feature 分支。如果存在任何合并冲突，您将需要手动解决它们。

注意

我们强烈、明确地建议在贡献 sktime 时，永远不要使用 rebase 来更新您的 feature 分支。rebase 会重写历史记录，可能导致非常难以恢复的状态。请务必使用 ``merge`` 来更新您的 feature 分支。 我们会将所有 pull requests 合并为一个提交到 main 上，因此您的 feature 分支的历史记录并不重要。

管理分支 - 高级指南#

本节提供了一些关于管理多个分支的高级技巧。

并行处理多个功能#

如果您正在并行处理没有相互依赖关系的不同任务：对于每个任务，从您的 fork 的 main 分支创建一个新的 feature 分支，遵循上面“贡献新功能 - 每次新功能重复”一节的说明。

我们强烈建议不要将同一分支用于多个任务，因为这会使分支的历史记录变得混乱，难以审阅，并大大增加 bug 和冲突的风险。

处理一系列相互依赖的任务#

对于更复杂的任务，通过将任务串联起来可能有助于限制复杂度。

例如，开发一个评估器，而此评估器首先需要合并一个 bug 修复。

在这种情况下，从前一个任务的分支创建一个新分支，并从那里继续开发。对于这种情况，请务必在 PR 描述中说明此 PR 依赖于之前的 PR。

此外，每当前一个分支发生更改时，请确保使用前一个分支的最新更改来更新依赖分支。

确保链中所有分支都是最新的通用工作流程如下。假设我们有分支 A、B、C 等，其中 A 依赖于 main，B 依赖于 A，C 依赖于 B，以此类推。

在任何分支发生任何更改后

从上游仓库更新您的 fork
将 main 合并到 A 中，并解决所有冲突
将 A 合并到 B 中，并解决所有冲突
将 B 合并到 C 中，并解决所有冲突
以此类推，直到链中的所有分支都已合并并解决

清理#

一旦您的 pull request 合并到 sktime 仓库的 main 分支中，您可以删除您的 feature 分支

git checkout main
git branch -D <feature-branch>

您也可以删除您 fork 上的远程分支

git push origin --delete <feature-branch>