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:

Comparing React Native BLE libraries

Comparing React Native BLE libraries

Discover the most popular libraries for enabling Bluetooth Low Energy (BLE) in React Native apps, allowing them to interact with Bluetooth hardware on iOS and Android platforms.

Fimber Elemuwa
Feb 26, 2024 ⋅ 4 min read
Using CRDTs To Build Collaborative Rust Web Applications

Using CRDTs to build collaborative Rust web applications

CRDTs, or conflict-free replicated data types, is a concept that underlies applications facing the issue of data replication across a […]

Mario Zupan
Feb 23, 2024 ⋅ 15 min read
Guide to Using TensorFlow in Rust

Guide to using TensorFlow in Rust

We explore the fusion of TensorFlow and Rust, delving into how we can integrate these two technologies to build and train a neural network.

Rosario De Chiara
Feb 22, 2024 ⋅ 8 min read
Using Signaldb With React

Using SignalDB with React: A complete guide

SignalDB enables automatic data synchronization between your components and a local in-memory or persistent database.

Antonello Zanini
Feb 20, 2024 ⋅ 6 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