Fatal编程技术网
  • git/
  • Git 如何仅为标记的提交创建单独的分支？

Git 如何仅为标记的提交创建单独的分支？

git

Git 如何仅为标记的提交创建单独的分支？,git,Git,我的任务是以这样的方式组织存储库：除了其他分支之外，还有一个专门的分支，我们将只存储发布版本的提交。以下是我希望实现的简化方案： | trunk | | releases | |----------+-----------+----------| | commit 1 | | | | commit 2 | v0.1 ---> | tag 1 | | commit 3 | | | |

我的任务是以这样的方式组织存储库：除了其他分支之外，还有一个专门的分支，我们将只存储发布版本的提交。以下是我希望实现的简化方案：

| trunk    |           | releases |
|----------+-----------+----------|
| commit 1 |           |          |
| commit 2 | v0.1 ---> | tag 1    |
| commit 3 |           |          |
| commit 4 |           |          |
| commit 5 |           |          |
| commit 6 | v0.2 ---> | tag 2    |
| commit 7 |           |          |
| commit 8 |           |          |
| commit 9 |           |          |
现在这对我来说有点太高级了，所以我希望能得到一些指导！我不确定如何才能在“releases”分支中使用第二个标记，而不必导入所有中间提交。那有可能吗

此外，如果您有一个更好的方案来实现相同的目标（目标是有一个只用于发布的专用分支），请不要犹豫提供建议

这是没有意义的，因为标记的提交表示由提交及其前辈组成的分支的状态

仅隔离标记的提交将编写一个非常不同的历史，因为这些提交将丢失它们的祖先：正是所述祖先的序列加上标记的提交将代码库引导到特定状态

更简单的方法是确保在一个专用分支（例如master）中标记发布提交

然后，一个简单的示例可以列出这些标记引用的Comimt

或者您可以（用于修复发行版的bug）

您可以（
git descripe--long
）

报告补充说：

但是发布版本的分支只存储特殊提交（标记的提交）的历史记录，并指向其他分支作为提交来源

这可以通过将标记提交合并到一个“发布分支”中来实现（即合并的源，即标记提交的源）

您首先需要了解git的一些内容：

  • git回购可以看作是一堆提交。每个都有一个或两个（合并）父提交
  • 标记只是指向其中一个提交的指针。已经修好了
  • 分支也是指向这些提交之一的指针。但它将始终指向您在该分支上的位置时所做的最后一次提交。所以它是一个“动态”指针
也许这就解释了为什么你想要的东西没有真正意义：标记独立于分支。

这没有真正意义。在git中，分支名称只是一个指向特定提交的标签，在该标签中，添加新提交时名称会自动“向前移动”：

C1 -- C2 -- C3         <-- label X
              \
                D1     <-- label Y

C1--C2--C3这是一个分支模型，我以前使用过它来保持开发、错误修复、功能和发布都是独立的，但协调的。这可能对你有帮助


您为什么需要一个单独的分支机构？为什么不在master上加上释放标签？@tjameson 1。我不确定。2.这就是给我的任务：）3。有人提出，如果其他人需要一个发布版本，他们必须更容易只知道一个“地址”以供求助。。。好吧，让我们称之为企业逻辑问题，我还不是其中的大师。@tjameson：这看起来像是git流（）的一部分。我不知道如何通过git在一个分支中只强制执行标记的提交，但作为一种惯例，它工作得相当好。+1类似于发布分支上的
git commit--allow empty
，可以解决这个问题，但是标记仍然会显示在
git tag
的输出中。--allow empty选项的好处是，
git descripe
可以在不同的分支上以不同的方式工作。我的意思是，我希望提交的历史记录存储在实际发生的位置——在相关的分支中，但发布的分支只存储在其中的特殊提交（标记的提交）的历史记录，并指向其他分支作为提交的来源。我无法想象一个完全独立的提交会同时包含来自其他几个提交的更改。。。不是说它会痛，但我认为这是不可能的：）谢谢！我试图阅读你链接到的另一个问题，但与此同时，要求发生了变化。。。另外，我真的不认为我理解了另一个答案，但我很高兴我不必再这么做了：）谢谢你的时间！小结：“八达通合并”有两个以上的父母。（Mercurial一次将合并限制为两个父级；为了获得八达通合并的效果，您需要执行一系列成对合并。当然，最终的结果是一样的。）根提交没有父级，因此git中的提交有零个或多个父级。与我的回答类似，但使用更多ascii艺术，所以+1；）我想我真正需要的是与你的例子相反的。。。我更多地考虑的是主分支上的
--no ff
提交，在主分支上它不会存储来自分支的历史记录，而原始提交来自该分支。你的帖子很有趣，但不幸的是并没有让我提前实现目标：（不过还是要谢谢你！@wvxvw:你可能确实想要
——没有ff
合并到你用于发布的分支中。但是标签仍然没有任何有用的意义上的“在分支上”。提交是“在”的东西-更恰当地说，“可从”是一个引用标签。实际上，标签与分支名称处于同一级别，位于该空间之外。（这就是为什么它们出现在
.git/refs/tags/
中的文件中，就像分支名称出现在
.git/refs/branchs/
中一样。事实上，标记有时可能是提交的唯一外部名称，防止提交被垃圾收集。）

--x--x--x--x--x--x--x
 (v1)     (v2)
   \        \ 
----y--------y--



C1 -- C2 -- C3         <-- label X
              \
                D1     <-- label Y



C1 -- C2 -- C3 -- C4   <-- label X
              \
                D1     <-- label Y



C1 -- C2 -- C3 -- C4   <-- branch X, tag TC
              \
                D1     <-- branch Y, TD



                   .------------- tag TC
                   v
C1 -- C2 -- C3 -- C4 -- C5   <-- branch X
               \      /
                  D1         <-- branch Y, tag TD