> 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.
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.
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.
> 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.
> 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.
> 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.
And you don’t need to a make three dozen shell/git aliases. The keybinds are already good.
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.
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.
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.
Well, it's not navigable, but there is git log --graph --oneline --decorate
> 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.
> 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/… ;)