DEV Community

Cover image for Choosing the Right Git Branching Strategy for Your Organization

Choosing the Right Git Branching Strategy for Your Organization

Adesoji1 on October 11, 2023

Effective version control is at the heart of modern software development, and Git has become the industry standard for managing source code. Git of...
Collapse
 
njfamirm profile image
S. Amir Mohammad Najafi
  • small branch and pr for each changes and feature
  • main branch: developing
  • release tag: production

So small pr make review fast and increase code quality, and the main branch with release tag make simple and stable project management

Adding workflow for build and ...., For each step make check code quality more better

Thanks for post

Collapse
 
ch4ni profile image
Ada-Claire • Edited

This sounds a lot like what gitlab flow is, effectively.

The assumptions on my part are:

  • every change starts against develop/main and gets merged "up" into the release branch
  • at every release tag there's a subsequent merge back "down" into develop.

With those two assumptions, release branches don't need to be long lived, after merge back down, they can go away because a hot fix/release branch can be recreated at will due to the existence of a tag. The recreated branch (due to the nature of commit refs and history) retains the original release branch history ... IIRC, you can see that behavior by viewing the commit graph on a branch made from a tag where the original tag branch had been removed.

If you'd like, you can probably think of a tag as a 'lightweight branch' ... Branches are a special commit ref named HEAD with some metadata, and tags are effectively a ref to a commit ref with some metadata (potentially including comments, such as release notes, and a cryptographic signature)

Collapse
 
adesoji1 profile image
Adesoji1

@ch4ni Thanks for this tutelage,it worth millions 🙏🏼

Collapse
 
adesoji1 profile image
Adesoji1

Thank you @njfamirm I have learnt

Collapse
 
njfamirm profile image
S. Amir Mohammad Najafi

What I understood from the recent articles I read, my comment was the description of the trunk, which is different from yours, what is the reason for this?

Collapse
 
adesoji1 profile image
Adesoji1 • Edited

@njfamirm Trunk-based development is a version control management practice where developers merge small, frequent updates to a core “trunk” or main branch

Collapse
 
hubertba profile image
Hubert Baumgartner

I would like to add. Please choose your branching strategy first and then take the git system which supports it. For example a bad idea would be to want to use git-flow together with GitHub. Especially GitHub is ver opinionated in favor of the branching strategy it supports ( basically GitHub-flow)

Collapse
 
dbolser profile image
Dan Bolser

And GitHub flow is a sales channel into its 'premium' services?

Collapse
 
adesoji1 profile image
Adesoji1

@hubertba duly noted

Collapse
 
adesoji1 profile image
Adesoji1

@hubertba Thanks for teaching me this

Collapse
 
ch4ni profile image
Ada-Claire

Github is just git with a fancy web-based frontend. It neither prescribes, nor proscribes any particular workflow ... The same can be said of any generic git hosting service.

GH works for pretty much everything you can throw at it, but GitHub flow is definitely a first class citizen in terms of workflow options.

That being said, I would always strongly advise against git-flow - it's an abuse of git mechanics, and completely ignores the merits of using git tags, and eschews them in favor of a convoluted workflow that places significant burdens on code maintainers.

To track multiple releases or environments within a branching model, gitlab-flow (with some of the documented variation) would likely be a better fit.

My hardline opinion is that there must be one branch that is the source of contiguous truth, and it must always be ready for deploy at a moment's notice. Everything else, in terms of branching strategy is up to the needs of the software, and the engineering team.

Collapse
 
adesoji1 profile image
Adesoji1

@ch4ni Thank you, can I speak with you further on this subject matter?

Thread Thread
 
ch4ni profile image
Ada-Claire • Edited

Absolutely, I wouldn't consider myself a deep expert on git, but I'm always up for discussion.

For git-flow in particular, it's always struck me as overly complex, and 5 years after my first exposure to it, it was nice to see that the original author has sought to slow adoption of the practice (see the "note of reflection")

Of course, the hard part is that once one builds up processes and automation around a solution not well architected for their needs, it's difficult to move away from all the implicit assumptions in those processes and automations.

Also, people are generally resistant to change 😅

Collapse
 
adesoji1 profile image
Adesoji1 • Edited

Thank you for this Information, well received @hubertba

Collapse
 
nickwillan profile image
Nick Willan

Give me Trunk-based branching or give me death.

Collapse
 
adesoji1 profile image
Adesoji1

I like this 😊

Collapse
 
dbolser profile image
Dan Bolser

Why plz?

Collapse
 
dallo7 profile image
Dalmas Chituyi

I think a Hybrid of Release Branching and Trunking will suffice.

Why?

It allows for the rather simple experience of Trunking but reduces the risk of bad commits by committing to a Release branch.

Collapse
 
august77 profile image
Augustino Hoobjana

Thank you