« 贡献 测试 »
Elastic 文档 ›Kibana 指南 [8.14] ›开发者指南 ›贡献

我们如何使用 Git 和 GitHub

编辑

我们如何使用 Git 和 GitHub编辑

分支编辑

我们遵循 GitHub 分支模型 来协作开发 Kibana 代码。此模型假设您有一个名为 upstream 的远程仓库，它指向官方的 Kibana 仓库，我们将在后面的代码片段中引用它。

分支策略编辑

在 Elastic，所有产品（包括 Kibana）都使用相同的版本号同时发布。大多数项目都采用以下分支策略

  • main 指向下一个次要版本。
  • <major>.<minor> 是先前发布的次要版本，包括补丁版本。

例如，假设主分支当前是尚未发布的 8.1.0。一旦 8.1.0 达到功能冻结，它将被分支到 8.1，并且主分支将被更新以反映 8.2.0。8.1.0 的发布和后续补丁版本将从 8.1 分支中切出。您可以随时通过检查 Kibana 源代码中 package.json 文件中的版本属性来验证分支的当前版本。

拉取请求被合并到 main 分支，然后在安全且适当的时候进行反向移植。

  • 只有在至少经过 18 个月的弃用期并且重大更改已获批准的情况下，才能对 main 进行重大更改。显示当前使用情况的遥测数据对于获得批准至关重要。
  • 不应将功能反向移植到 <major>.<minor> 分支。
  • 如果更改安全且适当，则可以将错误修复反向移植到 <major>.<minor> 分支。安全性是您根据错误的严重程度、测试覆盖率、对更改的信心等因素做出的判断。您的理由应包含在拉取请求描述中。
  • 文档更改可以随时反向移植到任何分支。

提交和合并编辑

  • 在分支上工作时，您可以随意进行任意数量的提交。
  • 提交 PR 以供审核时，请执行交互式变基以呈现逻辑历史记录，以便审阅者轻松跟踪。
  • 请在提交消息中包含有关更改的有用信息，例如 API 更改、用户体验更改、已修复的错误，以及对进行更改原因的说明。
  • 通过将目标分支变基到您的功能分支上并强制推送来解决合并冲突（请参阅下面的说明）。
  • 合并时，我们会将您的提交压缩为一次提交。
使用您的 @elastic.co 电子邮件地址提交编辑

为了协助开发者工具，我们要求所有 Elastic 工程师在提交到 Kibana 仓库时使用他们的 @elastic.co 电子邮件地址。我们实施了一项 CI 检查，以验证由 @elastic 组织成员打开的任何 PR 至少有一次提交归属于 @elastic.co 电子邮件地址。如果您的 PR 由于此检查而失败，您可以按照以下步骤修复您的 PR

  1. 确保您没有任何已暂存的更改
  2. 检出您 PR 的分支

  3. 更新当前仓库的 git 配置，以使用您的 @elastic.co 电子邮件地址进行提交

    git config user.email [email protected]

  4. 使用新的电子邮件地址创建提交

    git commit -m 'commit using @elastic.co' --allow-empty
  5. 将新提交推送到您的 PR，状态现在应该是绿色的
变基和解决合并冲突编辑

变基可能很棘手，解决合并冲突可能更棘手，因为它涉及强制推送。尝试远程推送变基后的分支会被 git 拒绝，这更加剧了这种情况，并且系统会提示您执行 pull 操作，而这根本不是您应该做的（这会真正弄乱您分支的历史记录）。

以下是将 master 变基到您的分支上以及如何在出现合并冲突时解决它们的方法。

首先，确保 master 是最新的。

git checkout master
git fetch upstream
git rebase upstream/master

然后，检出您的分支并将 master 变基到其上，这会将 master 上的所有新提交应用于您的分支，然后在此之后应用您分支的所有新提交。

git checkout name-of-your-branch
git rebase master

您要确保没有合并冲突。如果有合并冲突，git 将暂停变基，并允许您在继续之前解决冲突。

您可以使用 git status 查看哪些文件包含冲突。它们将是未暂存提交的文件。打开这些文件，查找 git 标记冲突的位置。解决冲突，以便以不会破坏 master 中已完成的工作的方式合并您要对代码进行的更改。如果您需要更好地了解代码是如何冲突的以及如何最好地解决它，请参阅 GitHub 上 master 的提交历史记录。

解决所有合并冲突后，使用 git add -A 将它们暂存以进行提交，然后使用 git rebase --continue 告诉 git 继续变基。

变基完成后，您将需要强制推送您的分支，因为历史记录现在与远程仓库中的历史记录完全不同。这可能很危险，因为它会完全覆盖您在远程仓库中的内容，因此您需要确保在解决合并冲突时没有丢失任何工作。（如果没有合并冲突，那么您可以强制推送，而不必担心这一点。）

git push origin name-of-your-branch --force

这会用您本地拥有的内容覆盖远程分支。您已完成！

请注意，您不应运行 git pull，例如，在遇到如下所示的推送拒绝时

! [rejected] name-of-your-branch -> name-of-your-branch (non-fast-forward)
error: failed to push some refs to 'https://github.com/YourGitHubHandle/kibana.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

假设您已成功变基并且对代码感到满意，则应改为强制推送。

创建拉取请求编辑

有关将代码更改合并到 Kibana 中的后续步骤，请参阅 提交拉取请求。

« 贡献 测试 »