How I Use Git

&gt; I use git on the CLI 99.9% of the time. I never used a GUI for git and don’t see a reason to.<p>Nobody needs a gui for git or a text editor but using magit is like a superpower compared to the command line. It is probably the best piece of software i&#x27;ve ever used. you can even drop down to the command line git inside of it if you need. i don&#x27;t understand why anyone would prefer the cli over it.

&gt; I use git on the CLI 99.9% of the time. I never used a GUI for git and don’t see a reason to.<p>Because it shows more information about the state and spares you the trouble of navigating much of the zoo that is git cli design<p>For example,<p>&gt; It shows the current branch and whether the repository is dirty, i.e. whether it has uncommitted changes<p>And the GUI would also show what&#x2F;where those changes are and allow jumping to edit them. And you&#x27;d get updates after you edit even without manually refreshing the prompt

Fascinating, and downright uncanny.<p>I could have written it.<p>Now I can share it with others and say &quot;This is 96% me.&quot;<p><pre><code> - I use gap instead of gaa. (He also uses git add -p, but no alias?) - I didn&#x27;t have &#x27;git lr&#x27;, but I do now. - I use `git commit --amend` more often. - Pull request workflows exactly the same. - Same policy on rebasing main onto feature branches. - Same behavior around reviewing and self-reviewing. - Same tendency to commit and cherry-pick off a branch. - ... </code></pre> My Atuin frequency table for git-specific commands:<p><pre><code> gs # git status gap # git add -p gl # git log gc # git commit (with -m, -v or --amend) ga # git add gdc # git diff --cached gd # git diff gp # git push (sometimes with --force-with-lease) gco # git checkout gpr # git pull --rebase --prune git restore git config git rebase </code></pre> I actually use Conventional Commits. I spent a total of 5 minutes bike-shedding &quot;chore&quot;.<p>I didn&#x27;t use &quot;chore&quot; before, because I don&#x27;t get it, but I care more about consistency than being right.<p>So with my current colleague, I use &quot;chore&quot; as he does.<p>Another big difference is: I used `git worktree` extensively in my previous job. I don&#x27;t now.<p>I used it extensively in my old job, since I maintained multiple long-lived contexts, and got distracted a lot.<p>I don&#x27;t do that recently, so it&#x27;s probably a work culture thing.

&gt; When someone asks me to help them with some git thing<p>I point them at jujutsu (jj) and then they simply get on with using source control without the need for 8,000+ articles about navigating the insane Git command line interface.

Good article. I&#x27;m both using git in CLI and graphic tools. But atm the thing that GUIs have and none of the cli is the navigable git graph. And I do like seeing the graph.

A lovely write up.<p>Regarding the formatting of commit messages: if everyone on your team is doing things slightly differently is something going wrong and what could fix it?<p>Is it a respect issue: people don’t follow a consensus because everyone is a headstrong individualist who refuses to play along with others?<p>Is it a communication problem? Are people just not intermingling in the commit message culture enough that they all naturally converge on a house style?<p>Is it a leadership issue? Are there no clear leaders in your engineering team who collude — consciously or subconsciously — to set the tone for everyone else?<p>Is it a technical issue? Without a pro-forma commit message template or additional tooling, are you failing your eng org by not giving them the framework &#x2F; training wheels &#x2F; guard rails they need to align on a house style for technical documentation?<p>I’ve been part of very healthy teams who largely ended up self organising into a consistent house style with a little help from tooling. I’ve also been part of unhealthy teams who fork themselves into multiple internal cliques that don’t intermingle enough to build up a monoculture. The healthiness of the teams might correlate with the commit message &#x2F; commit graph style, or it might not. I wonder how it could be done better.

Mostly agree, though I prefer pulling latest from main over rebasing as the latter messes up the “New changes” markers for reviewers in GH.<p>Also we always squash merge so I don’t bother squashing my commits. Don’t review commit by commit.

&gt; <i>When someone asks me to help them with some git thing and I notice that they don’t have git information in their shell prompt, that’s the first thing I tell them to do.</i><p>This sort of dogmatic thinking is insufferable. Suggesting things is fine, insisting your way of doing things is the best way is really annoying.

Thanks for the writeup, I especially liked the Committing section.<p>Question for the author: when working alone on a personal project, what&#x27;s the benefit of pushing every (minor) commit you&#x27;ve made?

pretty_git_log() looks great, but using kitty on macOS it gives me this:<p>pretty_git_log column: line too long * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * |\ | * | * | * | * | * | * * | * | |&#x2F; * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * <i>&gt; |\ | </i> | * | * * |<p>Perhaps my commit messages are too long.