我决定开始为我的C ++项目使用Git版本控制系统。我是版本控制的新手。对于主干，事情很简单，我只提交我拥有的所有项目版本。我将每个版本保存为一个单独的文件夹，因为我知道我很快就会使用Git。但我的分支机构遇到了问题。
在开发的某个阶段，我决定我想在分支中开发一个类。没有版本控制，我不得不使用make“手动”分支。我将该类的最新头文件和源文件复制到一个单独的文件夹并开始在那里工作。我在那里制作了几个版本同时工作。根据计划，一个版本是该类的第一个原型（我为此制作了“分支”）。然后我添加了另一个文件，其中我复制了第一个但删除了似乎没有必要的东西。这样我有两个版本，一个带有我所有的想法和功能，另一个带有我在代码中真正使用的版本，没有当前没有使用的版本。
但后来我添加了更多。随着开发的进行，我认为将该类作为模板可能是一个好主意。所以我添加了第三个版本，就像第二个版本一样，但现在使用多态实现的一些功能是使用模板实现的。我还不知道哪个版本是最好的，因为现在说太早，所以我希望将所有3个版本放在一起。
然后我创建了另一个特殊文件：第三个版本头文件的副本，其中每行可以标记或不标记。标记表示我使用的是特定方法，或者我确定它很快会被使用，否则该行不会被标记。
然后，一段时间后，我开始了一个新的分支。对于那个分支，我需要在第一个分支中开发的该类的新版本。所以我只是将其中一个版本复制到新分支的文件夹中并开始在那里工作。现在我又有了一些辅助文件：我有两个文件，一个是我删除我使用的类方法，另一个是我编写新方法我需要的文件。
现在我想开始使用Git，我想知道：对于所有项目的文本文件，计划，图表等，很明显 - 我将它们置于Git仓库之外。每当需要协作编辑时，我都可以设置一个wiki或类似的东西。但对于同一个头文件的所有副本，以及那些辅助的“标记”文件，我该如何处理它们？我的意思是，将它们全部放在分支中我很好，但是当我将分支合并到主干时会发生什么？我不想拥有所有这些副本，版本和列表，只是我制作的最后一个类文件。
一方面，这些是编码时使用的C ++源文件。另一方面，它们不是软件包的纯源代码的一部分，它们只是在我工作时帮助我，但永远不会被编译，因为最后只有我选择合并的类的最终版本，以及所有其他辅助文件，列表等仅供参考。
最好的办法是什么？ 感谢您阅读我的长篇故事：）
编辑：这是我个人电脑上的本地回购答案 0 :(得分：3)
始终将文档保存在与源代码相同的存储库中。如果不这样做，您的文档将会腐烂。因为文档会在某些版本的软件中重新编写，所以它必须以与软件开发相同的方式开发。
如果您的文档是自动生成或编译成另一种格式，则只提交源数据，makefile和生成器配置，就像使用源代码一样。
答案 1 :(得分：2)
你所描述的是分支的正常使用：你有你的主分支（“官方”，如果它在哪里）和一个分支来开发一个新功能（它实际上不必住在一个单独的目录中，如果我理解你了。定期将功能分支与主服务器同步，方法是在主服务器上对其进行重新定位或合并其更改。反过来，您可以使用从属分支，在其中尝试开发功能的方法，针对功能进行处理分支就像那个对主人的尊重。但是在那种情况下，你必须小心每一次重新安装。
您应该保留在存储库中不易重新创建的任何数据，无论是源代码，文档还是设计草图。应该保留可以重新创建的东西（目标代码，自动格式化文档......）（任何更改都会产生差异以便检入）。您的存储库（特别是未发布的分支）是您自己的工作空间，它可能是您喜欢的所有混乱。
看一下git homepage中提到的那本书。
答案 2 :(得分：1)
嗯，这显然是文档而不是源代码，因此您应该将其与源代码分开。由于您的文档似乎依赖于分支，您仍应将其检入到repo中，但是在单独的doc目录中。
关于合并：合并的工作方式最终取决于您。 Git只有一个默认的合并策略，这是大多数人大多数时候都想要的。但是如果你说合并到主分支应该只带来代码而不是文档，那就没关系了。只需合并：
git merge mybranch --no-commit
rm -rf **docu-dir**
git add -A
git commit