Question

让我们说我大约一年前发布了我的软件版本，并在Git中以2.3的标记。

所以我不断添加功能并修复错误，在您知道之前，该软件现在的版本为3.0。但是现在我的软件版本2.3上有一个错误，需要修复的人还没准备好升级到3.0版。

就Git而言，在不改变Git仓库历史的情况下，管理将补丁应用到2.3并创建2.3.1软件的最佳方法是什么。

例如，我无法检出版本2.3，应用补丁然后将其标记为2.3.1并将其推高，因为这会创建一个新头。

开发人员通常如何管理支持其旧版本的软件？

修改

好的，所以我跟着@AnoE建议，现在我的工作流程如下修补以前的版本。欢迎提出建议。

float

我必须创建分支的原因是因为标签不会出现在我们的repo托管解决方案Kiln上。我不知道像Bitbucket或Github这样的其他提供商是否会显示没有分支关联的标签，或者这只是Git如何存储事物的副作用。当我运行git checkout v2.3.0 // Make code changes git add -A git commit -m "Fixed a bug in old app" // Do something to verify the changes work on a different environment git checkout -b v2_3_1 git tag -a v2.3.1 -m "Fixed small bug." git push origin v2_3_1 git push --tags时，标签会在本地显示，但通过网络用户界面无法看到。在我推开分支和标记之后，我刚刚删除了分支，它从Web UI中正确显示。

git tag -l

如果有人解释为何会发生这样的事情，我们将不胜感激。

Answer 1

检查版本2.3，应用补丁，标记它2.3.1正是你要做的。

创建一个新的头（而不是一个新的分支）不是一个问题，它是git的用途。请注意，“HEAD”在git中没有结构含义，它只是突出，因为它是在当前工作目录中处于活动状态的一个提交。 Git只关心提交，从结构上来说，你可以拥有任意数量的“顶级”提交。

所以：

git checkout 2.3    # gives you a "detached HEAD" 
git checkout -b dev_2.3    # a new branch, more for convenience
...modify files...
git add ... ; git commit ...
git tag 2.3.1
git branch -D dev_2.3     # get rid of it if you have a feeling that you won't be comming back soon

请记住，git中的分支和标记都没有什么特别之处。它们只是指向提交的粘滞便笺。以这种方式创建一个（可能是临时的）分支只是更方便，因为如果您正在执行的backport涉及多个快速提交，您可以轻松切换到它。

Answer 2

在Git中有两种处理版本的方法：标签和分支。

标签的一个参数是它们是不可变的（你只能删除/重新创建它们，而分支可以继续增长），但是，我倾向于使用分支来发布而不是标记下面：

如果您必须根据标记修补版本，那么您最终会得到某些标记版本，某些版本是分支。这可能会让人感到困惑，特别是如果你必须第二次修补。这一次，你将检查第一个补丁分支，所以如果你不得不为那些不是Git专家的人做补丁程序，那可能会很棘手。
通常，git工具（Gitlab，BitBucket等）都有一个页面，列出了分支，前面/后面的提交比较，使用分支作为参考。虽然可以对标签进行相同的操作，但它不像分支那样简单，因为您必须手动选择每个标签。当您希望确保在最新版本上存在旧版本上的补丁
修补不需要（需要）创建新分支。通常，补丁不会导致向后兼容性问题，因此您可能只是向分支release_2.3添加提交（并且只是将pom从2.3.0更新到2.3.1）而不是仅创建新分支对于补丁，无论如何都要使父分支无用（除非某些客户端不需要补丁！）

有人可能会争辩说，标签允许避免创建分支并使用不再使用的释放分支“污染”存储库，但这是一个小的缺点，考虑到“污染”将来自补丁，我们都知道，可以和发行版一样多：）

编辑：您可以完全避免使用分支并使用100％标签，但是，如果您必须修补旧版本，则必须重新编写和重写历史记录，这是我不推荐的内容

如何在源代码管理中为旧标记创建补丁？

2 个答案: