Git分支具有完全不同的内容

我个人不会在不同的分支中存储不同的内容;对于文档和代码,我只需要创建一个myproject.git和一个myproject-docs.git(如果构建过程需要,还可以将文档子模块化为代码)。

另一方面,如果你这样做,不会有什么不好的事情发生。Git不会告诉你该怎么做,所以你可以自由地决定如何使用它。所以回答你的问题,它既不是一个杀手级的功能,也不是如果你不小心就会让你崩溃的东西。这只是人们选择使用它的方式。

Git跟踪项目中(文本)文件的协调变化,因此它不知道或关心分支是否可交易。在Git仓库中拥有独立的分支类似于在Subversion仓库中拥有单独的项目,这是一种常见的做法(因为svn的开销)。

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

因此,它们可以以不同的方式使用,因为 Git不是SVN 尽管两者都有存储库、分支和提交,并且提供相同的源代码控制通用功能。

随着我对Git有了更多的经验 奇怪的 刚刚成为 不同的 然后我很好奇我能用那个不同的工具做什么。

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

我说“懒惰”,因为当git开发人员自己发现需要它(用于存储文档)时,添加该功能不会太难。由于他们使用了这种奇怪的分支黑客,他们为其他人解决问题的动机大大减弱了。

这样做的好处是,如果你只感兴趣的话,可以只提取文档分支。就像jrockway说的那样,你可以使用另一个存储库并在必要时进行子建模来实现这一点,但有了创建“裸”分支的能力,你可以选择不这样做。

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

我认为这取决于你的项目是什么。

Git显然是一个社区OSS项目,因此将文档放在(同一)存储库中,这样每个人都能得到它们(对我来说)是有意义的。

另一方面,我不会在工作中存储项目的文档,因为除了“让我们更新文档”类型的工单外,我会随意编辑它们。在工作中,我不希望我的文档与源代码混杂在一起,我只想要源代码(我所知道的典型程序员视图)。

其他人可能希望他们都在一起。我认为你只需要意识到这意味着什么(记住每个人都有一个完整的存储库副本),并为你的项目选择最佳选项。

当你习惯了向用户呈现树的Subversion模型时,这有点奇怪,但一旦你习惯了这个模型,它就不会那么令人困惑了。

git存储库只是一个对象树,它解释了如何将目录从一种状态转换为另一种状态。这些对象有父对象。有些对象有两个(或更多)父对象;合并。有些对象没有父对象;最初的承诺。

据我所知,在内部,Subversion的模型是相似的,除了合并来源的概念。这些只是带有方便命令的新提交( svn merge )用于获取其他两个提交之间的差异补丁。

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

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