diff options
| author | Mitja Felicijan <mitja.felicijan@gmail.com> | 2023-10-29 14:41:39 +0100 |
|---|---|---|
| committer | Mitja Felicijan <mitja.felicijan@gmail.com> | 2023-10-29 14:41:39 +0100 |
| commit | 2836163e54e3b94342113314e70ee564c456c43e (patch) | |
| tree | 59b82fc69e83cc6d92846a8e9f510b0bb865cf3b /public/i-was-wrong-about-git-workflows.html | |
| parent | d50ea4053ea04abb3a455606d4591a8283af0677 (diff) | |
| download | mitjafelicijan.com-2836163e54e3b94342113314e70ee564c456c43e.tar.gz | |
Added public folder to git so it get get deployed on vercel
Diffstat (limited to 'public/i-was-wrong-about-git-workflows.html')
| -rwxr-xr-x | public/i-was-wrong-about-git-workflows.html | 65 |
1 files changed, 65 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..ae2e3b5 --- /dev/null +++ b/public/i-was-wrong-about-git-workflows.html | |||
| @@ -0,0 +1,65 @@ | |||
| 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:sans-serif;line-height:1.35rem;font-size:16px;margin:0 auto}hr{margin-block-start:1.5rem}h1,h2,h3{line-height:initial}h1{font-size:xx-large}footer{margin-block-start:2rem}cap{text-transform:capitalize}table{max-width:100%;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}ul.list li{padding:.2em 0}ul{line-height:1.4em}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;padding:0 1em;border:1px solid #dcdcdc}code{padding:0 3px;font-size:14px;border:0}pre code{line-height:1.3em}pre,code,pre *,code *{font-family:monospace}figure{margin-inline-start:0;margin-inline-end:0}figcaption{text-align:center}figcaption p{margin:.3em 0 0}img,video,audio{max-width:100%}header{display:flex;flex-direction:row;gap:3rem}nav{display:flex;gap:.75rem}nav.main{flex-grow:1}.pstatus-orange{background:gold}.pstatus-green{background:#9acd32}.pstatus-red{background:#cd5c5c}@media only screen and (max-width:600px){body{padding:15px}header{flex-direction:column;gap:1rem}a{word-wrap:break-word}}</style><header><nav class=main itemscope itemtype=http://schema.org/SiteNavigationElement role=toolbar><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=/radio.pls target=_blank>Radio</a> | ||
| 5 | <a href=/mitjafelicijan.pgp.pub.txt target=_blank>PGP</a> | ||
| 6 | <a href=/curriculum-vitae.html>CV</a> | ||
| 7 | <a href=/index.xml target=_blank>RSS</a></nav></header><main role=main><article itemtype=http://schema.org/Article><h1 itemtype=headline>I think I was completely wrong about Git workflows</h1><p><cap>post</cap>, May 23, 2023 on <a href=https://mitjafelicijan.com>Mitja Felicijan's blog</a><div><p>I have been using some approximation of <a href=https://jeffkreeftmeijer.com/git-flow/>Git | ||
| 8 | Flow</a> for years now and never really | ||
| 9 | questioned it to be honest. When I create a repo I create develop branch and set | ||
| 10 | 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 | ||
| 11 | always end up making a huge mess when they need to be merged eventually into | ||
| 12 | master. So by that reason, what is the develop branch if not the longest living | ||
| 13 | feature branch. And from my personal experience there was never a situation | ||
| 14 | 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 | ||
| 15 | is there a better way. Well the solution was always there. And it comes in a | ||
| 16 | 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 | ||
| 17 | repository's history. They are used to mark important milestones, such as | ||
| 18 | releases or significant commits, making it easier to identify and access | ||
| 19 | specific versions of a project.<p>Somehow we have all hijacked the meaning of the master branch that it has to be | ||
| 20 | the most releasable version of code. And this is also where the confusing about | ||
| 21 | versioning the software kicks in. Because master branch implicitly says that we | ||
| 22 | are dealing with the rolling release type of a software. And by having a develop | ||
| 23 | branch we are hacking around this confusion. With a separation of develop and | ||
| 24 | master we lock functionalities into place and forcing a stable vs development | ||
| 25 | version of the software.<p>But if that is true and the long living branches are the devil then why have | ||
| 26 | develop at all. I think that most of this comes to how continuous integration is | ||
| 27 | being done. There usually is no granular access to tags and CD software deploys | ||
| 28 | what is present on a specific branch, may that be master for production and | ||
| 29 | develop for staging. This is a gross simplification and by having this in place | ||
| 30 | we have completely removed tagging as a viable option to create a fix point in | ||
| 31 | 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 | ||
| 32 | behave very similarly as branches in that regard. And you don’t have the | ||
| 33 | overhead of having two mainstream branches.<p>So what is the solution? One approach is to use development workflow, where all | ||
| 34 | changes are made on the smaller branches and continuously merged into | ||
| 35 | master. Where the software is ready to be pushed to production you tag the | ||
| 36 | master branch. This approach eliminates the need for long-lived branches and | ||
| 37 | simplifies the development process. It also encourages developers to make small, | ||
| 38 | incremental changes that can be tested and deployed quickly. However, this | ||
| 39 | approach may not be suitable for all projects or teams that heavily rely on | ||
| 40 | automated deployment based on branch names only.<p>This also requires that developers always keep production in mind. No more | ||
| 41 | living on an island of the develop branch. All your actions and code need to be | ||
| 42 | 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 | ||
| 43 | things more streamlined but in the process of doing this, we have inadvertently | ||
| 44 | made our lives much more complicated.<p>In conclusion, it's important to re-evaluate our workflows from time to time to | ||
| 45 | see if they still make sense and if there are better alternatives available. | ||
| 46 | Long-living branches can be problematic, and using tags to mark important | ||
| 47 | milestones can simplify the development process.</div></article></main><section><hr><h2>Posts from blogs I follow around the net</h2><ul><li><a href=https://chotrin.org/writing/2023-10-20.html target=_blank rel=noopener>OpenBSD upgrade and fall things.</a><div>Been AFK for a bit. It's autumn and I upgraded this server to OpenBSD 7.4! — <a href=https://chotrin.org>chötrin's wiki.</a><li><a href=https://mirzapandzo.com/next-image-url-parameter-is-valid-but-upstream-response-is-invalid target=_blank rel=noopener>Next/Image "url" parameter is valid but upstream response is invalid</a><div>Getting "url" parameter is valid but upstream response is invalid error with Next/Image on WSL2 — <a href=https://mirzapandzo.com/>Mirza Pandzo's Blog</a><li><a href=https://drewdevault.com/2023/10/13/Going-off-script.html target=_blank rel=noopener>Going off-script</a><div>There is a phenomenon in society which I find quite bizarre. Upon our entry to | ||
| 48 | this mortal coil, we are endowed with self-awareness, agency, and free will. | ||
| 49 | Each of th… — <a href=https://drewdevault.com>Drew DeVault's blog</a><li><a href=https://solar.lowtechmagazine.com/2023/10/workshop-in-rotterdam-how-to-build-a-bike-generator/ target=_blank rel=noopener>Workshop in Rotterdam: How to Build a Bike Generator</a><div>Afbeelding: Low-tech Magazine workshop in Rotterdam, the Netherlands. Poster: Marie Verdeil. Image: Sara Vercauteren | ||
| 50 | The workshop takes place on behalf of the “Hou… — <a href=https://solar.lowtechmagazine.com/posts/>LOW←TECH MAGAZINE English</a><li><a href="http://offbeatpursuit.com:80/blog/?id=24" target=_blank rel=noopener>Printf debugging</a><div>tags: | ||
| 51 | plan9 | ||
| 52 | There’s no shame in that. Yes, there is documentation, code to be | ||
| 53 | read, and debuggers to be used. But sometimes you just need to “see” | ||
| 54 | what is happening. | ||
| 55 | So… — <a href=http://offbeatpursuit.com:80/blog/>WLOG - blog</a><li><a href=https://neil.computer/notes/chart-of-accounts-for-startups-and-saas-companies/ target=_blank rel=noopener>Chart of Accounts for Startups and SaaS Companies</a><div>Accounting is fundamental to starting a business. You need to have a basic understanding of accounting principles and essential bookkeeping. I had to learn it. Ther… — <a href=https://neil.computer/>Neil Panchal</a><li><a href=https://journal.valeriansaliou.name/deploy-a-nomad-cluster-on-alpine-linux-with-vultr/ target=_blank rel=noopener>Deploy a Nomad Cluster on Alpine Linux with Vultr</a><div>After spending countless hours trying to understand how to deploy my apps on Kubernetes for the first time to host Mirage, an AI API service that I run, I ended up … — <a href=https://journal.valeriansaliou.name/>Valerian Saliou</a><li><a href=https://jcs.org/2023/10/17/wikipedia target=_blank rel=noopener>Wikipedia Reader 1.0 Released</a><div>Wikipedia Reader | ||
| 56 | 1.0 has been released: | ||
| 57 | wikipedia-1.0.sit | ||
| 58 | (StuffIt 3 archive, includes | ||
| 59 | source code | ||
| 60 | and THINK C 5 project file) | ||
| 61 | SHA256: 360e12d064f6579695f1e627ce34cb2f0… — <a href=https://jcs.org/>joshua stein</a></ul><p><a href=https://git.sr.ht/~sircmpwn/openring>Generated with openring.</a></section><footer><hr><p><big><strong>Want to comment or have something to add?</strong></big><p>You can write me an email | ||
| 62 | at <a href=mailto:m@mitjafelicijan.com>m@mitjafelicijan.com</a> or | ||
| 63 | catch up with me <a href=https://telegram.me/mitjafelicijan target=_blank>on Telegram</a>.<hr><p>This website does not track you. Content is made available under | ||
| 64 | the <a href=https://creativecommons.org/licenses/by/4.0/ target=_blank rel=noreferrer>CC BY 4.0 license</a> unless specified | ||
| 65 | otherwise. Blog is also available as <a href=/index.xml target=_blank>RSS feed</a>.</footer> \ No newline at end of file | ||