Best practices for dealing with projects that depend on each other in Git?

Question

We have a product that we currently use TFS as the source control for. TFS's branching/merging capabilities seem incredibly lacking and we are migrating the project to git, and I want to take this as an opportunity to clean up our source control practices as best as possible.

Currently we have a single repository in TFS, lets call it "root". under root,we have all of our separated projects. We have 2 versions of the product in this repository as well as a separate front-end application for version 2 of the product; currently the repository looks something like this:

<root repository>
|
|___Product_V1
|   |_[master branch]
|   |_[dev branch]
|   |_[any release candidate branches]
|
|___Product_V2
|   |_[master branch]
|   |_[dev branch]
|   |_[any release candidate branches]
|
|___Web-based_front-end_for_Product_V2
    |_[master branch]
    |_[dev branch]

Now, when migrating to Git I am unsure of what would be the best practice to store these, my current ideas are as followed:

• Have a separate repository for all projects, a repository for Product_V1, a repository for Product_V2, and a repository for Web-based_front-end_for_Product_V2 - this seems bad because the web-based front end and the back-end will be seperated
• Have seperate repositories for Product_V1 and Product_V2, have a "backend" and a "frontend" folder under the Product_V2 repository and store the projects in there respectively. This seems like the best option out of these, but would like to know of any issues that could arise from people who have maybe done this in practice?
• continue as we were, have a single repository with 3 directories under it, one for Product_V1, one for Product_V2, and one for the front-end. This seems like a non-option, Product_V1 and Product_V2 are totally unrelated and any changes to Product_V1 have no effect to Product_V2 and vice versa. They are totally independent projects.

What are the best practices for Git most people would follow in this situation? My gut feeling is to go with option number 2, but I don't want to implement something now only to hit an obvious pitfall 6 months ahead i didn't think of at the time of implementing.

Answer 1

Since you responded with more information, personally I'd set it up as 2 separate repositories: one each for V1, and one for V2 and it's web front-end, assuming that the web front-end is heavily integrated and dependent (and needs to be deployed along with V2). If you have some amount of abstraction between the product itself and the web application (a versioned API, maybe?) then you might think about separating the two code bases.

All of that is less important than what your team thinks of the source control/branching/merging strategy... if you have a team besides yourself, I mean :D. Talk it over with them to come up with a good direction too.

Answer 2

Personally, I do not like option 3. I am trying to do that in a project and it is a headache. When you create separate repositories, you can use git's submodule feature to collect them into a single matter repository. This also gives you the flexibility to work on any single repository on its own.

As for choosing between options 1 and 2, I do not have enough information to form a strong opinion one way or the other.

Answer 3

It depends greatly on how your projects are used downstream from git - how they are built, deployed, etc. Basically, your automated processes will dictate the best method for repository structure.

For example, if you were using, say, Jenkins to build your projects, the ideal git structure would be to use one repository, with multiple branches (master, dev, release candidate). You would still have each separate project in its own folder. This setup allows you to have a single Jenkins job that can build everything in your repository. All three projects, built with one click. That wouldn't be possible with three repositories. Just three times more work when you go to build.

If you have no automated builds, just use whatever structure will be most familiar to your developers and make the transition to git as easy as possible. Git is pretty good at doing the job regardless of how you have it set up. Just set it up to best meet your needs. The hurdles you are most likely to run into probably won't be with your git repository or how you've structured it.

The dependencies between your projects would be resolved by your build system, not by git. Git only deals with source code and version control, not build order or dependency management. So the repository structure is irrelevant when it comes to dependencies.

Also, I concur with guineveretoo - the branching strategy is very important. Having a weird git structure amounts to a longer command or a couple more steps for developers, but it's an action that isn't often repeated anyway. Commits, and especially pushes, should only happen when a code change is built and tested and ready to go. On the other side of the coin, having a structure that doesn't match your branching strategy makes it a nightmare for just about everyone.

For an example of a best practice, tried-and-true branching strategy, see this guide.

Answer 4

First of all, we have to take into account the project management could (and it will) condition the strategy.

That being said, I would go for the 1st option.

Here my reasons:

• They are completely independent projects. As you already stated.

• Each project might have different ALM (versioning, CI, CD, etc). That applies to the frontend too.

  Backend and frontend versioning can be managed independently.

  For instance, we use Gitlab and so far I know it doesn't allow us to make tags/branches of specific content (folders) that hangs from the same repository. In other words, it forces you to tag/branch the whole repository.

• Each project can be developed and managed by different teams *(this is my case, specialised teams: backend, frontend, UX, iOS, Android, CMS, etc.).

  Independent repositories make easier, the pull,commit,merge,push processes.

  This might seem irrelevant but isn't especially if it's the first time working with git.

Assembling Project _v2 - frontend

Both projects can be assembled lately. For instance, during CI or via dependency management.

I'm not familiar with NugetServer but looks like it can do the job (as @RubberDuck suggested)

Disassembling Project_v2 - frontend

You might decide (for a good reason) to take out the static content (frontend) from the backend and serve it through a web server (IIS). For instance, let's say that you turned out the MVC app into a middleware API REST-like.

You would have already detached both projects. Having projects detached allows independent deliveries/deployments. This's important if you go to the cloud. It could save you some unnecessary deployments.

The key is treating the frontend as if it were a mobile app (just one more client app with its own planning).

Summarising, this approach makes the ALM a bit more complicated (extra work for everyone) but you gain in flexibility. It's less monolithic.

Note: I have omitted references to the project_v1. IMO it's evident that it has nothing to do with the other two projects. Reason enough for keeping it separated.