Git 分支删除 [AWS 代码提交]

Git branch delete [AWS Code Commit]

我目前在 AWS Code Commit 中有 masterfeatures 分支。我需要为项目创建更多分支。

假设,我将创建新的 ui-improvement 分支,几天后,我在本地和远程删除了该分支。之后,是否可以在使用 ui-improvement 之前创建相同的分支名称?

是的,可以在新分支中使用相同的分支名称(已删除分支的分支名称 - 本地和远程删除)。

擦除分支后,将不会有名称冲突,即使您之前在合并中使用了擦除的分支。

虽然 git 确实不在乎您是否重复使用分支名称,但实际上并非没有潜在后果。 tl;dr:只是因为您将它从 您的 本地和远程中删除,并不意味着它已从每个存储库中消失。

为什么你可以这样做: git 一个分支就是一个参考。也就是说,它是指向提交的指针的名称。如果您删除一个 ref,git 不会尝试跟踪该特定名称之前被使用过的事实。 (事实上​​ ,甚至分支的 reflog 也被丢弃,这可能有正当理由但在某种程度上是不幸的。)

为什么你可能不应该: 在 refs 中,分支的特别之处在于它们应该移动,并且有一个默认规则如何 他们预计会搬家。 (这与像标签这样的 refs 形成对比,通常只是希望它们 不会 移动。)

具体来说,随着新提交的创建,一个分支应该从父分支移动到子分支。如果在两个不同时刻的每一个时刻都存在一个具有给定名称的分支,那么预计它在较早时刻指向的提交与它在稍后时刻指向的提交相差 "reachable"(通过父指针)时间。

现在,如果您删除了分支的所有痕迹(从本地和远程删除),那么重新使用分支名称似乎足够安全。但是既然你有一个遥控器 - 或者就此而言,因为你使用的是分布式版本控制系统 - 我们至少应该考虑到你的不是遥控器的唯一克隆的可能性。

假设您启动项目。

A -- B -- C <--(master)

然后你创建一个分支

A -- B -- C <--(master)
      \
       D -- E <--(fixes)

并且你已经将它推送到源,另一个开发人员已经将所有这些都拉到他们的本地。所以他们有

A -- B -- C <--(master)(origin/master)
      \
       D -- E <--(fixes)(origin/fixes)

现在你继续工作,很快你就会

             H -- I <--(a_branch)
            /
A -- B -- C ------------ M<--(master)
      \                /
       D -- E -- F -- G <--(fixes)

到目前为止一切都很好,因为每个分支都只是向前发展。另一个开发者拉动并且是最新的。

             H -- I <--(a_branch)(origin/a_branch)
            /
A -- B -- C ------------ M<--(master)(origin/master)
      \                /
       D -- E -- F -- G <--(fixes)(origin/fixes)

但现在您删除 fixes,因为它已合并。 a_branch 上发生了一些事情,因此您决定需要一个新的 fixes 分支。

                    K <--(fixes)
                   /
             H -- I <--(a_branch)
            /
A -- B -- C ------------ M<--(master)
      \                /
       D -- E -- F -- G

所以另一个开发人员进行了一次获取,现在

                    K <--(origin/fixes)
                   /
             H -- I <--(a_branch)(origin/a_branch)
            /
A -- B -- C ------------ M <--(master)(origin_master)
      \                /
       D -- E -- F -- G <--(fixes)

现在从他们的回购协议的角度来看,fixes 分支似乎以意想不到的方式移动。这并不难解决,但大多数 "obvious" 的错误解决方法都是错误的,并且会导致奇怪的结果。这很烦人,您的工作流程不应该经常造成这种情况。