加载中

我们如何使用 Git 和 GitHub

Forking（派生）

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

Branching（分支）

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

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

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

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

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

Commits and Merging（提交与合并）

  • 在处理分支时，可以随意进行任意数量的提交。
  • 提交 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 YOUR_ELASTIC_EMAIL@elastic.co

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

    git commit -m 'commit using @elastic.co' --allow-empty

  5. 将新提交推送到您的 PR，状态现在应该是绿色的

Rebasing and fixing merge conflicts（变基和解决合并冲突）

变基可能很棘手，解决合并冲突甚至更棘手，因为它涉及强制推送。所有这些都因以下事实而加剧：尝试远程推送变基分支将被 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 中已完成工作的方式合并。

解决所有合并冲突后，使用 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.

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

Creating a pull request（创建拉取请求）

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

© . All rights reserved.