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