由于Git具有在同一代码库中跟踪（并使其保持清洁）具有完全不同内容的分支的能力，因此一些项目（例如Git本身）开始利用它。
例如，Git将代码本身放在一个分支中，同时将文档存储在另一个分支中。同一代码库，只是不同的分支。
也许只有我这样从SVN背景来看，但我认为将'没有共同点'的内容放在那些分支中令人困惑。开发/暂存/生产分支；我理解这些。未完成功能的分支；当然，我也在做这些。甚至每种语言都有一个文档分支。但是没有共同文件？
这是Git中可能被大家应该拥抱并且应该习惯的（或许很少使用或者市场推广不足的）特性，还是某个人懒得区分同一项目的两个方面而可能发生危险的错误使用方法？
个人而言，我不会在不同的分支中存储不同的内容；对于文档和代码，我只会创建一个 myproject.git 和一个 myproject-docs.git（如果需要构建过程中子模块化文档）。
另一方面，如果你这么做也不会有什么问题。Git 不会告诉你应该怎么做，因此你可以自由决定如何使用它。因此回答你的问题，这既不是杀手级功能，也不是如果不小心就会出问题的东西。这只是某个人选择使用它的方式。
git reset --hard 即可。 - OttoGit会跟踪项目中（文本）文件的协调更改，因此它不知道也不关心分支是否可以合并。在Git repo中拥有独立的分支类似于在Subversion repo中拥有独立的项目，这是一种常见的做法（因为svn的开销较大）。
由于Git的数据结构与SVN的结构非常不同，因此您可以用它们做不同的事情。在SVN中，特性分支有些不寻常，一个很少合并到主干的特性分支可能是一个"坏味道"，表明程序员已经"失去联系"，正在创建可能永远无法集成到项目中的代码。在Git中，特性分支是完全安全和明智的工作流程。
所以它们可以用不同的方式使用，因为 Git不是SVN，尽管两者都具有存储库、分支和提交，并提供源代码控制的相同一般功能。
随着我对Git的经验越来越丰富，曾经的奇怪变得不同了。接着我开始好奇我能用这个不同的工具做什么。
我认为这更像是一种懒惰的变通方式，因为Git目前无法处理在同一个存储库中存储多个项目的情况。虽然你可以这样做，但无法只拉取你需要的那个项目。
我说“懒惰”，是因为当Git开发人员自己发现需要该功能（用于存储文档）时，添加该功能并不会太困难。由于他们使用了这种奇怪的分支技巧，他们减少了为其他所有人修复此问题的动力。
这样做的好处是，如果你只关心文档分支，那么就可以只拉取文档分支。像jrockway所说的那样，如果必要的话，你可以使用另一个存储库和子模块来实现这一点，但是有了创建“裸”分支的能力，你就有了选择。
就我个人而言，我对此还没有完全确定。我理解它可能会有益，但我并不完全相信这是最好的方式。
当你习惯于Subversion向用户展示树形结构的模式时，使用Git可能会有点奇怪，但一旦你习惯了这种模式，就会少很多困惑。
一个Git仓库只是由对象组成的树形结构，这些对象解释了如何将目录从一个状态转换为另一个状态。这些对象都有一个父对象。一些对象有两个或更多的父对象；这就是合并。有些对象没有父对象；这就是初始提交。
据我所知，内部而言，Subversion的模型类似于Git，只是没有合并的概念。那些只是新的提交，有一个方便的命令（svn merge）可以获取两个其他提交之间差异的补丁。
我经常使用这个功能来管理从不同主机的相同目录开始的配置文件，比如/etc/apache2。它就像在说，“这是这些东西的备用起点，但已经被放弃了”。它允许我在覆盖这些文件之前存储一些文件的状态，但无需担心它们是否正确合并，甚至是否与主分支相关。
在Subversion中，我必须将备份存放在某个不相关的地方（例如zip文件），或者在仓库的子目录中。此外，在Subversion中，如果我删除了树形结构中对这些文件的任何引用，那么很难再次找到它们。
每个版本都有自己的价格。
因此，对于销售您开发的内容，这是一种很好的跟踪方式。
或者您可以将每个分支视为其他人正在更新主分支的克隆，这是传统的方式。似乎是您习惯的方式。 使用某物的方法不止一种，请向任何急诊室医生询问下肢X光片。 记住，有意愿时，请让路哈哈...
祝大家一切顺利。