Git:分支之间向上/向下方向的定义感觉违反直觉

Question

Git:分支之间向上/向下方向的定义感觉违反直觉

我正在阅读https://git-scm.com/docs/gitworkflows上的gitworkflows文档(也可以在"man gitworkflows"中阅读),但是分支之间的向上/向下方向的定义对我来说是违反直觉的.我没理解它,所以我想知道是否有任何我想念的东西.

具体来说,上述链接文档的"管理分支>毕业"部分说

毕业

由于给定的特征从实验到稳定,它也在软件的相应分支之间"毕业". git.git使用以下集成分支:

maint跟踪应该进入下一个"维护版本"的提交,即更新最后发布的稳定版本;

master跟踪应该进入下一个版本的提交;

next是作为测试主要稳定性主题的测试分支.

第四个官方分支的使用方式略有不同:

pu(建议更新)是一个集成分支,用于尚未准备好包含的内容(请参阅下面的"集成分支").

四个分支中的每一个通常是其上方的分支的直接后代.

最后一句似乎暗示maint > master > next > pu是向下的方向(因为master是maint的后代,等等).

但是,文档继续说

从概念上讲,功能在一个不稳定的分支(通常是进入下一个 或PU),和"毕业生",以掌握,一旦它被认为是足够稳定的下一个版本.

合并向上

上面讨论的"向下毕业"[...]

因此,在最后一句中,文档实际上定义了新特征在next > master方向上的传播为"向下分级".这与我早先的印象相反,即master > next是向下的方向.

对我来说,定义maint > master > next > pu作为向下方向感觉不仅更自然,而且更符合上游/下游存储库的定义.我们通常将远程"上游"存储库克隆到本地存储库,实现新功能,并将它们"向上"推送到远程存储库.(注意,这里的最后一步被称为"向上推").这整个过程是并行分支下一从主,在实现新的功能未来,并合并他们掌握.因此,我认为从旁边到master的新功能的传播也应该被称为"向上分级"(与从本地到远程存储库的"向上推"并行).然而,它在文档中被称为"向下毕业".

为什么Git使用这种反直觉定义分支之间的向上/向下方向？我怎么能理解它？或者,为了理解这个定义,我有什么重要的缺失吗？

Answer 1

Von*_*onC 4

自 2009 年以来，所有这些向下/向上合并都是Reintegrate由 Junio C. Hamano （在提交 cc1b258中解释）使用的脚本自动执行的，用于管理来自gitster/git（有很多分支）的 git 分支

但早在 2007 年，第一次修订Documentation/howto/maintain-git.txt就更加明确（并且是手动的）

next我认为新特征从到的传播master应该称为“向上毕业”

我同意，原始文件显示：

master->next如果需要，向下合并 ( )：
$ git checkout next
$ git merge master
$ make test
Run Code Online (Sandbox Code Playgroud)

在这种情况下，如果您合并next到master（为了升级next到中的新 git 版本master），您确实会向上合并。

关于Thomas Rast 在 2008 年引入的更现代的形式进行了有趣的讨论 ( )Documentation/gitworkflows.txttrast

Junio C. Hamano 在那里提到：

这个描述忽略了合并到主题分支不是一个好主意的最重要原因。一旦将通用集成分支（例如）合并master到主题分支中，该分支就不再是关于单个主题的。
它变成：“主题和其他不相关的变化混合在一起”。

始终向上合并是一个很好的规则，当与主题分支一起使用时，有一个你没有提到但值得了解的扭曲。
旨在最终合并到较旧的集成分支（例如maint）的主题不一定必须首先合并到其最终目标分支。
我经常这样做：
   git checkout tr/maint-fix-bla maint
   git am -s fix-mail-from-thomas.txt
   git checkout next
   git merge tr/maint-fix-bla
   ... cook further, perhaps adding more commits to
   ... tr/maint-fix-bla topic and merging the result to next;
   ... and then when the topic appears to be stable do:
   git checkout master
   git merge tr/maint-fix-bla
   
   vvvvvvvvvvvvvvvvvvvvvvvvv
   ... and later
   git checkout maint
   git merge tr/maint-fix-bla
   git branch -d tr/maint-fix-bla
Run Code Online (Sandbox Code Playgroud)
这会使旧的集成分支保持陈旧，直到该主题真正被证明在现场不会出现回归问题。
此工作流程更安全，更适合最终集成分支，已知的损坏比意外的回归更好。

另一种选择是读者从您对向上合并的描述中假设的内容，如下所示：
   git checkout tr/maint-fix-bla maint
   git am -s fix-mail-from-thomas.txt
   git checkout maint
   git merge tr/maint-fix-bla
   git checkout master
   git merge maint
   git checkout next
   git merge master
Run Code Online (Sandbox Code Playgroud)
这可能会maint无意中回归，然后回归会向上传播以污染所有集成分支。

和：

我们使用“集成分支”一词来表示稳定分支，例如maint// 。masternext

请注意，在 Git 2.28（2020 年第三季度）中，文档和一些测试已针对最近将“ ”pu分支重命名为“ seen”进行了调整。

请参阅Johannes Schindelin ( )的提交 6dca5db、提交 77dc604、提交 828197d（2020 年 6 月 25 日）。^（由^{Junio C Hamano 合并 --}^--^在^{提交 8a78e4d}^{，2020 年 7 月 6 日）}dscho
^gitster

docs：调整为最近重命名pu为seen

^{签署人：约翰内斯·辛德林}

从“ What's Cooking in git.git(Jun 2020, #04; Mon, 22) ”开始，不再有任何pu分支，而是一个seen分支。

虽然从技术上讲我们甚至不需要更新手册页，但更新它们是有意义的，因为它们清楚地讨论了git.git中的分支。

请注意，在两种情况下，此补丁不仅更新分支名称，还更新描述“（建议更新）”。

为了便于阅读，在适当的情况下添加了引号。

和：

tests: 引用seen任何地方pu的引用

^{签署人：约翰内斯·辛德林}

由于我们的测试套件部分反映了我们在 Git 项目中的工作方式，因此很自然地pu在几个地方使用了分支名称。

由于该分支已重命名为seen，让我们一致使用新名称。

从邮件列表中：

“pu”（提议的更新）分支已重命名为“seen”，以使用更有意义的名称（毕竟，它的目的不是包含所有提案，而只是作为一个停放维护者发生的事情的地方已经看到），更重要的是，为那些两字母姓名缩写需要在“ pu”下的“ pu/$topicName”的贡献者的主题腾出空间。

您可以在存储库的集成分支中找到此处描述的更改。

Git 2.42（2023 年第三季度）在开发者指导文档中明确了如何选择新主题的起点，阐释了“向上”的概念。

请参阅Linus Arver ( )的提交 0a02ca2、提交 5c98149、提交 b5dbfe2、提交 3423e37、提交 fc0825d（2023 年 7 月 14 日）。^（由^{Junio C Hamano 合并 --}^--^在^{dd68b57 提交}^{，2023 年 8 月 4 日）}listx
^gitster

SubmittingPatches：简化选择起点的指导

^{帮助者： Jonathan Nieder}
^{帮助者： Junio C Hamano}
^{签字人： Linus Arver}

背景： d0c26f0中添加了“将您的工作建立在与您的更改相关的最旧分支上”的指南（“ SubmittingPatches：添加有关工作基础的新部分”，2010-04-19，Git v1.7.2-rc0 ——合并）。
该提交还添加了描述使用以下命名分支之一的场景的要点：“maint”、“master”、“next”和“seen”（原文中的“pu”就是名称）该分支在重命名之前，根据828197d（“ docs：调整最近的重命名为pu” seen，2020-06-25，Git v2.28.0-rc0 -合并在批次 #7中列出））。
该指南可能取自f948dd8gitworkflows的“向上合并”部分中引入的现有类似语言（“ ：添加有关工作流程的手册页”，2008-10-19，Git v1.6.1-rc1 - merge）。Documentation

摘要：此更改通过将用户指向“maint”或“master”来简化指导。
但它也解释了为什么这是首选以及首选“较旧”分支的含义（这可能会让某些人感到困惑，因为这里的“旧”是指这些命名分支之间的相对术语，而不是指它们的年龄）分支本身）。
我们还添加了一个示例来说明为什么使用“下一个”作为起点是一个坏主意，这对于新贡献者来说可能不是那么明显。

SubmittingPatches现在包含在其手册页中：

作为第一步，您必须首先选择工作的起点。通常，这意味着选择一个分支，尽管从技术上讲，它实际上是一个特定的提交（通常是分支的 HEAD 或提示）。

有几个重要的分支需要注意。也就是说，有四个集成分支，如 linkgit:gitworkflows 7中讨论的：

维护

掌握

下一个

见过

列表中较低的分支通常是前面的分支的后代。例如，maint是一个“较旧”的分支， master因为master通常在 maint.

还有“主题”分支，其中包含其他贡献者的工作。主题分支由 Git 维护者（在他们的分支中）创建，用于组织邮件列表上当前收到的贡献集，并在常规的“git.git 正在烹饪什么”公告中逐项列出。要查找主题分支的提示，请运行git log --first-parent master..seen并查找合并提交。此提交的第二个父级是主题分支的尖端。

选择正确的起点有一个指导原则：一般来说，始终将您的工作基于与您的更改相关的最旧的集成分支（请参阅 linkgit:gitworkflows 7中的“向上合并” ）。这个原则的意思是，对于绝大多数情况，新工作的起点应该是以下情况的最新 HEAD 提交maint或master基于以下情况：

如果您正在修复已发布版本中的错误，请使用maint作为起点（这可能意味着您必须在不使用最近出现 master但在已发布版本中不可用的前沿的新 API 功能的情况下修复问题）。

否则（例如如果您要添加新功能）请使用master.

这也意味着，如果您希望您的工作有现实的机会毕业，那么next或对于您的工作来说是不合适的起点。它们根本不是为新工作提供稳定的基础而设计的，因为它们（根据设计）经常与邮件列表上的传入补丁重新集成，并强制替换这些分支的先前版本。seenmaster

例如，如果您正在进行树范围的更改，而其他人也在进行自己的树范围的更改，则您的工作可能与其他人的工作严重重叠。这种情况可能会诱使您将next其作为起点（因为它将包含其他人的工作），但这样做意味着您不仅会依赖于其他人的工作，还依赖于其他人的所有其他随机事物。已经集成到next. 一旦next更新了新版本，您的所有工作都需要重新调整基础，以便维护者能够干净地应用它们。

在真正特殊的情况下，您绝对必须依赖于已经在next但不在中的选定几个主题分支master，您可能希望通过分叉 master并合并所需的主题分支来创建您自己的自定义基础分支。然后您可以在这个基础分支之上工作。但请记住，这个基本分支只有您自己知道。因此，当您准备好将补丁发送到列表时，请务必在求职信中说明您是如何创建它的。
这条关键信息将允许其他人在他们的末端重新创建您的基础分支，以便他们尝试您的工作。

归档时间：	9 年，9 月前
查看次数：	580 次
最近记录：	9 年，9 月前

Git:分支之间向上/向下方向的定义感觉违反直觉

`docs`：调整为最近重命名`pu`为`seen`

`tests`: 引用`seen`任何地方`pu`的引用

`SubmittingPatches`：简化选择起点的指导

Git:分支之间向上/向下方向的定义感觉违反直觉

docs：调整为最近重命名pu为seen

tests: 引用seen任何地方pu的引用

SubmittingPatches：简化选择起点的指导

`docs`：调整为最近重命名`pu`为`seen`

`tests`: 引用`seen`任何地方`pu`的引用

`SubmittingPatches`：简化选择起点的指导