GIT 标签与 SVN 标签，以及 HotFix/Patches 管理

Question

快速提问，关于如何处理 SVN 和 GIT 中的热修复场景，如果我错了，请纠正我。

我有丰富的 SVN 经验，但我对 GIT 的经验较少，我主要想知道我在 GIT 中的翻译是否还可以（不是有史以来最好的！），但只要它能按预期工作。

SVN：

1. 我正在 TRUNK 上开发，客户要求我开发一个特殊功能，我决定在 BRANCH 上开发此功能

2. 这个功能还可以，我准备把它合并到TRUNK，同时已经更新了几个变化，但是客户要求我立即发布，他们一直在集中测试BRANCH，所以他们不想将功能合并到 TRUNK 中，但他们希望我直接释放 BRANCH。

3. 好的，够了，我标记了 BRANCH 并将其发布到 PRODUCTION，然后我将在接下来的几天里将该功能合并到 TRUNK 中，以便在我的 TRUNK 更改上线时进行下一个版本，此外，我决定删除 BRANCH 是因为我不再想要它了，因为该功能已经开发并且将被合并到 TRUNK 中，（并且我得到了 TAG 来保存基本代码）

4. 天啊！新功能有一个错误，我必须修复它，但我不再拥有 BRANCH，不用担心为此制作了“控制版本”，只需 BRANCH 刚刚发布的标签，开发您的修复程序然后发布再次，然后不要忘记将修复合并回 TRUNK。

GIT：

1. 我正在 MAIN_DEV 分支上开发，客户要求我开发一个特殊功能，我决定在 FEATURE_BRANCH 上开发此功能

2. 该功能还可以，我即将将其合并到 MAIN_DEV，同时已经更新了一些更改，但是客户喜欢我的新功能并要求我直接发布它并且他们一直将测试重点放在 FEATURE_BRANCH 上，因此他们不想将功能合并到 MAIN_DEV 分支中，但他们希望我直接发布 FEATURE_BRANCH

3. 好的，够了，我标记 FEATURE_BRANCH 并将其发布到生产环境中，然后我将在接下来的几天里将该功能合并到 MAIN_DEV 中，以便我的 MAIN_DEV 更改将上线的下一个版本，此外，我决定删除 feature_branch 因为我不再想要它了，因为我开发了这个功能..

4. 天啊！新功能有一个错误，我必须修复它，但我没有 FEATURE_BRANCH，我无法将它修复到 MAIN_BRANCH 原因包含我不想发布的新更新...不用担心“控制版本”是为此而制定的，只需将刚刚发布的标签分支，开发您的修复程序然后再次发布它，然后不要忘记将修复程序合并回 MAIN_DEV。

问题：

• 我的 SVN 流的 GIT 翻译正确吗？
• 如果我从我的 feature_branch 中删除我的标签，而不是我删除我的 feature_branch，因为该功能已经开发，我总是可以在刚刚发布的标签中剪切的新分支上开发 HotFix 或补丁，无需继续存储功能分支因为我将所有内容都放入了 TAG（代码、历史记录等）。我说的对吗？

Answer 1

大部分是正确的。但是，您不能合并到 Git 中的标签中。在 Git 中，标签是不可变的。每次更改时，您都必须创建一个新标签。

是的，如果你删除了一个标记了最新提交的分支，那么再次创建这个分支是很容易的。

---

“我决定在 feature_branch 上开发这个功能。”

(main_branch) $ git checkout -b feature_branch
(feature_branch) $ ... development ...

“我标记了功能分支并将其发布到生产环境中。”

(feature_branch) $ git tag myfeature_v1.0

“我合并特征分支...”

(feature_branch) $ git checkout main_branch
(main_branch) $ git merge feature_branch
(main_branch) $ ... fix merge ...

“我删除了功能分支……”

(main_branch) $ git branch -d feature_branch

“糟糕！我想再次创建功能分支...”

(main_branch) $ git checkout -b feature_branch myfeature_v1.0
(feature_branch) $ ... fix bugs ...

Answer 2

您的假设非常接近标记，Dietrichs 的回答很好，但让我更深入一点。

在 git 中，分支和标签在结构上是 无关的。它们只是一些小便签（“refs”），指向一些代表实际提交的十六进制哈希数。分支会定期进行新的提交（这是它们的目的），而标签仅在您强制它们更改时才会更改，但不会自动更改。 （在大型项目中存在与信任相关的签名标签——它们完全不同，但与日常工作无关）。

git 中的每个提交都包含整个文件树并且是自给自足的。

提交跨越了我们亲切地称为“有向无环图”的东西，这是一种奇特的说法，即每个提交都有任意多个父级（1 个用于常规提交，2 个用于常规合并，3+ 用于章鱼合并我们中的任何人都不太可能在实践中看到）和孩子。

所以。除了方便之外，分支和标签是无关紧要的，因为该图是不可变的。什么都不会改变您提交的内容，并且所有提交及其分支和标签都非常容易地显示在图表中。这就是颠覆的巨大差异，它让你在 git 中对这些事情真正放松。只要您牢记前面段落中提出的概念，就很难失去任何东西。

TLDR：您可以删除您的分支和标签，如果需要，您仍然可以快速查看gitk 或git log --graph --decorate。如果您不小心删除了您仍然需要的 ref，所有 git 命令都会使用提交哈希名称而不是标签/分支名称。