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:

Exploring Nushell, A Rust Powered, Cross Platform Shell

Exploring Nushell, a Rust-powered, cross-platform shell

Nushell is a modern, performant, extensible shell built with Rust. Explore its pros, cons, and how to install and get started with it.

Oduah Chigozie
Apr 23, 2024 ⋅ 6 min read
Exploring Zed, A Newly Open Source Code Editor Written In Rust

Exploring Zed, an open source code editor written in Rust

The Zed code editor sets itself apart with its lightning-fast performance and cutting-edge collaborative features.

Nefe Emadamerho-Atori
Apr 22, 2024 ⋅ 7 min read
Implementing Infinite Scroll In Next Js With Server Actions

Implementing infinite scroll in Next.js with Server Actions

Infinite scrolling in Next.js no longer requires external libraries — Server Actions let us fetch initial data directly on the server.

Rahul Chhodde
Apr 19, 2024 ⋅ 10 min read
Integrating Django Templates With React For Dynamic Webpages

Integrating Django templates with React for dynamic webpages

Create a dynamic demo blog site using Django and React to demonstrate Django’s server-side functionalities and React’s interactive UI.

Kayode Adeniyi
Apr 18, 2024 ⋅ 7 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