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:

Using Rust And Leptos To Build Beautiful Declarative User Interfaces

Using Rust and Leptos to build beautiful, declarative UIs

Leptos is an amazing Rust web frontend framework that makes it easier to build scalable, performant apps with beautiful, declarative UIs.

Eze Sunday
Nov 30, 2023 ⋅ 10 min read
5 Best JavaScript Multi-Dimensional Array Libraries

5 best JavaScript multidimensional array libraries

Learn more about the 5 best JavaScript libraries for dealing with multidimensional arrays, such as ndarray, math.js, and NumJs.

Pascal Akunne
Nov 30, 2023 ⋅ 4 min read
Dom Scandinaro Leader Spotlight

Leader Spotlight: Leading by experience with Dom Scandinaro

We spoke with Dom about his approach to balancing innovation with handling tech debt and to learn how he stays current with technology.

Jessica Srinivas
Nov 30, 2023 ⋅ 6 min read
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
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