我可以使用同一个分支而不是新分支吗？答案

【问题标题】：Can I use the same branch instead of a new branch?我可以使用同一个分支而不是新分支吗？
【发布时间】：2022-01-10 09:50:09
【问题描述】：

我在开发分支上进行开发。通常我会从开发分支创建我的功能分支。与场景 1 类似：

场景 1

development -> featureA -> development -> megre featureA = COMPLETE 
// A few feature branches later I realise I need to do something in featureA 
development -> featureA_1 -> development -> megre featureA_1 = COMPLETE

但我也认为我可以采用已经存在的 featureA 分支并将其更新。就像在场景 2 中一样。

场景 2

development -> featureA -> development -> megre featureA = COMPLETE 

// A few feature branches later I realise that I still have to do something in featureA 
develompment -> featureA 
-> merge development 
-> ..add new things ... 
-> development 
-> merge featureA_1

问题：场景 B 会导致问题吗？

【问题讨论】：

ff-merge 将不可能（可能）。由于合并，变基可能也无法顺利进行
据我所知，场景 2 很好。你可以通过这个简单的标准来判断它是否会好起来：如果将开发合并到 featureA 是一个快进合并，那么它会好起来的。如果没有，那么从一个新的分支开始。
对于它的价值，在我的开发工作流程中，一旦我合并了一个分支，我就会删除它。所以无论如何我都不会有featureA。因此，当我开始创建 featureA_1 时，名称 featureA 将是免费的，我可能会为新分支重用该名称。
@joanis 当您说合并后再次删除分支时，您当然是绝对正确的。这就是我在其他项目中所做的。在这个项目中它是不同的（至少在开始时），这就是出现这个问题的原因。谢谢你！
@MaikLowrey 有点奇怪的工作流程，保留旧的功能分支，但如果这是你的工作流程，重用分支可能没有意义：一旦你快进合并开发回到 featureA，那么在合并后保留 featureA 分支可能拥有的任何信息都将丢失，因为它看起来就像是在 featureA_1 启动时从开发中分离出来，而不是在 featureA 开始时。因此，我仍然声称您本身不会遇到问题，但它可能会破坏最初合并后保留这些分支的目的。

标签： git

【解决方案1】：

重要的是要认识到，对于 Git，分支——或者实际上是分支名称——是无关紧要的。在 Git 中重要的是 commits。完全不使用任何分支名称就可以使用 Git：人类以这种方式工作非常不方便。

Git 通过哈希 ID 查找提交。实际上，提交的哈希 ID 是它的“真实名称”：请参阅 the Wikipedia definition，如果您不介意迷失在 TV-Tropes 页面中，请参阅 the TV trope "I Know Your True Name"。但是哈希 ID 又大又丑，人类无法记住：你能一眼看出 dcc0cd074f0c639a0df20461a301af6d45bd582e 和 dcc0a86f2f2f036b3a379f41a4b754f8bb73ed6b 吗？但是，如果其中一个现在是master，而一个是 master 或过去某个时候的其他名称，那么那些对人类来说是有意义的。所以我们使用分支名称。

在 Git 中，分支名称是具有多个特定属性的名称。 Git 中的所有引用存储一个哈希 ID，因此分支名称存储一个哈希 ID。分支名称的特别之处在于：

它的全名以refs/heads/开头：例如dev是refs/heads/dev的缩写；
Git 将允许您“启用”一个分支名称：其他名称强制执行 Git 所称的 分离 HEAD 模式，在使用 git switch 时需要 --detach 标志，并在使用 @ 时自动分离987654334@;和
当您进行新提交时并且“在”某个分支上，Git 会自动将新提交的哈希 ID 写入分支名称.

正是这最后一个属性使分支名称特别有用：在git checkout <em>branch</em> 或git switch <em>branch</em> 之后，我们“打开”该分支，new 提交会自动推进分支名称。如果没有此功能，我们将不得不写下所有提交哈希 ID，以便能够再次找到它们，或者同样令人讨厌的东西（也许在我们工作时手动 git update-ref 每个名称）。

无论如何，一旦您意识到分支名称的目的只是为了能够查找提交，以前关于 Git 的许多神秘事物就会变得简单得多。如果您将存储库可视化为 commits（通过单向、向后的箭头连接，以便每个“子”提交记住其父级或父级），您会得到一个简单的Directed Acyclic Graph，如下所示：

          D <-E <-F
         /
A <-B <-C
         \
          G <-H

其中F 和H 是两个“分支”中的最新提交，它们在提交C 处合并或分开，具体取决于您是否“向后”遍历提交"（Git 风格）或“forwards”（人类风格）。 分支名称只是定位特定的提交：

        D--E--F   <-- br1
       /
A--B--C   <-- main
       \
        G--H   <-- br2

例如，或者也许：

        D--E--F   <-- develop
       /
A--B--C--G--H   <-- master

请注意，这些是相同的图表。一个图具有提交C 的名称，而一个没有，这一事实不会影响图。由于 Git 只关注提交和图表——根本不关注分支名称——就 Git 无论如何都会做的而言，这些基本上是相同的存储库。要将第二个更改为第一个，我们只需将develop 重命名为br1，将master 重命名为br2，并添加一个名称main 指向提交C。

这可能不是人类将打算使用它的方式，但这就是Git所看到的。所以像这样的问题：

场景 B 会导致问题吗？

真的是关于人类是否会犯某些错误的问题。我认为没有人能真正正确地预测human reliability，但如果您知道您个人犯了什么样的错误，您也许能够评估什么最适合您。不过，这并不是一个可以通过获取 StackOverflow 答案来解决的技术问题。 ?

【讨论】：