DEV Community

Keith Darragh
Keith Darragh

Posted on

Git process

We have had a debate on our git process, how we branch and release into production.

My preference is to continuously commit and release from master by tagging each release. Features can be branched from this and pushed for code review before merge. Generally I like to continuously deploy and have features which are not yet available behind configuration.

The team I'm in prefers a different approach which I find messy. They would rather have a development branch along with the master branch. To build a feature you branch from development, and merge back to development. On release in development will get merged into master. I think this is harder to maintain and allows issues to arise if master gets ahead of development due to a bug fix.

What is your preferred git process?

Top comments (9)

Collapse
 
endy_tj profile image
Endy Tjahjono

Having a long lived dev branch is extra work. The daily merge/rebase from master + adjustment itself will take a lot of time. But sometimes it is better to use this long lived dev branch if the modification is huge and you don't want all these changes in the master branch for the time being.

Collapse
 
keithdarragh_73 profile image
Keith Darragh

Fair point about the changes not being in the master branch for the time being, but if there are changes which you don't want to release is it not easier to create a release branch from master? This way you can continually add to master and keep it up to date but only release what is necessary? In this scenario a release cut can be taken from a specified commit hash rather than head.

Collapse
 
endy_tj profile image
Endy Tjahjono

Hmm I'm not clear with what you mean. The long lived dev branch is a branch of master. Bug fixes are applied to master using short lived dev branch using the pull request flow (create branch, commit to branch, pull request from branch, squash merge to master). To release we add tag on master, then build from tag.

Thread Thread
 
keithdarragh_73 profile image
Keith Darragh

Instead of using the tag, you can create a release branch which removes the need for a dev branch. How do you manage bug fixes to your master release and propagating those changes back into dev?

Thread Thread
 
endy_tj profile image
Endy Tjahjono

Instead of using the tag, you can create a release branch

Yes, we create branch from the tag in case a version needs patching.

which removes the need for a dev branch

Um no. Put another way, our dev branch uses the same pull request flow but longer lived.

How do you manage bug fixes to your master release and propagating those changes back into dev?

Bug fixes are squash merged from the pull request branches into master, then the dev branch rebase from master.

Thread Thread
 
keithdarragh_73 profile image
Keith Darragh

Yes I understand. I didn’t realise you were gutted a release branch from master as well, I understood you were just using the git tag!

Thread Thread
 
endy_tj profile image
Endy Tjahjono

Off topic, I've been to Belfast twice. Nice city!

Thread Thread
 
keithdarragh_73 profile image
Keith Darragh

It is, come back soon!

Collapse
 
grasmachien profile image
grasmachien

Both processes have their positive and negative sides and I'm sure you will never find the perfect one without any negative sides.
In my experience it is best to find a process that most people agree on.
When they don't agree and you force it on them then they will keep hating it even if it works really well.
If after some time issues are coming up with their process you can still explain them how your preferred process fixes this issue.
Chances are they will want to try out your process.

It's also possible their process will work just fine for your team and in that case there is no need to keep searching for another way. Be happy there is a git process that everyone is respecting.