2

I have a rather simple application which consists of an angular frontend and a REST API done in C# For the frontend I use WebStorm and for the backend Visual Studio. Now we need to introduce a new version control and it has been decided to use Team Services (Git).

There is no code or any assets shared between the frontend and the backend, but they are logically coupled because the frontend needs the backend and the backend is only (and will only ever be) used by this particular frontend.

I'm fairly new to Git but I know (a bit) what submodules, subtree etc. are.

My initial thought was: Clearly, two repositories are the way to go, since I can publish frontend/backend separatly on different servers, as long as the backend exists somewhere the frontend has access too everybody will be happy. And:

  • Webstorm and Visual Studio won't interfere with each other and "steal" commits (which I personally find annoying).
  • Or show files which don't belong to the project. For example I would see every backend file when opening my frontend in webstorm since they are in the same repository. Or am I wrong?

On the other hand I would have to make sure myself that Frontend and Backend are always compatible. Which I think isn't that hard. But those two repositories would be totally separated in git and there wouldn't be any connection whatsoever between the two.

As far as I know it is not possible to tell git or webstorm/visual studio to just use a specific subdirectory, right?

So, my question would be. What would you recommend in this case?

  • two repositories
  • one repository with just subdirectories
  • one repository with subtrees (and an empty parent repository?)
  • something different

Thanks in advance

Improve this question
1
  • Think about the surface vector for bugs that may arise if future development on one repository continues out of sync with the frontend. Unless you have automated integration tests, it's not worth having the decoupling of git repos. You can also always just open your IDE in the specific subfolder if you are concerned about that.
    – Akshat Mahajan
    May 29, 2017 at 15:14

1 Answer 1

Reset to default
3

The biggest issue I think about for projects like this is, 'How can I keep the front-end and API in-sync with each other?' You don't want your front-end asking for things that don't exist or have been deprecated by your API.

The easiest way to solve this issue is to have one repo, where changes in the API and front-end are all in the same commits / PRs.

This falls apart in a lot of places though. It can be harder if you want to swap out your API or front-end later. Also, you can end up wasting a lot of time when doing deployment if you have a long build step, or a large test suite.

There's another post that goes over a lot of pros and cons, but I think this really boils down to team size and how you plan on doing deployments. If it's a small team, even up to 4 people, you're probably good with one repo. If you have a large team, and a dedicated versions, and so on, managing one repo can get out of hand.

Again, I would recommend looking at the other post as the question and the answer provide a lot of good considerations.

When to separate a project in multiple subprojects

Improve this answer
6
  • 1
    Oh, and as far as your IDEs, they shouldn't care what folder they're looking at, assuming you're​ not doing git management with them, which I would recommend against (if nothing else, because you'll have to learn git with two different programs, visual studio and web storm).
    – JRJurman
    May 29, 2017 at 21:25
  • 1
    OP is using VSTS, so I'm assuming they're using that for their build too. That build system allows you to create different builds based on what directory files were changed in.
    – RubberDuck
    May 29, 2017 at 23:19
  • I intend to do Git from within the IDEs because I don't want to use yet another tool for just version control (not unless necessary because of limitations in the IDE)
    – Arikael
    May 30, 2017 at 13:28
  • I personally recommend using git from the command line, but, as with anything, use what makes you most productive
    – JRJurman
    May 30, 2017 at 16:53
  • thanks for your input. We decided to go with one repo since this is a small project and only few people will every work with it. Multiple repos would only result in unnecessary complexity.
    – Arikael
    Jun 1, 2017 at 5:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.