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 --- .../2023-05-23-i-was-wrong-about-git-workflows.md | 71 ---------------------- 1 file changed, 71 deletions(-) delete mode 100644 content/posts/2023-05-23-i-was-wrong-about-git-workflows.md (limited to 'content/posts/2023-05-23-i-was-wrong-about-git-workflows.md') 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 deleted file mode 100644 index 16739de..0000000 --- a/content/posts/2023-05-23-i-was-wrong-about-git-workflows.md +++ /dev/null @@ -1,71 +0,0 @@ ---- -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 -draft: false -type: posts -tags: [] ---- - -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. - -- cgit v1.2.3