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

我们如何使用 Git 和 GitHub

编辑

我们如何使用 Git 和 GitHub

编辑

Fork

编辑

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

分支

编辑

在 Elastic，所有堆栈中的产品，包括 Kibana，都以相同的版本号同时发布。大多数这些项目都有以下分支策略：

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

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

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

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

提交和合并

编辑
  • 在处理分支时，您可以随意进行任意多次提交。
  • 在提交 PR 进行审查时，请执行交互式变基，以呈现一个易于审查人员遵循的逻辑历史记录。
  • 请使用您的提交消息来包含有关您更改的有用信息，例如对 API 的更改、UX 更改、修复的错误，以及对您进行更改的原因的解释。
  • 通过将目标分支变基到您的功能分支上，并强制推送（请参阅下面的说明）来解决合并冲突。
  • 合并时，我们将把您的提交合并为一个单独的提交。
使用您的 @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 的后续步骤，请参阅 提交拉取请求。

« 贡献 测试 »