Git – 在单个 Git 存储库中放置多个 Visual Studio 解决方案

Mark Pelf

5.00/5 (3投票s)

2022年8月15日

CPOL

5分钟阅读

18739

如何创建包含多个 VS 解决方案的单个 Git 存储库

1. 问题

我遇到的问题是，我想在 GitHub 上发布我的一篇文章的源代码，以便用户可以轻松下载。问题是我一篇文章的源代码包含四个 Visual Studio C# 解决方案。我不想将解决方案合并为一个，这样做也不明智，因为多个 VS 解决方案包含同名项目，这正是我在文章中所解释的代码演变过程。我希望用户能够轻松地在“一次克隆”中获取文章的全部源代码。这是我的文件夹结构

我打开了 VS2022，然后就卡住了。VS2022 假定 Git 存储库是针对 VS 解决方案的。而我想将多个 VS C# 解决方案打包到一个存储库中。现在怎么办？

2. 检查技术：Git Submodule 或 Git Subtree

有一会儿，我以为像 Submodule 或 Subtree 这样的 Git 技术会有帮助。但是，在仔细研究之后，它们并不适合这样的目的。我不想共享库代码，而是想一次性从 GitHub 下载所有内容。我发现不了如何在 Git 中创建一个包含多个存储库的“工作区”，并从“git clone”的角度将它们视为一个整体。

3. 解决方案 - 在 SourceTree 中创建单个存储库

我发现我能做的最好的事情是创建一个位于更高级别目录的 Git 存储库，其中包含我拥有的所有四个解决方案。这样，我将在一个 Git 存储库中获得四个解决方案。我立刻就知道，我将会有针对每个存储库的分支，而不是针对每个 VS 解决方案的分支。

3.1. 创建存储库

我检查了 VS2022 中的 Git 选项，发现它们功能有限，所以我需要另一个 Git 工具。我决定使用 Sourcetree 创建一个高级目录存储库。

暂时不要提交任何东西！我们首先需要设置 .gitignore 文件。如果你不先设置 .gitignore 文件，你的所有项目文件，如二进制文件和中间生成文件，都将被提交到存储库，而我们不希望那样。

3.2. 设置 .gitignore

为了模拟 VS2022 的工作方式，我将 VS2022 生成的两个文件 .gitignore 和 .gitattributes 复制到了我的存储库根目录，这两个文件是在其他 C# 项目中创建的，然后将它们提交了。

我们之所以手动进行此操作，是因为我们没有使用 VS2022 来创建 Git 存储库，在这种情况下，VS2022 会根据你选择的项目类型自动创建 .gitignore。由于我们通过 SourceTree 承担了创建存储库的责任，因此我们有责任创建正确的 .gitignore 文件。

3.3. 提交 C# VS 解决方案文件

然后，我将所有 Visual Studio 解决方案文件提交到存储库。因为设置了 .gitignore，所以提交会忽略二进制文件等。

3.4. 创建 GitHub 存储库

然后，我在 GitHub 上创建了我的远程存储库账户，并推送了文件。

你可以在远程端浏览存储库，并验证没有二进制文件或其他项目文件被提交到存储库。如果发生这种情况，说明你的 .gitignore 文件有问题。

3.5. 合并无法合并的分支

我现在遇到的问题，也就是刚刚发生的，但我确定这还会再次发生在我身上以及其他人身上，那就是我完成了两个分支：main 和 master。“main”分支是 GitHub 默认创建的，并且有一个 readme 文件。“master”分支是 SourceTree 默认创建的，并且我的代码（我的四个 VS 解决方案）在其中。

好的，这里不需要两个分支，让我们将它们合并然后去掉一个。我们保留 GitHub 的默认分支“main”，删除“master”。

但是当你尝试合并这两个分支时会有一个问题

它会给出一个错误：“fatal: refusing to merge unrelated histories”（致命错误：拒绝合并不相关的历史记录）。

由于我们的两个分支没有共同的祖先提交，SourceTree 认为我们正在做错误的事情。但我们知道我们是对的，并且想要强制执行。

我查了一下，在 [1] 中提到，你无法从 SourceTree GUI 中解决这个问题。所以，我们需要 GitBash 来运行命令行 Git 命令。问题的解释和说明在 [2] 中。
我们需要运行“git merge <branch-name> --allow-unrelated-histories”

所以，你可以从 SourceTree（Terminal 按钮）打开 GitBash，然后执行该命令。系统会提示你在单独的文本编辑器中输入提交注释。然后合并将继续。

合并后的分支现在看起来是这样的

将你的更改推送到 GitHub，并验证“main”分支现在包含所有文件。

3.6. 删除不需要的分支

现在你可以在本地的 SourceTree 和远程的 GitHub 上删除“master”分支。它现在看起来是这样的。分支历史被保留，但没有“master”分支。

4. 在 VS2022 中验证解决方案

现在是时候看看 VS2022 端的情况了。首先，我们获取克隆 URL

然后，我们在 VS2022 中克隆存储库。

这是我们得到的结果。我们一次性获得了所有四个解决方案。

通过点击某个解决方案，我们进入该解决方案

通过点击上面的按钮，我们可以返回到所有四个解决方案的视图。

这就是我们想要的。唯一的问题是所有四个解决方案都在同一个分支上，即“main”分支。也许你能做的最好的事情是为每个解决方案创建一个单独的分支，并在那里检查代码更改。

5. 结论

我的大部分项目都在 TFS 中，所以我很惊讶强大的 VS2022 竟然轻易地被将多个解决方案放入单个 Git 存储库的简单想法所击败。没有像 SourceTree 这样的外部工具或命令行 GitBash，这是不可能做到的。

关于 Git，我在想，它不是一个开源项目吗？它能被升级，使其拥有一个包含多个 Git 存储库的“工作区”的概念吗？这将使我们免于现在所有四个解决方案都在同一分支上的糟糕境地。链接到 Git 社区的适当链接似乎是 [3]、[4]... 对于有时间的人来说。

6. 参考文献

7. 历史

2022 年 8 月 15 日：初始版本