2022-04-28
2838
Fernando Doglio
377
Apr 28, 2022 ⋅ 10 min read

Git workflow strategies: Multiple teams in a single repository

Fernando Doglio Technical Manager at Globant. Author of books and maker of software things. Find me online at fdoglio.com.

Recent posts:

Vite Adoption Guide Overview Examples And Alternatives

Vite adoption guide: Overview, examples, and alternatives

Vite is a versatile, fast, lightweight build tool with an exceptional DX. Let’s explore when and why you should adopt Vite in your projects.

David Omotayo
Nov 29, 2023 ⋅ 16 min read
Implementing Advanced Features With The Navigator.Share API

Implementing advanced features with the navigator.share API

Explore advanced capabilities for content sharing with the navigator.share API, including dynamic content sharing, custom share targets, and batch sharing.

David Omotayo
Nov 29, 2023 ⋅ 10 min read
Chas Peacock Leader Spotlight

Leader Spotlight: Scaling for the next phase of growth with Chas Peacock

We spoke with Chas to get his insights on building technology and internal processes for companies that are scaling quickly.

Jessica Srinivas
Nov 29, 2023 ⋅ 7 min read
Cypress Adoption Guide: Overview, Examples, Alternatives

Cypress adoption guide: Overview, examples, and alternatives

Cypress is one of today’s foremost tools for testing web applications. Let’s explore when and why you should adopt Cypress in your projects.

Paul Akinyemi
Nov 28, 2023 ⋅ 10 min read
View all posts

5 Replies to "Git workflow strategies: Multiple teams in a single repository"

  1. Really intresting article and workflow. We are trying to adopt this (or something similiar) in our current project, as the same problems arose:
    Some members in our teams are not as proficient in git as others and often we encountered issues that came from misusing git and it’s standard workflows. Also, the two teams work in parallel on the same project but in a different sub-module/part of the codebase and there were quite a few cases where the two teams broke each other’s code, causing us a lot of headaches.
    Having said that, we will also try to educate colleagues about proper git usage 🙂
    Thanks for the article!

    1. Absolutely! Educating your team members is definitely the way to go, but that takes time and a lot of effort that also depends on them and the amount of effort they put towards getting educated. In the meantime this workflow can help you lower the amount of conflicts and issues in your project! I’m glad you liked it, I wish you the best of lucks!

  2. Nice Article! We are working on a large project (tens of millions of lines spread across 45 repositories). We see most of the problems you describe. It is nice to see that we aren’t alone.

    We follow a process similar to yours currently: We have 12 integration branches (one per team) and a base development branch. After pull request review, we merge feature changes into the team integration branches. Then, every sprint, the team merges their integration branch into the base development branch (which eventually becomes the main release branch).

    We created these integration branches for exactly the reason you say: To isolate teams from each other.

    However, this has a couple of significant issues for us:

    * We don’t deliver individual features to a Q/A branch, and it is not possible for us to deliver 50 different builds to Q/A every day. (A full build takes a couple of hours and creates a 20 gigabyte product directory.) So, instead, we deliver only the integration branches to Q/A. Developers are tempted to prematurely merge to their integration branch, “poisoning” it with incomplete features.

    * At the end of the sprint, the poisoned integration branch is merged to a the develop branch, poisoning the PSI and leaving extra undone work that has to be fixed next before we are really shippable.

    We are probably going to eliminate the integration branches. This gives up the isolation but (hopefully) simplifies the process for us. We’ll deliver those feature branches to Q/A and add more reviews, getting those features truly done before they go anywhere.

    You show the dotted arrow merges to a special Q/A branch as automatic, but how do those actually happen? Having specific Q/A branches might help us, but it seems like a lot of overhead. We also do not do any separate merges to prod. It seems that those merges are not all automatic but could have merge conflicts.

    Do you have any issues getting Q/A done on your feature branches? It seems that you have to keep the T1Dev branch clean. If a feature doesn’t get completed in a sprint, there is potentially a lot of rebasing or merging going on to move it to the next sprint.

    Thanks again for the article!

  3. I enjoyed reading this Article, maybe because I felt like you were living in my own head. So many people think that “everyone” knows how to use Git, GitHub, GitLab etc, but what I have found is that most do not know how to use these tools. I have actually had one developer state “my job will be easier when we move from tool X to GitHub” I asked him “have you used GitHub?” his answer was “No”. Guess what, he wishes we had stayed with tool X 🙂 Again, great article, I am passing it to several of my co-workers.

  4. I feel like the approach in the article will work to share my team’s repo with another team, but, I’m still confused about a few things.

    My company uses 4 branches: Development, QA, Staging and Prod.
    Development merges into QA which merges into Staging which merges into Prod.
    Soon, another team will be sharing one of my team’s repositories,

    Following the diagram (assuming BaseDev is our current Development branch):

    Given a tag called Sprint1

    1. The Sprint1 tag is created from T1Stable
    2. T1Dev is created from the Sprint1 tag
    3. F1 branch is created from T1Dev
    4. F1 is committed to T1Dev
    5. T1Dev is merged to T1Stable and auto-merged to BaseDev
    6. BaseDev is auto-merged to QA
    7. T1Stable is merged to Prod

    Questions:
    1. How is T1Stable initially created?
    2. T1Stable and T2Stable function like QA branches because a) QA must approve the merges and b) they merge into Prod. Correct?
    3. Since BaseDev is the only branch that merges into QA – but QA doesn’t merge into Prod. What purpose does QA serve?

    Thank you.

Leave a Reply