这些辅助文件是否应该受 Git 版本控制？

Question

我决定开始为我的 C++ 项目使用 Git 版本控制系统。我是版本控制的新手。对于主干来说，事情很简单，我只提交我拥有的所有项目版本。我将每个版本保存为一个单独的文件夹，因为我知道我很快就会使用 Git。但是我的分支遇到了问题。

在开发的某个阶段，我决定在一个分支中开发一个类。如果没有版本控制，我不得不使用“手动”分支。我将该类的最新头文件和源文件复制到一个单独的文件夹并开始在那里工作。我在那里制作了几个版本以同时使用。根据计划，一个版本是该类的第一个原型（为此我制作了“分支”）。然后我添加了另一个文件，我在其中复制了第一个文件，但删除了似乎不需要的东西。这样我就有了 2 个版本，一个包含我所有的想法和功能，另一个只包含我在代码中真正使用的内容，没有目前未使用的内容。

但后来我添加了更多。随着开发的进行，我认为将这个类作为模板可能是个好主意。所以我添加了第三个版本，和第二个一样，但是现在使用多态实现的一些功能是使用模板实现的。而且我还不能说哪个版本最好，因为现在说还为时过早，所以我想把这三个放在一起。

然后我制作了另一个特殊文件：第三版头文件的副本，其中每一行可以标记或不标记。已标记表示我使用了该特定方法或者我确定它很快就会使用，否则该行不会被标记。

然后，过了一段时间，我开始了一个新的分支。对于那个分支，我需要在第一个分支中开发的那个类的新版本。所以我只是将其中一个版本复制到新分支的文件夹并开始在那里工作。现在我又有了某种辅助文件：我有 2 个文件，一个用来删除我使用的类方法，另一个用来写我需要的新方法。

现在我想开始使用 Git，我想知道：对于所有项目的文本文件、计划、图表等，很明显 - 我将它们保存在 Git 存储库之外。每当需要协作编辑时，我都可以建立一个 wiki 或类似的东西。但是对于同一个头文件的所有副本，以及那些辅助的“标记”文件，我该怎么处理它们呢？我的意思是，我可以将它们全部放在一个分支中，但是当我将一个分支合并到主干时会发生什么？我不想拥有所有这些副本、版本和列表，只是我制作的最后一个类文件。

一方面，这些是编码时使用的 C++ 源文件。另一方面，它们不是软件包的纯源代码的一部分，它们只是在我工作时帮助我，但永远不会被编译，因为最后只有我选择合并的类的最终版本，并且所有其他 aux 文件、列表等仅供参考。

最好的做法是什么？ 感谢您阅读我的长篇故事:)

编辑：这是我个人计算机上的本地存储库

Answer 1

你描述的是分支的正常使用：你有你的主分支（“官方”，如果它在哪里）和一个开发新功能的分支（它实际上不必住在一个单独的目录中，如果我理解正确）。定期将功能分支与主分支同步，方法是将其重新定位在主分支上或合并其更改。反过来，您可以拥有从属分支，您可以在其中尝试开发功能的方法，并针对该功能进行处理分支就像对主人的一种尊重。但在这种情况下，你必须在每次 rebase 时小心。

您应该在存储库中保留任何不容易重新创建的数据，无论是源代码、文档还是设计草图。可以重新创建的东西（目标代码，自动格式化的文档，...）应该被排除在外（任何更改都会产生要签入的差异）。您的存储库（尤其是未发布的分支）是您自己的工作区，可以随心所欲。

看看git homepage提到的书。

Answer 2

始终将文档保存在与源代码相同的存储库中。如果你不这样做，你的文档就会腐烂。这是因为文档是针对您的软件的某个版本编写的，因此它必须以与软件开发相同的方式进行开发。

如果您的文档是自动生成或编译成另一种格式的，请只提交源数据、makefile 和生成器配置，就像处理源代码一样。

Answer 3

嗯，这显然是文档而不是源代码，因此您应该将其与源代码分开。由于您的文档似乎依赖于分支，您仍应将其检入到 repo 中，但在单独的 doc 目录中。

关于合并：合并的工作方式最终取决于您。 Git 只是有一个默认的合并策略，这是大多数人大部分时间想要的。但是如果你说合并到主分支应该只带代码而不是文档，那很好。就这样合并：

git merge mybranch --no-commit
rm -rf **docu-dir**
git add -A
git commit