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)
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.
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.
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.
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?
Yes, we create branch from the tag in case a version needs patching.
Um no. Put another way, our dev branch uses the same pull request flow but longer lived.
Bug fixes are squash merged from the pull request branches into master, then the dev branch rebase from master.
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!
Off topic, I've been to Belfast twice. Nice city!
It is, come back soon!
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.