内容完全不同的 Git 分支

Git branches with completely different content

提问by Henrik Paul

Since Git has the ability to keep track (and keep it clean) of branches with completely different content from each other, in the same repository, some projects (like Git itself) have started to make use of it.

由于 Git 能够跟踪（并保持干净）内容完全不同的分支，因此在同一个存储库中，一些项目（如 Git 本身）已经开始使用它。

Git, for instance, uses one branch for the code itself, while keeping its documentation in a separate branch. Same repo, just different branches.

例如，Git 为代码本身使用一个分支，同时将其文档保存在一个单独的分支中。相同的回购，只是不同的分支。

It might just be me, coming from a SVN background, but I find it confusing to have 'nothing in common' in those branches. Development/staging/production branches; those I understand. Branches for incomplete features; sure, I'm doing those too. Heck, have your documentation with one branch per language. But no files in common?

可能只是我，来自 SVN 背景，但我发现在这些分支中“没有共同点”令人困惑。开发/暂存/生产分支；我理解的那些。不完整特征的分支；当然，我也在做这些。哎呀，让您的文档每个语言都有一个分支。但是没有共同的文件？

Is this just (perhaps an underused and/or undermarketed) feature in Git, that everyone should embrace and get used to, or a possibly dangerous misuse by someone being lazy of not differentiating two aspects of the same project enough?

这只是 Git 中的（可能是未充分利用和/或市场不足的）功能，每个人都应该接受并习惯，还是由于懒惰而没有充分区分同一项目的两个方面的人可能造成的危险误用？

采纳答案by jrockway

I personally would not store different content in different branches; in the case of docs and code, I would just make a myproject.git and a myproject-docs.git (and sub-module the docs into the code if it was necessary for the build process).

我个人不会在不同的分支中存储不同的内容；在文档和代码的情况下，我只会制作一个 myproject.git 和一个 myproject-docs.git（如果构建过程需要，将文档分模块到代码中）。

On the other hand, nothing bad will happen if you do this. Git is not going to tell you what to do, so you are free to make your own decision on how you want to use it. So to answer your question, it's neither a killer feature, nor something that will bowl you over if you are not careful. It's just how someone choses to use it.

另一方面，如果你这样做，不会有什么不好的事情发生。Git 不会告诉您该做什么，因此您可以自由决定如何使用它。因此，回答您的问题，它既不是杀手级功能，也不是如果您不小心就会让您失望的东西。这只是某人选择使用它的方式。

回答by Paul

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).

Git 跟踪项目内（文本）文件中的协调更改，因此它不知道也不关心分支是否可合并。在 Git 存储库中拥有独立的分支类似于在 Subversion 存储库中拥有独立的项目，这是一种常见的做法（因为 svn 的开销）。

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.

因为 Git 的数据结构与 SVN 的非常不同，你可以用它们做不同的事情。在 SVN 中，一个特性分支有点不寻常，一个不经常合并到主干的特性分支可能是“难闻的味道”，表明程序员已经“变黑”并且正在创建可能永远无法实现的代码集成到项目中。在 Git 中，功能分支是一个非常安全和合理的工作流程。

So they can be used in different ways because Git is not SVNeven though both have repositories and branches and commits, and serve the same general function of source control.

所以它们可以以不同的方式使用，因为Git 不是 SVN，即使它们都有存储库、分支和提交，并且提供相同的源代码控制一般功能。

As I got more experience of Git, what had been weirdjust became different. Then I got curious about what I could do with that different tool.

随着我对 Git 的体验越来越多，原本奇怪的东西变得不同了。然后我很好奇我可以用这个不同的工具做什么。

回答by T.E.D.

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.

我想说这更像是一种懒惰的解决方法，因为 Git 目前无法处理将多个项目存储在同一个存储库中的事实。你可以做到，但没有办法只拉下你想要的。

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.

我说“懒惰”，因为当 git 开发人员自己发现需要它（用于存储文档）时，添加该功能并不会太难。由于他们使用了这个奇怪的分支黑客，他们为其他人解决问题的动力已经显着减弱。

回答by Andrew Burns

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).

Git 显然是一个社区 OSS 项目，因此将文档放在（相同的）存储库中以便每个人都可以获取它们（对我而言）。

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.

其他人可能希望将它们全部放在一起。我认为您只需要了解它的含义（记住每个人都有一个完整的存储库副本）并为您的项目选择最佳选项。

回答by foxxtrot

The benefit to doing this, is that it's possible to pull only the docs branch if that's all you're interested in. Like jrockway said, you can do this using another repository and submoduling if necessary, but with this ability to create a 'naked' branch, you have the option not to.

这样做的好处是，如果这就是您感兴趣的所有内容，则可以仅拉取 docs 分支。就像 jrockway 所说，您可以使用另一个存储库并在必要时使用子模块来完成此操作，但是有了这种创建“裸”的能力' 分支，您可以选择不这样做。

Personally, I'm still on the fence about this. I understand why it could be beneficial, but I'm not wholly convinced it's the best way to go.

就我个人而言，我仍然对此持观望态度。我理解为什么它可能是有益的，但我并不完全相信这是最好的方法。

回答by Otto

It's a little weird when you're used to the Subversion model of presenting the tree to users, but once you get used to the model it's a lot less confusing.

当您习惯将树呈现给用户的 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.

git 存储库只是一棵对象树，用于解释如何将目录从一种状态转换为另一种状态。这些对象有一个父对象。有些对象有两个（或更多）父对象；合并。有些对象没有父对象；最初的提交。

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.

据我了解，在内部，Subversion 的模型是相似的，但没有合并来自何处的概念。这些只是带有一个方便的命令 ( svn merge) 的新提交，用于获取其他两个提交之间差异的补丁。

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.

我实际上经常使用此功能来管理从不同主机上的同一目录启动的配置文件，例如/etc/apache2. 这就像在说，“这是这个东西的另一个开始，但它已经被放弃了”。它允许我在覆盖某些文件之前隐藏它们的状态，但不必担心它们是否合并正确，或者甚至与 master 分支完全相关。

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.

在 Subversion 中，我必须将该备份存放在某个不相关的地方（某处的 zip 文件）或存储库中的子目录中。另外，在 subversion 中，如果我在树的当前视图中删除对这些文件的任何引用，则很难再次找到它们。