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

gitpatterns-and-practices

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.

Best Answer

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.

Related Topic