All but the simplest projects today have multiple components.

With Git, what’s the best way to organize a project with multiple components?

If you put all the code in one repo, you would always have the latest versions. But things become unwieldy when you change one component and not the others. Likely, you’re using multiple repositories.

But, if you store each component in a separate repo, there is no good way to associate them with one another in Git.

How would you know that version 2.0 of the app requires version 1.5 of the server? You could track this in a tool like Jira, but how would you be able to see with certainty that the work has been completed across multiple repos?

In this video, we will look at the Helix TeamHub feature that will take your code to the next level, Multi-Repo Code Review.

We’ll use the example of a Poker Game. This project has multiple components: a server, a web app, an iOS app, and an Android app.

These are all separate codebases, but are architected in such a way that a change to the server code requires a change to each of the other components. The fact that they are written in different languages, by different people, also adds to the complexity.

Here is my project, called “Project With Many Repos”. 

Helix TeamHub natively organizes multiple Git repos inside a single project, not as submodules.

You can see this project has four Git repos for each of the components. The server, the web app, the iOS component, and the Android component are all visible in the project. There’s also a built-in Wiki in the project. Here I can share my documentation with my collaborators beyond just readme files.

This makes it easy to see how they are interrelated, and you can watch the team make changes to each repo in one place.

Now you can create one code review that encompasses work being done across multiple repos by individual team members.  

Branches have been created for each of the components, with a small change to one file in each branch.

Now, let’s look at the multi-repo code review functionality

Each individual commit in the review can be required to pass a build, be reviewed, satisfy assigned tasks, and be approved by a specified number of developers before merging.

This my first Code Review in this project. I’ll click “create the first one.”

Now I select the first Repo I want in the review. I’ll choose the server, the source is the branch, and the destination is master.

I also want to include the IoS code changes, so I will select the IoS component on the next line. The source is the branch, and the destination is also master.

I’m not going to change the web server but I do need to change the Android App code in production.

On the next line, I select the repo Android_Component. The branch is the source and the destination is master.

I can add a title and a description for the review.

I click Create.

So, let’s take a look at what the Reviewer would see. I click on Code Reviews and choose Multi-Repo Code Reviews. Here I can see my list of reviews and the one I just created.

“Poker Game Change” has 3 code reviews. Its State is Open and it is “Not Ready to Merge.”

Once I select the review, I can view each branches’ state. Let’s click into one of them to approve this review. You can see that one review is already approved, but it still says “Not Ready to Merge.” The other two reviews need to pass their gates as well. Once the other two reviews are approved, we’re ready to merge.

When I press the Merge button, all three SHAs are merged into their respective masters simultaneously.

That’s Helix TeamHub’s Multi-Repo Code Review.