You know what? Fuck it. Git CLI. Hot take.

Question is "least favorite". Not "worst". Not "least important".

Git is great, essential, fantastic, whatever. But I hate interacting with the CLI. I can never remember the stupid fucking commands, I always mess shit up if I need to do something outside of my normal workflow, and honestly, usually the correct way of doing shit looks fucked.

So fuck git CLI and its learning curve

I'm inclined to agree. Not the best beginner experience, docs aren't explicit enough and mostly have sophisticated terminology.

git gud?

Jokes aside, I personally hate the graphical tools.

Git is one of those tools though, if you don't get comfortable with it you're gonna have a bad time. I started on SVN back in the day though, so git is 1000x better IMO.

Sorry you're having such a shit time with it.

I prefer the cli over GUI clients, I have more control over the stuff I do and don't have to keep fiddling with menus and other shit. It did take a bit of time to get used to, but once I learned the commands I use often (add, reset, commit, log, merge, checkout, push, and a few others) it became wonderful. I don't even consider switching to a gui anymore.

Maybe you could write a little cheatsheet so you don't need to remember the commands, once you use them enough you'll start remembering them. Or just use a gui, you do you.

If you’re on bash, have you used autocompletion? It remembers your old command and helps me type/remember what my workflow is

@devTea good point!

There's also history|grep if you have executed it once in your last 100-1000 commands.

@devTea Don't forget to add this lines to .inputrc, they are useful for arrow up (implicit ctrl-R):

## arrow up

"\e[A":history-search-backward

## arrow down

"\e[B":history-search-forward

@happygimp0 that doesn't sound like a typical bash setup.

Yeah try having a repo with submodules and sub submodules.

You still have to know what you're doing with a good GUI tool, but having to traverse the directories all the time to create PRs is just ridiculous imo.

Doable, but slower. And I like efficiency/speed. Also, git bash conflict solver is not very nice, not to say cumbersome.. cli is overrated for direct user interaction. I think it just means devs were too lazy to build a proper UI 👀

/Adds fuel to the fire: the yaml hype is the latest abomination of this trend.. punishment for typos without telling you, yay!

@jkommeren switching from keyboard to mouse repeatedly through the day takes a huge hit against efficiency and performance.

Bloated GUIs also impact system performance and can actually steal days of productivity from you per month if they are constantly running in the background.

CLIs will always be a better choice for those who can utilize them. It's fine if you can't, but don't get mad when someone can out maneuver you in a coding challenge.

Also, if you're working on a project that has n+1 submodules, it's a good indicator that the platform is ready to be split into services or at a minimum should have some kind of package state management like npm, gem, or pip.

I've never met a Sr dev or engineer that said, "I hate the cli, it's so buggy and useless." I think that says a lot about skill set for tech leaders.

Yes

I use git extensions for most things, cli for small commands like pull, checkout.

Ask the advanced stuff, I just Google for it and if useful, save it in a bat script...

Same with maven commands... Have a build.bat and depTree.bat in my project folders

ah, the joy of using Magit

I really like the git cli. But also prefer a healthy mix with whatever UI I'm coding in. I really like the UI for basic commits, chunk based staging/restore and quickly resolving merge conflicts with.

For the rest I prefer git cli. It's easy to find solutions for it + I don't need to bother learning multiple UIs doing the same stuff.

Having guake (a drop down terminal) and zsh (bash alternative with op history search) it really is fastest for me to do a "git push origin main" in the cli rathet then finding the button for it and clicking through at least one more dialog.

It's quicker AND I only ever have to learn it once.

When I started out, gitkraken was nice to get over some hurdles beyond the most basic workflow though.

I only use a handful of git commands: commit, diff, merge, rebase, reset, add, rm.

Easy peasy.

Can resonate

for me it's the opposite: I feel like I don't completely understand what's happening with the GUI, and every GUI has its own style, and I don't wanna screw up. Plus, some GUI's like PyCharm's are pretty opinionated and don't let you do stuff that you otherwise could. The only thing I hate about the CLI is having to wait those two extra seconds

btw, Sublime Merge is a great tool for most of the basic git usage

Your job as a programmer is interacting with text, and conjuring words to make sense for computer to do things. Git should be the least of your worries. ;)

i think the cli itself is fine, but i find the terminology unnecessarily confusing

@calmyourtities Its simple once you get the hang of it. I wouldn't stress too much.

Try working on multiple features at the same time - Hint use branches.
Try rewriting your commit history so your reviewer is in awe - Git rebase.

They tried to make it simple with Mercurial, but it has kinda failed.

https://dev.to/unseenwizzard/...

I use git cli by default.
The only exception is for
git add -a -p
git checkout -a -p
It is better be done in gui.
In order to make quick code review for yourself
And to ensure that you are commiting only relevant code to current commit

Git cli is pretty had to understand without a gui graphing out everthing you do. But once you get the hang of it, you should use the cli for doing most stuff outside of making commits.

I use a mixture of both.

When I first entered the industry I was using CLI only, because CLI-evangelist-dipshits on the internet told me, that's what real developers do.

But since I am now 7 years in the field, there were chances to work with superb people. Pretty much all of them used the tools they needed to get the job done and the most important part was motivation to learn. Unwillingness to learn may be the reason why someone does not want to learn CLI as they have clicked things in Windows their whole life, but it can also be the reason not to learn how to use a GUI based program, because you used CLI your whole life and thus defend it and evangelize anti-GUI stances. Either is utter nonsense.

Personal examples: Pretty much all of my git workflow is via CLI, including merge. However rebase in complex scenarios I do in Fork. It is an advantage to see the order of commits, the current branching and encapsulate complex commands into simple Fork calls, so why would I waste time?

This is kinda agreeable Git is notoriously difficult to grasp for beginners. I had a junior colleague who ran git reset hard on master. Luckily you don’t always provide access immediately to such juniors that easy on actual repo that fast. He learnt his lesson though. 😄

Make scripts

Alias

I have one alias which basically says: "All these changes you've made directly to your local master branch? Let's split them to a new branch, commit, push, create PR and send a slack message to team asking for a review"

$ quickpush "This text will become the (slugged) branch name, commit description and PR title"

And sure, sometimes I wanna cherrypick, find which commit deleted a class so I can revert, or forget how to do interactive rebase squash or nuke an accidental API key from a branch history — That's what gitscm docs, stack overflow and github help pages are for.

I prefer GUI (for me it's SmartGit). I had to use CLI for interactive rebase and as soon as GUI could do it on my setup I switched to GUI. It's better for me to use drag'n'drop than edit file.