Comment

Comment on What helps people get comfortable on the command line?

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 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 add git 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…

source

Sort:hotnew top

atheken@programming.dev ⁨1⁩ ⁨year⁩ ago
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

source
- StudioLE@programming.dev ⁨1⁩ ⁨year⁩ ago
  
  -p –patch
  
  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?
  
  source
  - atheken@programming.dev ⁨1⁩ ⁨year⁩ ago
    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.
    
    source