由于 Git 有能力跟踪（并保持干净）具有完全不同内容的分支，因此在同一个存储库中，一些项目（如 Git 本身）已经开始使用它。
例如，Git 为代码本身使用一个分支，同时将其文档保存在一个单独的分支中。相同的仓库，只是不同的分支。
可能只是我，来自 SVN 背景，但我发现在这些分支中“没有共同点”令人困惑。开发/分期/生产分支；那些我理解的。不完整特征的分支；当然，我也在做这些。哎呀，每种语言都有一个分支的文档。但是没有共同的文件？
这只是 Git 中的（可能是一个未充分利用和/或市场不足的）功能，每个人都应该接受并习惯，或者可能是由于懒惰而没有充分区分同一项目的两个方面的人误用？
我个人不会在不同的分支中存储不同的内容；在文档和代码的情况下，我只会制作一个 myproject.git 和一个 myproject-docs.git （如果构建过程需要，则将文档子模块到代码中）。
另一方面，如果你这样做，不会发生任何不好的事情。Git 不会告诉您该做什么，因此您可以自由决定如何使用它。因此，要回答您的问题，它既不是杀手级功能，也不是如果您不小心就会让您失望的东西。这只是某人选择使用它的方式。
Git tracks coordinated changes in (text) files within a project, so it doesn't know or care whether branches are mergable or not. Having independent branches in a Git repo is similar to having independent projects in a Subversion repo, which is a common practice (because of svn's overhead).
Because Git's data structure is very different than SVN's, you can do different things with them. In SVN a feature branch is somewhat unusual, and a feature branch which is not often merged to the trunk might be a "bad smell", a sign that the programmer has "gone dark" and is creating code that may never be able to be integrated into the project. In Git, a feature branch is a perfectly safe and sensible workflow.
So they can be used in different ways because Git is not SVN even though both have repositories and branches and commits, and serve the same general function of source control.
As I got more experience of Git, what had been weird just became different. Then I got curious about what I could do with that different tool.
I'd say it's more like a lazy workaround for the fact that Git can't currently handle having multiple projects stored in the same repository. You can do it, but there's no way to pull down just the one you want.
I say "lazy", because it wouldn't have been too horribly tough to add the feature when the git developers themselves discovered a need for it (for storing docs). Since they used this weird branch hack, their incentive to fix the issue for everyone else has abated significanly.
这样做的好处是，如果您只对 docs 分支感兴趣，则可以只拉取它。就像 jrockway 所说，您可以使用另一个存储库并在必要时进行子模块来执行此操作，但具有创建“裸”的能力' 分支，你可以选择不这样做。
就个人而言，我仍然对此持观望态度。我理解为什么它可能是有益的，但我并不完全相信这是最好的方法。
I think it depends on what your project is.
Git is obviously a community OSS project so having the docs in the (same) repository so everyone gets them makes sense (to me).
On the other hand I would not store the docs for my projects at work as I would rarley edit them except on 'let's update the docs' type of ticket. At work I don't want my docs intermingled with my source, I just want the source (typical programmer view i know).
Others may want them all-together. I think you just need to realize what it means (remember everyone has a full copy of the repository) and pick the best option for your project.
当您习惯了将树呈现给用户的 Subversion 模型时，这有点奇怪，但是一旦您习惯了该模型，它就不会那么混乱了。
A git repository is just a tree of objects that explain how to transform a directory from one state to another. Those objects have a parent. Some objects have two (or more) parents; merges. Some objects have no parent; the initial commit.
As I understand it, internally, Subversion's model is similar minus the concept of where merges came from. Those are just new commits with a handy command (svn merge) for getting a patch of the differences between two other commits.
I actually use this feature rather often to manage config files that started from the same directory on separate hosts, like /etc/apache2. It's like saying, "this is the alternate start of this stuff, but it's been abandoned". It allows me to stash the state of some files before I overwrite them, but without having to worry about whether they merge right, or are even related to the master branch at all.
In Subversion I'd have to stow that backup in some un-related place (zip file somewhere) or in a subdirectory in the repository. Plus, in subversion, if I delete any reference to those files in the current view of the tree it becomes very hard to find them again.