为什么我应该删除功能分支时合并到主 [英] why should I delete feature branches when merged to master

问题描述

我见过的大多数git工作流都建议在合并到master后删除分支。例如，这个 gitflow 建议如下：

 ＃在开发
 $中包含完成的功能git checkout develop 
转换到分支'develop'
 $ git merge --no- ff myfeature 
更新ea1b82a..05e9557 
（变更汇总）
 $ git branch -d myfeature 
删除分支myfeature（05e9557）。 
 $ git push origin develop 
  

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

解决方案

重要的是Git分支只不过是一个指向提交的标签。在Git中分支就是分支。如果功能分支为 master ，当 master c>是一个提交B.

  A  -  B  -  C  -  F  -  H [master] 
 \ 
 D  -  E  -  G  -  I [功能] 
  

实际分支。当你把 git merge feature 合并到master时，你可以得到这个。

  A -  B  -  C  -  F  -  H  -  J [master] 
 \ / 
 D  -  E  -  G  -  I [功能] 
  

一旦你 git branch -d feature 分支历史记录仍然存在！

  A  -  B  -  C  -  F  -  H  -  J [master] 
 \ / 
 D  -  E  -  G  -  I 
  

J有父母H和I.如果没有他们，J就不可能存在，它已经融入了Git的工作方式。没有G我就不能存在。没有E就不能存在。等等。该分支必须保留

J是一个合并提交，它通常包含被合并分支的名称。它像任何其他提交，所以你甚至可以添加更多的信息，如链接回你的问题跟踪。

$ b

git merge - no-ff 用于阻止Git执行快进并丢失分支历史记录。如果在创建分支后没有对 master 执行任何工作，就会发生这种情况。快速前进看起来像这样。

  A  -  B [master]  -  D  -  E  -  G  -  I [特性] 
 
 git checkout master 
 git合并功能
 
 A  -  B  -  D  -  E  -  G  -  I [特性] [master] 
  master 是特征的直接祖先，所以 > 
 
 
 code>，不需要合并。 Git可以移动 master 标签。您的分支历史记录已丢失，看起来像D，E，G和我都是作为个人提交的。  git merge --no-ff 告诉Git永远不要执行此操作，总是执行合并。  
 
 
未来，当发现在G中引入了一个错误时，浏览存储库的任何人都可以看到它是作为分支的一部分完成的，展望未来找到合并提交，并从那里获取有关分支的信息。
 
 
 
即便如此，为何要删除分支？两个原因。首先，它会让你的分支清单杂乱无章。
 
 
 
其次，更重要的是，它阻止你重用分支。分支和合并很复杂。通过确保您只有一次将分支合并回主一次，单次使用，短期生活的功能分支简化了过程。这消除了许多技术和管理问题。当你合并一个分支时，它是完成的。如果您需要修复该分支中引入的问题，请将其作为主服务器中的错误处理，然后创建一个新分支来修复它。
 
 
 
不幸的是， git log 对用户有用，并呈现非线性历史的线性表示。要解决这个问题，请使用 git log --graph --decorate 。这将按照上面的示例绘制线条，并在每次提交时向您显示任何分支和标签。您将获得更真实的存储库视图。
 
 
 
如果您在Mac上， GitX 将可视化您的存储库。  gitk 是通用版本。
 
Most of the git workflows I've seen suggest to delete a branch after it's been merged into master. For example, this gitflow suggests the following:
# 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
Why should I delete the branch? I'm also curios what to do when later a bug is discovered that was introduced by the feature - should I create the branch with the same name again, fix bug there, merge into master and again delete the branch?
解决方案
Something important to realize is Git branches are nothing more than a label pointing to a commit.  Branching in Git is literally branching.  Here's what a repository looks like if feature branched off master when master was a commit B.
A - B - C - F - H [master]
     \
      D - E - G - I[feature]
See?  Actual branch.  When you git merge feature into master, you get this.
A - B - C - F - H - J [master]
     \             /
      D - E - G - I  [feature]
And once you git branch -d feature the branch history remains!
A - B - C - F - H - J [master]
     \             /
      D - E - G - I
J has the parents H and I.  J cannot exist without them, it's baked into how Git works.  I cannot exist without G.  G cannot exist without E.  And so on.  The branch must remain

J is a merge commit which will typically contain the name of the branch being merged.  Its like any other commit, so you can even add more information to it, like a link back to your issue tracker.

git merge --no-ff is used to prevent Git from doing a "fast forward" and losing the branch history.  This happens if no work has been done on master since the branch was created.  A fast-forward looks like this.
A - B[master]- D - E - G - I [feature]

git checkout master
git merge feature

A - B - D - E - G - I [feature] [master]
Since master is a direct ancestor of feature, no merge is required.  Git can just move the master label.  Your branch history is lost, it looks like D, E, G and I were all done as individual commits on master.  git merge --no-ff tells Git to never do this, to always perform a merge.

In the future, when it's noticed a bug was introduced in G, anyone browsing the repository can see it was done as part of the branch, look ahead to find the merge commit, and get information about the branch from there.

Even so, why delete the branch?  Two reasons.  First, it will clutter up your list of branches with dead branches.

Second, and more important, it prevents you from reusing the branch.  Branching and merging are complicated.  Single use, short lived feature branches simplify the process by ensuring you only ever merge the branch back into master once.  This eliminates many technical and management problems.  When you merge a branch, it is done.  If you need to fix a problem introduced in that branch, just treat it as a bug in master and make a new branch to fix it.

Unfortunately, git log lies to the user and presents a linear representation of history that is not linear.  To fix this, use git log --graph --decorate.  This will draw lines as in my examples above, and show you any branches and tags on each commit.  You'll get a much truer view of the repository.

If you're on a Mac, GitX will visualize the repository for you.  gitk is the generic version.

                        
这篇关于为什么我应该删除功能分支时合并到主的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！