git分支总是要合并吗？

Question

Before : My question is focused on Git philopsophy and best practice, not on technical POV.

I wonder if a Git branch fate is to be eventually merged all the time . Will we stick to best practice using a branch to live it's own life without merging at any time to master, and knowing it at start?

Would it be better in this case to create an new repo with this branch content?

Answer 1

A branch name is mostly just a name for a commit, just like a tag name. There's no need to use it to make merge commits, though there's no compelling reason not to use it that way either.

When a name—including a branch name or a tag name—identifies some commit, such as the commit whose hash ID starts with 1234567... , we say that this name points to that particular commit. The "true name" of the commit is the hash ID, and any number of (non-hash-ID) names —zero, one, two, a million—can all point to that commit. The hash IDs are terrible for humans to use (who can remember a3c921fa60b7... for more than a few seconds?) so we generally prefer names. When a commit is particularly important, we might give it a name, or several names.

There is one very important way that a branch name is not like a tag name, though, and that is how Git behaves when you are "on" the branch, as in, when running git status says on branch xyz . In this case , Git will automatically change the branch name so that it points, not to the commit that it pointed to just a moment ago, but instead, to the new commit you just made.

Hence, if you're on branch xyz , and it points to commit 1234567 , and you make a new commit, the name xyz no longer points to 1234567 . Instead, it points to some new commit, maybe fedcba9 for instance. The new commit you just made, meanwhile, points back to commit 1234567 . This is how branches grow.

Something special that any name does, for any commit, is to make sure that both you and Git can find that commit easily. Having found that commit, you can have Git find that commit's parent. Having found the parent, you can have Git find the grandparent. Having found that commit, you can have Git keep going through history.

This is the history in the repository, and it's formed by these parent linkages between commits. Branch names point to the tip commit of any given branch, and starting at that commit, you—and Git—can work your way back in time to every previous commit. Every commit you visit, as you do this "walk back through time", is reachable from the branch tip, via this walk process.

When you run git merge , you can ¹ make Git create a new commit that has not one but two parents. These commits are called merge commits , and when you (or Git) do the walking through history, you (or Git) will visit both parents, and their grandparents and so on. All of these commits are reachable from the branch tip that got you to this merge commit.

This reachability has the side effect of making sure that Git does not remove the commits. All reachable commits are permanent. All commits are read-only. So whatever is in history, reachable from all branch tips, is stored forever: read-only and permanent, in the form of commits.

Once you merge branch feature into mainline , you can delete the name feature , because the name mainline either points to, or eventually reaches, the merge commit that points to the commits that were, earlier, only reachable from feature . So after merging, you can delete a name. But there's no need to merge: you can keep the name, which keeps the commits.

Or, if you have determined that there's no need for these commits ever, in the future, you can delete the name. This makes the commits unreachable —well, by that name at least; there might still be some other name(s) that reach them. If the commits are truly unreachable—if they have no branch name that finds them, no tag name that finds them, and no other name (such as refs/stash ) that eventually allows Git to find them from a name—then at some point soon, when git gc runs, Git will actually remove those commits for real.

Hence, the answer is no: you don't have to merge a branch. As long as you keep the name around, the name keeps all those commits preserved. If you have merged the branch, some other name is now also keeping those commits preserved, so you can (but do not have to) delete the branch-name; but as long as you keep the branch name around, the commits stick around, whether merged or not. Those commits are reachable from the tip of the branch: something Git sometimes calls contained in the branch. (See git branch --contains .)

---

¹ The git merge command does not always make merge commits. Sometimes, it does a "fast forward", which is not really a merge. You can tell it to --squash , which eventually makes an ordinary (non-merge) commit, too. So git merge only makes merge commits sometimes .

Answer 2

不会。使用发行分支非常普遍：例如，对于每个主要发行版，您都可以在其发行分支上进行错误修复，以创建新的子发行版本，而同时在开发分支上并行完成主要开发。