How I Use Git | Hacker News Reader

How I Use Git

registerspill.thorstenball.com

87 pointsBerislavLopac29 comments

> 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.

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've ever used. you can even drop down to the command line git inside of it if you need. i don't understand why anyone would prefer the cli over it.

Exactly. My favorite is probably "r s" or rebase subset: it is much more intuitive to use than remembering the order of the refs you pass to `git rebase --onto X Y Z`, and this happens to be something I do a whole lot since I use dependent branches to create dependent PRs.

My second favorite is "c F" or instant fix up.

But magit is a plugin for a text editor. No text editor, no magit. And the difference between a TUI and a GUI is only gradual.

I'm not sure your point? I am advocating for magit/a text editor plugin. git itself is not a TUI either like say lazygit is one. if someone were to rip out everything except magit and throw it into a TUI I'd be down to use it but as it is I only use emacs for magit because magit is just that good.

I don't use magit, because I don't use Emacs.

But I've seen a magit power user, and arguably:

magit is the only git client I've seen that does some things better than CLI without being severely disempowered.

I only prefer the CLI over magit because I don't use Emacs. I'm not switching back to Emacs because of magit (or org-mode).

LSP is just too big for me, and Emacs has poor LSP, both in rendering, back-end performance, and effort setting it up.

I installed doom emacs to get magit because i don't use emacs anymore other than magit and i wanted fast startup and no config. it's worth it to me.

And you don’t need to a make three dozen shell/git aliases. The keybinds are already good.

GitKraken is amazing.

gitkraken is nice yeah. it's nowhere near the efficiency of magit imo. git is like ed. magit is like vim. gitkraken is more like maybe word? does everything you want has a nice clickable gui but it is not quite as efficient to use.

> 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.

Because it shows more information about the state and spares you the trouble of navigating much of the zoo that is git cli design

For example,

> It shows the current branch and whether the repository is dirty, i.e. whether it has uncommitted changes

And the GUI would also show what/where those changes are and allow jumping to edit them. And you'd get updates after you edit even without manually refreshing the prompt

> spares you the trouble of navigating much of the zoo that is git cli design

Yeah. I understand the inner workings of git and am perfectly capable of using git on the command line but the git cli is just so horribly designed. I regularly have to google how to perform rather basic actions because the cli just isn't structured in any sensible way.

Fascinating, and downright uncanny.

I could have written it.

Now I can share it with others and say "This is 96% me."

  - I use gap instead of gaa. (He also uses git add -p, but no alias?)
  - I didn't have 'git lr', 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.
  - ...

My Atuin frequency table for git-specific commands:

  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

I actually use Conventional Commits. I spent a total of 5 minutes bike-shedding "chore".

I didn't use "chore" before, because I don't get it, but I care more about consistency than being right.

So with my current colleague, I use "chore" as he does.

Another big difference is: I used `git worktree` extensively in my previous job. I don't now.

I used it extensively in my old job, since I maintained multiple long-lived contexts, and got distracted a lot.

I don't do that recently, so it's probably a work culture thing.

One suggestion for local branch logging - you can do `git log master..` and it will show you the log of commits on your branch, stopping when it gets to (the common ancestor with) master.

I don't use many aliases, but I do use that command a lot.

> When someone asks me to help them with some git thing

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'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.

I also love clicking on the current branch name, seeing all available branches and the checkout in an instant. 0 typing.

Or select files by intuitively pressing + on them (or their folder), go through all the changes on the side.

From these threads it seems that I'm the only one who appreciates some UX and not having to type literally everything every time I've got to do something on a computer.

Well, it's not navigable, but there is git log --graph --oneline --decorate

A lovely write up.

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?

Is it a respect issue: people don’t follow a consensus because everyone is a headstrong individualist who refuses to play along with others?

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?

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?

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 / training wheels / guard rails they need to align on a house style for technical documentation?

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 / commit graph style, or it might not. I wonder how it could be done better.

Specifically the commit formatting? How to write and markup?

A lot of people don’t care enough. Likely someone will be on your team. And if they all care then it might still be the case that they won’t have a house style. Because it’s still well-written and legible.

Yeah, commit message formatting as a proxy metric for how closely aligned your engineers are. Another one might be “do they all dress kind of the same?”

Lots of successful teams literally dress identically (Real Madrid, Biles et al., Seal Team Six, Destiny’s Child) or at the very least have an underlying culture that joins them. An actual culture, not just a list of corporate touchstones, that you can visibly see either with a dress code or behavior.

Mostly agree, though I prefer pulling latest from main over rebasing as the latter messes up the “New changes” markers for reviewers in GH.

Also we always squash merge so I don’t bother squashing my commits. Don’t review commit by commit.

> 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.

This sort of dogmatic thinking is insufferable. Suggesting things is fine, insisting your way of doing things is the best way is really annoying.

When I see that someone is using the Git CLI exclusively and not magit/lazygit/… ;)

Why do you read "tell" as insisting instead of suggesting?

Thanks for the writeup, I especially liked the Committing section.

Question for the author: when working alone on a personal project, what's the benefit of pushing every (minor) commit you've made?

Not the author, but I make micro commits because it helps me backtrack my implementation decisions. A lot of times I would look at a line of code thinking why I would write something like that and find the reasoning by git blaming that specific line or chunk of code. In short, I do it to make up for my poor memory.

Interesting, I've almost never had this problem and I don't have a great memory. Not worth making small commits just for that reason (for me, of course!)

pretty_git_log() looks great, but using kitty on macOS it gives me this:

pretty_git_log column: line too long * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * |\ | * | * | * | * | * | * * | * | |/ * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * > |\ | | * | * * |

Perhaps my commit messages are too long.

All of those characters are part of the ASCII history graph -- that repo must have a very interesting graph at some point!

Reply on news.ycombinator.com