What helps people get comfortable on the command line?
Sometimes I talk to friends who need to use the command line, but are intimidated by it. I never really feel like I have good advice (I’ve been using the command line for too long), and so I asked some people on Mastodon:
if you just stopped being scared of the command line in the last year or three — what helped you?
This list is still a bit shorter than I would like, but I’m posting it in the hopes that I can collect some more answers. There obviously isn’t one single thing that works for everyone – different people take different paths.
I think there are three parts to getting comfortable: reducing risks, motivation and resources. I’ll start with risks, then a couple of motivations and then list some resources.
I’d add ImageMagick for image manipulation and conversion to the list. I use it to optimize jpg’s which led me to learn more about bash scripting.
I’m comfortable on the command line but a decent git UI is a way better experience.
git diff is so basic using a GUI makes it far easier to compare changes.
Same for merge conflicts. I’m not sure you can even resolve them on the CLI?
Any form of rebase: I think I used the CLI to do an interactive rebase a few times in the early days but I’d never do so without a GUI now.
Managing branches: perhaps I’m a little too ott but I keep a lot of branches preserved locally, a GUI provides a decent tree structure for them whereas I assume on the command line I’d just get a long list.
Managing stashes: unless you just want to apply latest stash (which admittedly is almost always the case) then I’d much rather check what I’m applying through a GUI first.
There are some things I still use the CLI for though:
git remote addgit remote set-url because I’m just too lazy to figure out how to do that in a GUI. It’s usually hidden away somewhere.
git push --force because every GUI makes it such an effort. C’mon! I know what I’m doing - it’s /probably/ not going to mess things up…
I use git on the CLI exclusively. I almost never rebase, but otherwise get by with about 5-10 commands. One that will totally change your experience is git add -p
I also have my diff/mergetool configured to use kaleidoscope, but still do everything else in the CLI.
Interactively choose hunks of patch between the index and the work tree and add them to the index. This gives the user a chance to review the difference before adding modified contents to the index.
This effectively runs add --interactive, but bypasses the initial command menu and directly jumps to the patch subcommand. See “Interactive mode” for details.
The documentation is entirely meaningless? What does it do?
Useful if you have a large set of changes you want to make separate commits for. I also just find that it’s a good way to do a review of each chunk before committing changes blindly.
Give it a shot some time, worst case is you stage some stuff that you don’t want to commit, but it’s non-destructive.
Yeah, -p can help with that. I’m not much for “commit grooming” - as long as a branch merges to main cleanly and passes tests, I don’t care about an “ugly” commit history.
git add -p is great to know, but IMO one shouldn’t rely on it too much, because one should strive committing early and often (which eliminates the need for that command). Also using git add -p has the risk of accidentally not adding some code that actually belongs to the change you are trying to commit. That has happened to me sometimes in the past and only later do I see that the changes I commited are broken because I excluded some code that I thought didn’t belong to that feature.
There are other reasons to use it. A major one is doing a “code review” of changes before committing, or even deciding to drop a chunk of code from a commit entirely (like a debug statement that no longer is necessary.)
I’m all about frequent commits (and right-sized commits), but the functionality can still be beneficial even in those scenarios.
I also don’t care if I have a broken commit. This turns up very quickly, and there is zero expectation that feature branches are always in a working/stable state. The expectation is that pending work gets off the local machine on a regular interval.
Same for merge conflicts. I’m not sure you can even resolve them on the CLI
How are they solved when using a GUI? When using cli, it simply tells auto-merging failed and you can open the conflicting files in a text editor and solve the conflicts, then add them and continue the merge.
Managing branches: perhaps I’m a little too ott but I keep a lot of branches preserved locally, a GUI provides a decent tree structure for them whereas I assume on the command line I’d just get a long list.
git log --graph --all --oneline
There’s also --pretty, but it uses a lot of screen space.
Managing stashes: unless you just want to apply latest stash (which admittedly is almost always the case) then I’d much rather check what I’m applying through a GUI first.
You can attach a message when stashing with -m.
And you can check them out by doing git checkout stash@{1} or similar.
To be fair, I like to use VSCode for resolving merge conflicts, because it is easy to see the deviations and apply/edit as needed. Still, I use the CLI for everything else, including commiting that merge. Plus the gh cli client when I’m using github as I can create a repo or push a repo with zero effort.
It is possible to resolve conflicts through any text editor, but not an amazing experience.
I also exclusively use the git CLI. I have tried to use a graphical client and could never figure out what it was doing and what was going on. I probably picked it up so easily because when I learned git, I was already used to using a CLI version control client. At the time, I was working at a company that heavily used Perforce and had a custom wrapper around the p4 cli that injected a bunch of custom configuration.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programming@programming.dev
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person’s post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
Follow the programming.dev instance rules
Keep content related to programming in some way
If you’re posting long videos try to add in some form of tldr for those who don’t want to watch videos
You’ve never used a graphical git client?!
I’m comfortable on the command line but a decent git UI is a way better experience.
git diffis so basic using a GUI makes it far easier to compare changes.Same for merge conflicts. I’m not sure you can even resolve them on the CLI?
Any form of rebase: I think I used the CLI to do an interactive rebase a few times in the early days but I’d never do so without a GUI now.
Managing branches: perhaps I’m a little too ott but I keep a lot of branches preserved locally, a GUI provides a decent tree structure for them whereas I assume on the command line I’d just get a long list.
Managing stashes: unless you just want to apply latest stash (which admittedly is almost always the case) then I’d much rather check what I’m applying through a GUI first.
There are some things I still use the CLI for though:
git remote addgit remote set-urlbecause I’m just too lazy to figure out how to do that in a GUI. It’s usually hidden away somewhere.git push --forcebecause every GUI makes it such an effort. C’mon! I know what I’m doing - it’s /probably/ not going to mess things up…I use git on the CLI exclusively. I almost never rebase, but otherwise get by with about 5-10 commands. One that will totally change your experience is
git add -pI also have my diff/mergetool configured to use kaleidoscope, but still do everything else in the CLI.
The documentation is entirely meaningless? What does it do?
You can stage individual chunks of a file.
Useful if you have a large set of changes you want to make separate commits for. I also just find that it’s a good way to do a review of each chunk before committing changes blindly.
Give it a shot some time, worst case is you stage some stuff that you don’t want to commit, but it’s non-destructive.
I’ll occasionally
It’s clunky but it’s robust and safe. It does sound a lot cleaner to just use
commit -pthoughYeah, -p can help with that. I’m not much for “commit grooming” - as long as a branch merges to main cleanly and passes tests, I don’t care about an “ugly” commit history.
git add -pis great to know, but IMO one shouldn’t rely on it too much, because one should strive committing early and often (which eliminates the need for that command). Also usinggit add -phas the risk of accidentally not adding some code that actually belongs to the change you are trying to commit. That has happened to me sometimes in the past and only later do I see that the changes I commited are broken because I excluded some code that I thought didn’t belong to that feature.There are other reasons to use it. A major one is doing a “code review” of changes before committing, or even deciding to drop a chunk of code from a commit entirely (like a debug statement that no longer is necessary.)
I’m all about frequent commits (and right-sized commits), but the functionality can still be beneficial even in those scenarios.
I also don’t care if I have a broken commit. This turns up very quickly, and there is zero expectation that feature branches are always in a working/stable state. The expectation is that pending work gets off the local machine on a regular interval.
How are they solved when using a GUI? When using cli, it simply tells auto-merging failed and you can open the conflicting files in a text editor and solve the conflicts, then add them and continue the merge.
git log --graph --all --oneline
There’s also --pretty, but it uses a lot of screen space.
You can attach a message when stashing with
-m.And you can check them out by doing
git checkout stash@{1}or similar.To be fair, I like to use VSCode for resolving merge conflicts, because it is easy to see the deviations and apply/edit as needed. Still, I use the CLI for everything else, including commiting that merge. Plus the gh cli client when I’m using github as I can create a repo or push a repo with zero effort.
It is possible to resolve conflicts through any text editor, but not an amazing experience.
I also exclusively use the git CLI. I have tried to use a graphical client and could never figure out what it was doing and what was going on. I probably picked it up so easily because when I learned git, I was already used to using a CLI version control client. At the time, I was working at a company that heavily used Perforce and had a custom wrapper around the
p4cli that injected a bunch of custom configuration.