I know this has been asked a few times but I still a bit confused, People say to have a git repo per project, but I not 100% what "project" means in this context.
I am going to have a reactjs front end, asp.net core web api.
Should I be making 2 git repos for this as they are 2 different solutions or since it is used all on the same web application they should be in the same git repo?
Where one folder would contain all the reactjs and another folder would have the visual studio solution.
Make one repo for all the code.
In other cases the advantages of splitting things into two could be reduction in individual repo size, and ease of working independently on one package or the other without affecting the other one. In this case presumably the repository will never be so big as to be inconvenient, and ease of working on one project separately is unlikely to help much since for many features you will have to work in both sides.
By having one repo you make it easier to keep track of versions and deployments, and if you need to change something in the API that links server side to client side you can easily change both sides at once. For instance your asp.net might be sending prices in pounds to the react app. If you decide you want to change the protocol and send the prices in pence instead it's much easier if you can update both parts within a single commit.
For a developer working exclusively on one part of the application it shouldn't hurt them to have the other part in a directory on their machine, and it might help by making it that much easier for them to read a little part and see how it does something. They can even make some simple changes without needing to be an expert in the other language.
These are independent projects, one server, one client, and it could be developed/maintained for different teams, so in my conception, the best way is use 2 repos.
