修补先前版本的最佳实践是什么？

问题描述 投票：0回答：1

我正在开发一个项目，我们需要修补旧版本的库。我们将此包发布/发布到 GitHub 包注册表并（不用说）使用语义版本控制。这是我们第一次修补之前的版本，我很难确定最佳实践。

我遇到了this线程，除了几个主要问题外，它似乎大部分都有效。按照我上面链接的评论中的描述，以下是我在测试存储库中尝试过的步骤。在此示例中，假设 

main
分支上存在两个标签：
v1.0.0
和 
v2.0.0
，我需要使用修补程序 (
v1.0.0
) 来修补 
v1.1.0
版本。

  • 查看 v1.0.0 标签 (
    git checkout v1.0.0
    )
  • 创建一个修补程序分支 (
    git checkout -b hotfix-v1.1.0
    )
  • 将更改提交到修补程序分支 (
    git add .;git commit -m "Hotfix v1.1.0 changes"
    )
  • 在修补程序分支上创建修补程序标记 (
    git tag v1.1.0
    )
  • 切换到后备箱(
    git checkout main
    )
  • 将修补程序分支合并到主干中 (
    git merge hotfix-v1.1.0 --no-commit --strategy ours
    )
  • 提交合并（需要手动干预）(
    git commit
    )
  • 上推修补程序标签(
    git push --tags
    )
  • 删除本地修补程序分支(
    git branch -d hotfix-v1.1.0
    )

完成这些操作后，我检查了 GitHub 中的 origin，发现 

v1.1.0
修补程序 was 出现在最新提交中（好），并且 
main
的最新状态包含来自 
v2.0.0
的代码（好）。它还具有新的 
v1.1.0
标签（好）。

不过，有几个问题。首先，当我切换到 GitHub 中的修补程序标签 (

v1.1.0
) 时，出现以下警报： “此提交不属于此存储库上的任何分支，并且可能属于存储库之外的分支。”我不清楚这意味着什么，但这似乎不是一件好事。

更大的问题是我执行的提交、合并等忽略了我的

main
分支受到各种状态检查保护的事实。必须能够确保现有工作流程和检查包含在此修补程序流程中。

那么修补先前版本的最佳实践是什么？预先感谢您的任何意见。

git github version-control semantic-versioning
1个回答
0
投票

Gitflow 是一个工作流程，可以解决维护多个版本和修补程序的问题。

更大的问题是我执行的提交、合并等忽略了我的主分支受到各种状态检查保护的事实。必须能够确保现有工作流程和检查包含在此修补程序流程中。

问题是您在没有检查的情况下进行本地合并。

相反，使用 pull requests 进行合并。这允许在分支上运行检查并在合并到主干之前进行审查。

首先，当我切换到 GitHub 中的修补程序标签（v1.1.0）时，出现以下警报：“此提交不属于此存储库上的任何分支，并且可能属于存储库之外的分支。”我不清楚这意味着什么，但这似乎不是一件好事。

尽管
git log

和 Github 显示了什么，Git 历史

不是
线性的。这是一个图表。每个提交都与其之前的提交相关联。您可以使用 git log --graph --decorate 或 
Git Kraken
等工具查看此内容。 分支和标签只是指向提交的标签。

Git 告诉您的是无法从任何分支访问该提交。

让我们来看看这是如何发生的。

你是这样开始的：

local {v1.0.0} A - B - C - D - E - F [main] origin {v1.0.0} A - B - C - D - E - F [main] 

这里你的本地存储库和 Github 上的副本（你的“原始”远程）是相同的。

# checkout the v1.0.0 tag (git checkout v1.0.0) # create a hotfix branch (git checkout -b hotfix-v1.1.0) # commit changes to hotfix branch (git add .;git commit -m "Hotfix v1.1.0 changes") # create hotfix tag on hotfix branch (git tag v1.1.0) local {v1.0.0} A - B - C - D - E - F [main] \ G {v1.1.0} [hotfix-v1.1.0] origin {v1.0.0} A - B - C - D - E - F [main] 

仅提交连接到左侧的内容。 D 可以到达 C、B、A。C 不能到达 D。G 可以到达 C、B、A。

v1.0.0 标记指向提交 C。您的新 v1.1.0 标记和 hotfix-v1.1.0 都指向提交 G。主分支指向提交 F。

没有任何内容被推送到 Github。

# switch to trunk (git checkout main) # merge hotfix branch into trunk (git merge hotfix-v1.1.0 --no-commit --strategy ours) # commit merge (which requires manual intervention) (git commit) local {v1.0.0} A - B - C - D - E - F - M [main] \ / G ----------- {v1.1.0} [hotfix-v1.1.0] origin {v1.0.0} A - B - C - D - E - F [main] 

在本地，您的存储库现在看起来像这样。没关系，G属于主分支。

# push up hotfix tag (git push --tags) # delete local hotfix branch (git branch -d hotfix-v1.1.0) local {v1.0.0} A - B - C - D - E - F - M [main] \ / G ----------- {v1.1.0} origin {v1.0.0} A - B - C - D - E - F [main] \ G {v1.1.0} 

这就是出错的地方。 Git 推/拉非常高效，并且只会推送所需的量。由于您只推送标签，因此它只推送填充该标签的历史记录所需的提交。

因此就Github而言，任何分支都无法到达提交G。这不一定是坏事，提交仍然可以通过标签引用。

最新问题
© www.soinside.com 2019 - 2024. All rights reserved.