866

submitted 4 days ago* (last edited 4 days ago) by Maven@lemmy.zip to c/programmer_humor@programming.dev

336 comments fedilink hide all child comments

Bonus

you are viewing a single comment's thread
view the rest of the comments

[-] _____@lemm.ee 122 points 3 days ago

let's turn this into a constructive angle for future devs and current juniors: just learn git cli, I promise you it is much simpler than it seems.

all those memes about git having like a thousand commands are true, but you really will only use like 7 at most per month.

learn push, pull, merge, squash, stash, reset, im probably missing like one or two

I promise you again: it is much simpler than it seems. and you won't have to use these stupid git GUI things, and it will save you a hassle because you will know what commands you are running and what they do

short disclaimer: using git GUI is totally fine but low-key you are missing out on so much

[-] MajorasMaskForever@lemmy.world 18 points 3 days ago

Every time I mentor a dev on using git they insist so much on using some GUI. Even ones who are "proficient" take way longer to do any action than I can with cli. I had one dev who came from SVN land try and convince me that TortoiseGit was the only way to go

I died a little that day, and I never won her over to command line despite her coming to me kinda regularly to un-fuck her repository (still one of the best engineers I ever worked with and I honestly miss her... Just not her source control antics)

[-] dave@feddit.uk 6 points 3 days ago

So I’m normally a command line fan and have used git there. But I’m also using sublimerge and honestly I find it fantastic for untangling a bunch of changes that need to be in several commits; being able to quickly scroll through all the changed files, expand & collapse the diffs, select files, hunks, and lines directly in the gui for staging, etc. I can’t see that being any faster / easier on the command line.

[-] MajorasMaskForever@lemmy.world 3 points 3 days ago

Heh, I guess this shows my corporate software dev experience. Whenever I've taught git workflows it was always paired with a work ticketing system where any changes you were making were ideally all one single set of changes. If you need a feature or bug fix someone else was doing that was being done on another branch which you could pull into your code early and for tracking purposes we always made sure the other person merged into main first. The only time I've seen per line manipulation with git was when someone made a ton of changes in a file and wanted to revert a handful of lines.

Everything else you mentioned I've had a web git host like gitlab or bitbucket for, but I kinda put that more into peer review workflow than git itself