It is not possible from VS2022 to create a single Git repository to contain multiple VS solutions, so we resourced to SourceTree and achieved the goal. Technical details are in the article.
1. Problem
The problem I had was that I wanted to post on GitHub source code from one of my articles so that users can easily download it. Problem was that the source code for one article consists of four Visual Studio C# solutions. I didn’t want to merge solutions into one, and neither would that be smart, since multiple VS solutions contained a project with the same name, that is the evolution of code as I was explaining in the article. I wanted the user to easily get the whole source code for the article in “one clone”. Here is my folder structure:
I opened VS2022 and I was stuck. VS2022 implies that the Git repository is per VS solution. And I have multiple VS C# solutions that I want to package into one repository. What now?
2. Checking Technology: Git Submodule or Git Subtree
For a moment, I thought that part of Git technology like Submodule or Subtree would help. But, after carefully examining them, they are not meant for such a purpose. I do not want to share a library code and want to get everything down from GitHub in one shot. I do not see that you can in Git create “a workplace” that would contain several repositories and treat them as one from the perspective of a “git clone”.
3. Solution - Creating a Single repository in SourceTree
I figured out that the best I can do is create Git repository on a higher lever directory, containing all the four solutions I had. That way, I will get four solutions in one Git repository. I knew immediately, that I will have branches per repository, not per VS solution.
3.1. Creating Repository
I checked Git options in VS2022 and figured out they are limited so I will need another Git tool. I decided to use Sourcetree to create a high-level directory repository.
DO NOT COMMIT ANYTHING YET! We need to set .gitignore file first. If you do not set .gitignore file first, all your project files, like binaries and intermediate build files will be checked into the repository, and we do not want that.
3.2. Setting .gitignore
In order to emulate the work of VS2022, I copied two files generated by VS2022, files .gitignore and .gitattributes that were created in some other C# project, into the root of my repository and checked them in.
We are doing this manually because we are not using VS2022 to create Git repository, in which case, VS2022 would automatically create .gitignore according to the project type you selected. Since we took over the responsibility of creating the repository on ourselves by SourceTree, it is our responsibility to create the correct .gitignore file.
3.3. Checking in C# VS Solutions Files
Then, I committed all the Visual Studio solutions files into the repository. Because .gitignore is set, the commit will ignore binaries, etc.
3.4. Create GitHub Repository
Then, I created my remote repository account on GitHub and pushed the files.
You can browse the repository on the remote side and verify that no binaries or other project files are checked into the repository. If that did happen, something is wrong with your .gitignore file.
3.5. Merging Unmergeable Branches
The problem that I had now, that just happened, but I am sure will happen again to me and to other people, was that I finished with two branches: main and master. The “main” branch is by default created by GitHub and there is a readme file there. The branch “master” is created by default by SourceTree and my code (my four VS solutions) is in it.
Ok, there is no need to have two branches here, let us merge them and get rid of one of them. Let us keep GitHub default branch “main” and delete “master”.
But there is a problem when you try to merge those two branches:
It gives an error: “fatal: refusing to merge unrelated histories”.
Since our two branches do not have a common ancestor commit, SourceTree thinks we are doing something wrong. But we know we are right, and want to force it.
I looked and it says in [1] that you cannot resolve that from SourceTree GUI. So, we need GitBash to run the command line Git commands. Explanation of the problem and instructions are at [2].
We need to run “git merge <branch-name> --allow-unrelated-histories”
So, you can open GitBash from SourceTree (Terminal button), and execute the command. You will be prompted to enter a commit comment in the separate text editor. Then merge will continue.
And here is what merged branches now look like:
You push your changes to GitHub and verify that the “main” branch now has all your files:
3.6. Deleting Unneeded Branch
Now you can delete the “master” branch both locally in SourceTree and remotely at GitHub. Here is how it looks now. Branch history is preserved, but there is no branch “master”:
4. Verifying Solution in VS2022
Now is the time to see how things look from the VS2022 side. First, we get the clone URL:
Then, we clone the repository in VS2022.
Here is what we got. We got all four solutions at once.
By clicking on some solution, we go to it:
By clicking on the button above, we can go back to the view of all four solutions.
That is what we wanted. The only issue is that all four solutions are on the same branch, that is the “main” branch. Probably the best thing you can do is to create a separate branch for each solution and check the code changes there.
5. Conclusion
Most of my projects are in TFS, so I was surprised how easily mighty VS2022 got defeated by the simple idea to put multiple solutions into a single Git repository. Without an external tool like SourceTree or command line GitBash, it would not be possible to do it.
Regarding Git, I was thinking, isn’t it an open-source project? Can it be upgraded so it has a concept of a workspace that would contain multiple Git repositories? That would save us from the nasty situation that we have now all four solutions on the same branch. Proper links to Git community seem to be [3], [4] ... for those that have time for that.
6. References
7. History
- 15th August, 2022: Initial version
