don’t use the git cli. In my professional life I don’t know a single person who does
I do, I find it much simpler than using the GUIs
Comment on Why Git is hard
Carighan@lemmy.world 10 months ago
A much simpler solution: don’t use the git CLI. And in my professional life I don’t know a single person who does. The shortcomings of git have long been abstracted away and as problematic as the CLI is, it’s now just an internal library of the tools we actually use.
nitefox@sh.itjust.works [bot] 10 months ago
TrickDacy@lemmy.world 10 months ago
I usually use a gui but I know plenty of colleagues who exclusively use cli. I’ve never understood if it’s an ego thing or what but it’s an incredibly popular way to use git
Buckshot@programming.dev 10 months ago
I exclusively use CLI, it’s not ego at all, I simply find typing what I want to be quicker than clicking buttons. I’ve written a bunch of aliases to automate my common workflows.
When I need to help a colleague who’s made a mess of something, I can easily give them the command to fix it rather than finding the right options in their GUI of choice and it’s often because of some broken abstraction in the GUI they got into the mess in the first place.
TrickDacy@lemmy.world 10 months ago
Yeah there are totally commands I use daily, but the visualization involved in looking at the log and available branches (which is a constant use case) is much easier in a gui for me. In fact I’d go as far as saying logs, diffs, and branching in cli are neigh unusable. The buttons I click while in the gui (like fetch/pull/commit) are largely used because at that point (after finding and checking out the right branch, etc) it would be slower to switch back to cli.
I only mentioned ego because I’ve seen multiple junior devs struggling with the command line resist using a gui even when it solves a specific problem they are having quite easily. To each their own though.
Cyno@programming.dev 10 months ago
I use the CLI for simple commands, especially if helping someone on another PC and I don’t have access to my preferred tool, but I honestly don’t get people who use it religiously and never even try tools with GUIs. The convenience of being able to easily see the commit history, scroll through it, have a right click context menu or ability to just click it and see file changes (and then right click those files for additional options), is just something I can’t abandon. Nowadays even the aliasing can be replicated in those tools if they support creation of custom commands so even that is a moot point - with some setup you can be as fast as with a CLI.
MajorHavoc@lemmy.world 10 months ago
I do have a huge ego, but I’ll claim it’s a total coincidence that I use CLI git.
My main reason to use mostly CLI is the better error messages I get when something goes wrong.
My secondary reason is that my preferred GUI tools for git didn’t used to have support for operations I do often such as ‘cherry-pick’ and ‘rebase’. I think that is mostly solved now, but my habits change slow and I’m used to the CLI.
TrickDacy@lemmy.world 10 months ago
Haha fair. My experience though, is that cherry picking is easily done in gui and I’ve honestly never attempted on cli because it only takes me three clicks in Fork
MajorHavoc@lemmy.world 10 months ago
Yeah. Cherry pick was the killer feature for CLI back when I was forming habits. Seems like it’s built into most tools now, which is really nice.
Carighan@lemmy.world 10 months ago
Which to me is just wild unless you’re doing something you wouldn’t want to use an IDE for - and that’s not actually that many professional things, if I’m being honest. But if you use an IDE, then it’s far easier, faster and importantly doesn’t take you out of your mental flow to just use the built-in git abstraction of that IDE.
mr_satan@monyet.cc 10 months ago
O that’s my pet peeve, I hate integrated git GUI’s in IDE’s. The only useful thing is file and code highlight for changes, other than that I disable that stuff as fast as possible.
mr_satan@monyet.cc 10 months ago
There are things that my GUI of choice lack, so I occasionally type out a command, although I did also bind a couple of commands to GUI buttons, so there’s that.
chunkystyles@sopuli.xyz 10 months ago
I mostly agree. The caveat to this is I’ve had to learn CLI for programmatic use cases like automation.
atheken@programming.dev 10 months ago
I’ve used the git cli exclusively for more than a decade, professionally. I guess it varies wildly by team, but CLIs are the only unambiguous way to communicate instructions, both for humans and computers. That being said, I still don’t mess around with rebase for anything, and I do use a gui diff tool for merge conflict resolution. Practically everything you need to do with git can be done with like 10 commands (I’m actually being generous here, including reset, stash, and tag).
technom@programming.dev 10 months ago
Rebasing has a worse reputation than it deserves. It’s something you just get used to - just like how git use is, when you started using it. There are a couple of strategies to make it easier and less anxiety inducing:
After a while, rebasing becomes as simple as commit or merging.
atheken@programming.dev 10 months ago
Rebasing and merge conflicts are the top ways that git can turn into a mess. I know that rebasing could (in some circumstances) make merge conflicts less of an issue, but I just mostly think the value of “commit grooming” is overrated. I don’t want to argue about this, if you like doing it, go ahead.
clif@lemmy.world 10 months ago
I had to check and make sure I didn’t type the comment above because it sounds exactly like me.
All UIs do things slightly differently, the CLI is always exactly the same… Everywhere. UI for non trivial conflict resolution? Definitely. For everything else, CLI.
And, I’m also reticent to use rebase unless I have to. Gimme that good ole FF :)
nous@programming.dev 10 months ago
I dont know about that… Never found they help that much in conflict resolution. They give you some nice buttons for accept their or accept our changes but really I find more often than not those are what breaks code as you often want a mash-up of both sides - which needs to be manually done even in UIs.
Otherwise it is just find the marked sections in the file, and make it look like what you want it to after the merge/rebase. And that is the hardest part - figuring out what it should look like. Which is made easier if you only ever have small commits and merge back to master frequently minimizing the amount your branches drift from each other.