Move back to JBMAFP

1 files changed, 70 insertions, 0 deletions

diff --git a/content/posts/2023-05-23-i-was-wrong-about-git-workflows.md b/content/posts/2023-05-23-i-was-wrong-about-git-workflows.md
new file mode 100644
index 0000000..c0ac6ea
--- /dev/null
+++ b/content/posts/2023-05-23-i-was-wrong-about-git-workflows.md
@@ -0,0 +1,70 @@
+---
+title: I think I was completely wrong about Git workflows
+url: /i-was-wrong-about-git-workflows.html
+date: 2023-05-23T12:00:00+02:00
+type: post
+draft: false
+---
+
+I have been using some approximation of [Git
+Flow](https://jeffkreeftmeijer.com/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](https://git-scm.com/book/en/v2/Git-Basics-Tagging).
+
+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.
+