合并为master时,为什么要删除功能分支?

Max*_*kyi 35 git git-flow

我见过的大多数git工作流建议branch在合并到master之后删除它.例如,这个gitflow建议如下:

# Incorporating a finished feature on develop 
$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff myfeature
Updating ea1b82a..05e9557
(Summary of changes)
$ git branch -d myfeature
Deleted branch myfeature (was 05e9557).
$ git push origin develop
Run Code Online (Sandbox Code Playgroud)

我为什么要删除分支?我也好奇当以后发现一个由该功能引入的错误时该怎么做 - 我是否应该再创建一个具有相同名称的分支,修复那里的bug,合并到master并再次删除分支?

Sch*_*ern 50

要实现的重要事情是Git分支只不过是一个指向提交的标签.Git中的分支实际上是分支.这里有一个仓库的样子,如果feature分支mastermaster被提交B.

A - B - C - F - H [master]
     \
      D - E - G - I[feature]
Run Code Online (Sandbox Code Playgroud)

看到?实际分支.当你git merge feature进入高手时,你会得到这个.

A - B - C - F - H - J [master]
     \             /
      D - E - G - I  [feature]
Run Code Online (Sandbox Code Playgroud)

一旦你git branch -d feature的分支历史仍然存在!

A - B - C - F - H - J [master]
     \             /
      D - E - G - I
Run Code Online (Sandbox Code Playgroud)

J有父母H和I.如果没有他们,J就不存在,它就是Git的工作方式.没有G.我不可能存在.没有E.不能存在.等等.分支必须保留

J是合并提交,通常包含要合并的分支的名称.它与任何其他提交一样,因此您甚至可以向其添加更多信息,例如返回问题跟踪器的链接.

git merge --no-ff用于防止Git执行"快进"并丢失分支历史记录.如果master自创建分支以来未完成任何工作,则会发生这种情况.快进看起来像这样.

A - B[master]- D - E - G - I [feature]

git checkout master
git merge feature

A - B - D - E - G - I [feature] [master]
Run Code Online (Sandbox Code Playgroud)

由于master是直接祖先feature,因此不需要合并.Git可以移动master标签.您的分支历史记录丢失了,看起来D,E,G和I都是作为master上的单独提交完成的. git merge --no-ff告诉Git永远不要这样做,总是执行合并.

在将来,当注意到G中引入了一个错误时,任何浏览存储库的人都可以看到它是作为分支的一部分完成的,预先查找合并提交,并从那里获取有关该分支的信息.

即便如此,为什么删除分支?两个原因.首先,它会使你的分支列表变得杂乱无章.

其次,更重要的是,它会阻止您重复使用分支.分支和合并很复杂.单次使用,短期功能分支通过确保您只将分支合并回主服务器一次来简化过程.这消除了许多技术和管理问题.合并分支时,它就完成了.如果您需要修复该分支中引入的问题,只需将其视为master中的错误并创建一个新分支来修复它.

不幸的是,git log对用户来说是谎言,并且呈现出非线性的历史的线性表示.要解决此问题,请使用git log --graph --decorate.这将在上面的示例中绘制线条,并在每次提交时显示任何分支和标记.您将获得更真实的存储库视图.

如果您使用的是Mac,GitX会为您显示存储库. gitk是通用版本.