From cd6644ea4ddc78597934ab0ef5ba50e3c3daa927 Mon Sep 17 00:00:00 2001 From: Mitja Felicijan Date: Sat, 8 Jul 2023 23:25:41 +0200 Subject: Moved to a simpler SSG --- public/i-was-wrong-about-git-workflows.html | 51 +++++++++++++++++++++++++++++ 1 file changed, 51 insertions(+) create mode 100755 public/i-was-wrong-about-git-workflows.html (limited to 'public/i-was-wrong-about-git-workflows.html') diff --git a/public/i-was-wrong-about-git-workflows.html b/public/i-was-wrong-about-git-workflows.html new file mode 100755 index 0000000..e71d60b --- /dev/null +++ b/public/i-was-wrong-about-git-workflows.html @@ -0,0 +1,51 @@ +I think I was completely wrong about Git workflows

I think I was completely wrong about Git workflows

May 23, 2023

I have been using some approximation of Git +Flow for years now and never really +questioned it to be honest. When I create a repo I create develop branch and set +it as default one and then merge to master from there. Seems reasonable enough.

One thing that I have learned is that long living branches are the devil. They +always end up making a huge mess when they need to be merged eventually into +master. So by that reason, what is the develop branch if not the longest living +feature branch. And from my personal experience there was never a situation +where I wasn’t sweating bullets when I had to merge develop back to master.

This realisation started to give me pause. So why the hell am I doing this, and +is there a better way. Well the solution was always there. And it comes in a +form of git tags.

So what are git tags? Git tags are references to specific points in a Git +repository's history. They are used to mark important milestones, such as +releases or significant commits, making it easier to identify and access +specific versions of a project.

Somehow we have all hijacked the meaning of the master branch that it has to be +the most releasable version of code. And this is also where the confusing about +versioning the software kicks in. Because master branch implicitly says that we +are dealing with the rolling release type of a software. And by having a develop +branch we are hacking around this confusion. With a separation of develop and +master we lock functionalities into place and forcing a stable vs development +version of the software.

But if that is true and the long living branches are the devil then why have +develop at all. I think that most of this comes to how continuous integration is +being done. There usually is no granular access to tags and CD software deploys +what is present on a specific branch, may that be master for production and +develop for staging. This is a gross simplification and by having this in place +we have completely removed tagging as a viable option to create a fix point in +software cycle that says, this is the production ready code.

One cool thing about tags are that you can checkout a specific tag. So they +behave very similarly as branches in that regard. And you don’t have the +overhead of having two mainstream branches.

So what is the solution? One approach is to use development workflow, where all +changes are made on the smaller branches and continuously merged into +master. Where the software is ready to be pushed to production you tag the +master branch. This approach eliminates the need for long-lived branches and +simplifies the development process. It also encourages developers to make small, +incremental changes that can be tested and deployed quickly. However, this +approach may not be suitable for all projects or teams that heavily rely on +automated deployment based on branch names only.

This also requires that developers always keep production in mind. No more +living on an island of the develop branch. All your actions and code need to be +ready to meet production standards on a much smaller timescale.

I think that we have complicated the workflow in an honest attempt to make +things more streamlined but in the process of doing this, we have inadvertently +made our lives much more complicated.

In conclusion, it's important to re-evaluate our workflows from time to time to +see if they still make sense and if there are better alternatives available. +Long-living branches can be problematic, and using tags to mark important +milestones can simplify the development process.

\ No newline at end of file -- cgit v1.2.3