2

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

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

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

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

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

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

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

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

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

4

3 回答 3

3

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

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

于 2013-01-31T12:20:04.307 回答
2

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

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

看看git 主页上提到的书。

于 2013-01-31T12:20:40.510 回答
1

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

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

git merge mybranch --no-commit
rm -rf **docu-dir**
git add -A
git commit
于 2013-01-31T11:09:54.093 回答