Git应该用于文档和项目管理吗？代码应该放在单独的存储库中吗？

我正在为一个小组项目启动一个Git存储库。将文档与代码存储在同一Git存储库中是否有意义-似乎这与git修订流程的本质冲突。

这是我的问题的摘要：

• 如果将代码和文档都检入同一个存储库，Git修订样式会不会引起混淆？有经验吗？

• Git非常适合文档版本控制吗？

• 我不是在问总体上是否应该将修订控制系统用于文档编制，而是应该使用。

感谢您到目前为止的反馈！

我们始终将文档存储在SVN中。实际上，我们的整个用户手册都是用LaTeX编写的，并存储在SVN中。我们之所以选择LaTeX，是因为它是基于文本的语言，并且易于显示逐行差异。

必要时，我们还会存储一些非文本格式的文件，例如Microsoft Office .doc文件，电子表格，.zip文件等...，但是当您看不到增量文件时，RCS的某些好处就会丢失差异

关键确实是要确保您的文档井井有条，以便人们在需要时可以找到（和更新）文档（和源代码）。

好吧，这取决于您使用哪种格式的文档。如果它是基于文本的东西，那一切都很好。

Git还可以存储二进制内容，并且您可以跟踪修订，但是diff输出没有意义。

也可以将文档存储在代码本身中，例如perldoc pod，java也为此提供了一些格式/注释。

我无法想象为什么您认为使用git或任何其他版本控制系统进行文档编制可能会出现问题。就像源代码一样，文档应具有完整的历史记录，并能够在必要时恢复为较早版本。版本控制系统是完美的选择。

显然，使用某种版本控制系统来存储文档是不费吹灰之力的。问题中更有趣的部分是将文档存储在SAME位置作为源代码是否是个好主意？这里可能的问题是，在这种情况下，可能很难为代码和文档设置不同的访问权限。而且在许多业务案例中，人们将需要访问文档而不是源代码，例如市场营销或BA部门。

在我工作的公司中，我们将文档放入SVN中。但是，在发生了几次冲突并需要共享后，我们决定将其移至Mediawiki。

起初是追踪，之后转移到Mediawiki，因为它更易于使用...

SVN的主要问题是我们拥有SVN授权系统的共享原因。

• 在存储库中不仅仅是源代码是一件好事。

  它将所有资源组合在一起，并将项目变成一个凝聚的，集中的实体，而不是分散的文件集合。贡献者/员工知道在哪里找到所有内容，而不是发送“我在哪里更改功能x的文档？” 电子邮件。

  您将需要使事情井井有条。对分离系统src从images从docs。您始终可以将a添加.gitignore到目录中以保持存储库和历史记录的清洁。由于Git提交基于文件，*您可以根据需要将源代码更改与文档更改脱钩。

• 正如其他人所说，Git只要基于文本，就非常适合文档版本控制。

• 我完全同意; 文档应与代码一起进行版本控制。

我的信誉来自于成为GitHub用户并致力于一个项目并探索许多其他项目。以我的经验，一个完整，统一的项目很容易从一个半失误的项目中分辨出来。我尽可能将所有项目都包含在单个目录中。

我来到这里时遇到了类似的问题。我们来自SVN环境，在这里，将与项目相关的所有材料都保存在同一存储库中基本上是一件容易的事。由于SVN的性质，您可以轻松检出存储库的某些部分，因此，如果您只需要源代码（例如，网站部署），那就没问题了。

使用Git，情况就不同了。签出始终在根级别，因此，如果要将所有内容放入同一存储库，则最终将始终具有相同的目录结构。我遇到的一种方法是将所有内容放在单独的分支中，即，您具有代码分支（通常是您的常规master，develop等分支）和doc分支，其具有自己的单独目录结构。我不确定这是否是最好的主意，但这是一个建议，可以绕开我认为是您的问题基础的问题。

我使用内部文档的Wiki ...获取修订版以及突出的访问权限/易于编辑。如果文档不同步，请立即进行更新。对于最终用户文档，请考虑使用Madcap Flare之类的专业工具。他们使用XML方言来共享，编写和转换文档。

在代码中，思想通常是逐行分开的。我倾向于用换行符写文档。当我提交这些文件时，行长为整段。读起来不是很有用git diff。这就是我在Google搜索并找到此页面时试图解决的问题。感谢Arne Hartherz向我介绍了git diff --word-diff。您可能会更喜欢git diff --color-words。