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

虽然git不关心你是否重用分支名称，但在实践中它不是没有潜在的后果。 tl; dr：只是因为您从您的中删除了本地和远程，并不意味着它已从每个回购中消失。

为什么你可以做到这一点： git分支是ref。也就是说，它是指向提交的指针的名称。如果你删除了一个ref，git并没有试图跟踪之前使用过这个特定名字的事实。 （其实即使对于分支reflog就会被丢弃，这可能有像样的理由，但在某种程度上是不幸）

为什么你可能不应该：在裁判，有什么特别的分支是他们预期移动，并有一个默认规则他们预计如何移动。 （这是相对于像标签裁判，这只是预期通常不移动）

具体来说，分支预计，在创建新的提交到由父母转移到孩子。如果在两个不同时刻都存在一个具有给定名称的分支，则预计它在较早时刻指向的提交是“可到达的”（通过父指针），它指向稍后的提交。

现在，如果您已经删除了分支的所有痕迹（从本地和远程删除），那么重新使用分支名称似乎足够安全。但是既然你有一个遥控器 - 或者说那个问题，因为你使用的是分布式版本控制系统 - 我们至少应该考虑到你的遥控器不是唯一的克隆。

假设你开始你的项目。

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分支以意想不到的方式移动。这并不难解决，但是他们得到的错误中最“显而易见”的方式是错误的，并且会导致奇怪的结果。这很烦人，你的工作流程不应该经常创建这个条件。

是的，可以在新分支中使用同一分支名称（已删除分支的名称 - 本地和远程删除）。

一旦分支被清除，即使您之前在合并中使用了已清除的分支，也不会有名称冲突。