diff options
| author | Mitja Felicijan <m@mitjafelicijan.com> | 2023-07-08 23:25:41 +0200 |
|---|---|---|
| committer | Mitja Felicijan <m@mitjafelicijan.com> | 2023-07-08 23:25:41 +0200 |
| commit | cd6644ea4ddc78597934ab0ef5ba50e3c3daa927 (patch) | |
| tree | 03de331a8db6386dfd6fa75155bfbcea6b4feaf3 /public/i-was-wrong-about-git-workflows.html | |
| parent | 84ed124529ffeee1590295b8de3a8faf51848680 (diff) | |
| download | mitjafelicijan.com-cd6644ea4ddc78597934ab0ef5ba50e3c3daa927.tar.gz | |
Moved to a simpler SSG
Diffstat (limited to 'public/i-was-wrong-about-git-workflows.html')
| -rwxr-xr-x | public/i-was-wrong-about-git-workflows.html | 51 |
1 files changed, 51 insertions, 0 deletions
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 @@ | |||
| 1 | <!doctype html><html lang=en-us><meta charset=utf-8><meta name=viewport content="width=device-width,initial-scale=1"><link href="data:image/x-icon;base64,AAABAAEAEBAAAAEAIABoBAAAFgAAACgAAAAQAAAAIAAAAAEAIAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAL69vf8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAv76+/8LBwQkAAAAAAAAAAAAAAAC+vb3/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAL+9vf/Bv78JAAAAAAAAAAAAAAAAu7q6/wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC7ubr/vr29CAAAAAAAAAAAy8nJAZ6foP8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnqGj/6GipAoAAAAAHLjU/xcXHf/BwsL/I8XY/yPK3v8XGiD/IbjL/yPF2f8XGiD/Fxkf/yLF2f8gnK3/Fxog/62ztv8fwNf/FRcd/x271v8mz93/GRsi/xkXHf8p097/GiIp/xobIv8p0t3/KdPe/xocIv8fYmr/KNPe/xoZH/8aHCL/J87c/xy81/8VFxz/IsPZ/8zS0/8XGiD/Ir/R/yPH2/8XGiD/Fxkf/yPH2/8dd4T/GBog/yPJ3f8jyNr/uru9/xcUGv8cudb/EhITDKi5vRKlvMP/RUpOERwcHRAdOj4QHTk8EBwdHRAdNTgQHTo/EBwcHRAcHB0QSGduEKW4vf+koqQfHzg+EBqz0ewSFRv7EyMr/xq51vsTERb7ExUb+xq41fsau9j7ExUb+xiPp/sZudb7ExUb+xMVG/sZuNX/GKvI/BIUGfMdvdn/IrfL/xcaIP8n1eb/J9Dh/xkcIf8ZGR7/J8/f/xxCSv8ZGyH/J9Dg/ybQ4P8ZHCL/FSQs/yPK3/8UExj/GE1b/ybS5P8ZGB7/Ghwj/ynW5P8p2Ob/Ghwi/yWrtv8p1eH/Ghwi/xocIv8p1uT/J8XT/xkcIv8m1un/Hb7d/xUYH/8hzOr/HtHu/xcaIf8XGB//I8vi/xgxOv8XGSD/I8rg/yPK4P8XGiD/GUFL/yPP6f8SERj/Fhkh/x3A4f8AAAAAJ2f9/ydr//8mZPH/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAlYu38J2v//ydo/f8AAAAAAAAAAAd8/fkFqf//Iob8sAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMY39awWr//8FfP3/AAAAAAAAAAAFm/7/SfD//wR+/f8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOB/f9B7v//BaX+/wAAAAAAAAAAQ878SAyZ/v9n1v4KAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADu9v8DDJb+/z3N/XgAAAAA3/sAAN/7AADf+wAA3/sAAAAAAAAAAAAAAAAAAN/7AAAAAAAAAAAAAAAAAAAAAAAAj/EAAI/5AACP8QAA3/sAAA==" rel=icon type=image/x-icon><title>I think I was completely wrong about Git workflows</title><meta name=description content="I have been using some approximation of GitFlow for years now and never reallyquestioned it to be honest."><link rel=alternate type=application/rss+xml title="Mitja Felicijan's posts" href=https://mitjafelicijan.com/index.xml><link rel=alternate type=application/rss+xml title="Mitja Felicijan's notes" href=https://mitjafelicijan.com/notes.xml><style>body{padding:1rem;max-width:760px;background:#fff;font-family:times new roman,Times,serif;line-height:1.35rem}hr{margin-block-start:1.5rem}h1,h2,h3{line-height:initial}footer{margin-block-start:3rem}table{max-width:100%;border-collapse:separate;border-spacing:2px;border:1px solid #000;border-left:1px solid #999;border-top:1px solid #999}blockquote{font-style:italic}table thead{background:#eee}td,th{border:1px solid #000;padding:4px;border-right:1px solid #999;border-bottom:1px solid #999;text-align:left}pre{text-wrap:nowrap;overflow-x:auto;margin-block-start:1.5rem;margin-block-end:1.5rem;padding:.5rem 0;border-top:1px solid #000;border-bottom:1px solid #000}pre code{line-height:1.3em}pre,code,pre *,code *{font-family:monospace;font-size:initial!important}img,video,audio{max-width:100%}header{display:flex;flex-direction:row;gap:3rem}nav{display:flex;gap:.75rem}.pstatus-orange{background:gold}.pstatus-green{background:#9acd32}.pstatus-red{background:#cd5c5c}@media only screen and (max-width:600px){header{flex-direction:column;gap:1rem}a{word-wrap:break-word}}</style><header><nav class=main><a href=/>Home</a> | ||
| 2 | <a href=https://git.mitjafelicijan.com/ target=_blank>Git</a> | ||
| 3 | <a href=https://files.mitjafelicijan.com/ target=_blank>Files</a> | ||
| 4 | <a href=/mitjafelicijan.pgp.pub.txt target=_blank>PGP</a> | ||
| 5 | <a href=/curriculum-vitae.html>CV</a> | ||
| 6 | <a href=/index.xml target=_blank>RSS</a></nav></header><main><div><h1>I think I was completely wrong about Git workflows</h1><p>May 23, 2023<div><p>I have been using some approximation of <a href=https://jeffkreeftmeijer.com/git-flow/>Git | ||
| 7 | Flow</a> for years now and never really | ||
| 8 | questioned it to be honest. When I create a repo I create develop branch and set | ||
| 9 | it as default one and then merge to master from there. Seems reasonable enough.<p>One thing that I have learned is that long living branches are the devil. They | ||
| 10 | always end up making a huge mess when they need to be merged eventually into | ||
| 11 | master. So by that reason, what is the develop branch if not the longest living | ||
| 12 | feature branch. And from my personal experience there was never a situation | ||
| 13 | where I wasn’t sweating bullets when I had to merge develop back to master.<p>This realisation started to give me pause. So why the hell am I doing this, and | ||
| 14 | is there a better way. Well the solution was always there. And it comes in a | ||
| 15 | form of <a href=https://git-scm.com/book/en/v2/Git-Basics-Tagging>git tags</a>.<p>So what are git tags? Git tags are references to specific points in a Git | ||
| 16 | repository's history. They are used to mark important milestones, such as | ||
| 17 | releases or significant commits, making it easier to identify and access | ||
| 18 | specific versions of a project.<p>Somehow we have all hijacked the meaning of the master branch that it has to be | ||
| 19 | the most releasable version of code. And this is also where the confusing about | ||
| 20 | versioning the software kicks in. Because master branch implicitly says that we | ||
| 21 | are dealing with the rolling release type of a software. And by having a develop | ||
| 22 | branch we are hacking around this confusion. With a separation of develop and | ||
| 23 | master we lock functionalities into place and forcing a stable vs development | ||
| 24 | version of the software.<p>But if that is true and the long living branches are the devil then why have | ||
| 25 | develop at all. I think that most of this comes to how continuous integration is | ||
| 26 | being done. There usually is no granular access to tags and CD software deploys | ||
| 27 | what is present on a specific branch, may that be master for production and | ||
| 28 | develop for staging. This is a gross simplification and by having this in place | ||
| 29 | we have completely removed tagging as a viable option to create a fix point in | ||
| 30 | software cycle that says, this is the production ready code.<p>One cool thing about tags are that you can checkout a specific tag. So they | ||
| 31 | behave very similarly as branches in that regard. And you don’t have the | ||
| 32 | overhead of having two mainstream branches.<p>So what is the solution? One approach is to use development workflow, where all | ||
| 33 | changes are made on the smaller branches and continuously merged into | ||
| 34 | master. Where the software is ready to be pushed to production you tag the | ||
| 35 | master branch. This approach eliminates the need for long-lived branches and | ||
| 36 | simplifies the development process. It also encourages developers to make small, | ||
| 37 | incremental changes that can be tested and deployed quickly. However, this | ||
| 38 | approach may not be suitable for all projects or teams that heavily rely on | ||
| 39 | automated deployment based on branch names only.<p>This also requires that developers always keep production in mind. No more | ||
| 40 | living on an island of the develop branch. All your actions and code need to be | ||
| 41 | ready to meet production standards on a much smaller timescale.<p>I think that we have complicated the workflow in an honest attempt to make | ||
| 42 | things more streamlined but in the process of doing this, we have inadvertently | ||
| 43 | made our lives much more complicated.<p>In conclusion, it's important to re-evaluate our workflows from time to time to | ||
| 44 | see if they still make sense and if there are better alternatives available. | ||
| 45 | Long-living branches can be problematic, and using tags to mark important | ||
| 46 | milestones can simplify the development process.</div></div></main><footer><hr><div><h3>Want to comment or have something to add?</h3>You can write me an email at | ||
| 47 | <a href=mailto:m@mitjafelicijan.com>m@mitjafelicijan.com</a> or catch up | ||
| 48 | with me | ||
| 49 | <a href=https://telegram.me/mitjafelicijan target=_blank>on Telegram</a>.</div><hr><p>This website does not track you. Content is made available under | ||
| 50 | the <a href=https://creativecommons.org/licenses/by/4.0/ target=_blank rel=noreferrer>CC BY 4.0 license</a> unless specified | ||
| 51 | otherwise. Blog feed is available as <a href=/index.xml target=_blank>RSS feed</a>.</footer><script src=https://cdn.usefathom.com/script.js data-site=XHQARKXP defer></script> \ No newline at end of file | ||