Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Aye, most of my 10 year career in web dev is pretty much those commands. However, some advanced git concepts are worth diving into. Stuff like git bisect that can narrow down the exact commit that broke your app is an absolute life saver. Knowing how to git cherry-pick is also a git skill professionals should be comfortable doing. Migrating work from one branch to another without merging the entire branch is pretty common.
I once had HR ask if I was familiar with G-I-T ( she spelled it out), for a moment, my only thought was "wtf is G-I-T".
The thing is that for a majority of cases, this is all one needs to know about git for their job. Knowing git add, git -m commit "Change text", git push, git branch, git checkout , is most of what a lone programmer does on their code.
Where it gets complicated real fast is collaboration on the same branch. Merge conflicts, outdated pulls, "clever shortcuts," hacks done by programmers who "kindof" know git at an advanced level, those who don't understand "least surprise," and those who cut and paste fixes from Stackexchange or ChatGPT. Plus who has admin access to "undo your changes" so all that work you did and pushed is erased and there's no record of it anymore. And egos of programmers who refuse any changes you make for weird esoteric reasons. I had a programmer lead who rejected any and all code with comments "because I like clean code. If it's not in the git log, it's not a comment." And his git comments were frustratingly vague and brief. "Fixed issue with ssl python libs," or "Minor bugfixes."
If it’s not in the git log, it’s not a comment.”
This is so incredibly dumb, though I’m sure I don’t have to tell you this. That comment will be buried in the git log if anyone ever fixes a typo on that line.
I had a programmer lead who rejected any and all code with comments "because I like clean code. If it's not in the git log, it's not a comment."
Pretty sure I would quit on the spot. Clearly doesn't understand "clean" code, nor how people are going to interface with code, or git for that matter. Even if you write a book for each commit, that would be so hard to track down relevant info.
Yeah, I think that guy only got a superficial understanding of what Uncle Bob was saying.
My policy as a tech lead is this: In an ideal world, you don't need the comment because the names and the flow are good. But when you do need the comments, you usually really need those comments. Anything that's surprising, unusual, or possibly difficult to understand gets comments. Because sometimes the world is not ideal, and we don't have the time or energy to fully express our ideas clearly in code.
My policy on SCM logs is that they should be geared more towards why this commit is going in, not what is being done. And what other tickets, stories, bugs it relates to.
But when you do need the comments, you usually really need those comments.
It’s nice to see you sharing my experience. My code is either uncommented or very severely commented with comment-to-code ratios of 10:1 or more. I hate the files that are soo green… :(
git blame is another good one
Gut clone
git commit -am
As someone who knows that they know very little about git, this thread makes me think I'm not alone.
I think advanced git knowledge, like RegEx, is the exception, while the norm is to know the tiny handful of day to day useful bits
How is regex git knowledge? I guess you can use regular expressions with git grep but it's certainly not a git-oriented concept...
I don't even know how to respond to this considering it has nothing to do with what I said...
There are at least two ways to parse your statement, and they interpreted it differently from your intention.
I guess, if you ignore the comma...
Rereading it, I now understand what you meant. I interpreted the "like regex" as an example of advanced git knowledge. I'm not sure the comma helps make it unambiguous though.
Yeah, reading it again and I can see that interpretation...
This is why you shouldn't rely on yourself alone for proofreading your writing, I probably could have read that a hundred times and not seen another way to read it without someone else pointing it out
If you happen to forget the -m though, you may also need to have mastered exiting vim
What developer uses Linux in professional work? Maybe for on the side stuff but I haven't seen any corporate Linux machines.
Everywhere I've worked, you have a Windows/Mac for emails, and then either use WSL, develop on console in Mac since it's Linux, or most commonly have a dedicated Linux box or workstation.
I'm starting to see people using VSCode more these days though.
I thought Mac was unix which is similar but different from Linux?
They're both UNIX-like, i.e. they both implement the POSIX specification and are therefore in many ways compatible.
But yeah, modern macOS is more directly derived from the original UNIX operating system.
Linux was instead implemented from scratch to be compatible with UNIX.
The entire IT ecosystem is built around Linux, because it's so prevalent in servers, containers, budget hardware and the open-source community.
Yes, many companies don't understand that and expect their devs to be productive on Windows. But in my experience, that's an uphill battle.
In my company, we get very little IT support, if we decide to order a Linux laptop and we still have significantly less trouble with getting things set up to start coding.
Not to mention the productivity boost from having all the relevant technologies natively available + being able to script whatever you want.
git gud
git: 'gud' is not a git command. See 'git --help'.
rekt
git rekt
Interviewer: It's git push origin main now. Get out of here!
Fuck those that use main. If you're working on a library fork that has main and a project that has master you're bound to invert the two.
"What do you mean I can't checkout main? Oh right, here it's master..."
For once that we had a standard, it had to be ruined.
Fuck those that use master. If you're working on a library fork that has main and a project that has master you're bound to invert the two.
"What do you mean I can't checkout main? Oh right, here it's master..."
For once that we had a standard, it had to be ruined.
The standard is now main.
The standard is now main.
Git itself does not use that standard yet, so at least now there are two competing standards.
I get that there are cultural reasons why the word master was loaded language, but still, it's not like institutional racism will go away. Meanwhile, the rest of the world which doesn't struggle with the remnants of slavery has to put up with US weirdness.
Git itself does not use that standard yet, so at least now there are two competing standards.
Just ran git init in a brand new empty directory, and while it did create a master branch by default, it also printed out a very descriptive message explaining how you can change that branch name, how you can configure git to use something else by default, and other standards that are commonly used.
Also, there's nothing saying your local branch name has to match the upstream. That's the beauty of git - you have the freedom to set it up pretty much however you want locally.
Yeah, that's what I'm saying, there is no one standard now. The stupid thing is all the problems that causes is mostly because there used to be one, and stuff written assuming master branches are eternal.
I've had a company that had some automation built on git but below GitLab that would not let you delete master branches. When main became a thing, they just started hard protecting those as well by name. It's because of regulatory, and they are very stingy about it.
So when I created a few dozen empty deployment repos with main as the default, and then had to change it over to master so that it lined up nicer with the rest of the stuff, I've had a few dozen orphaned undeletable empty main branches laying around. A bit frustrating.
That said, the whole thing is just that. A bit frustrating. If it makes some people feel better about themselves, so be it. I am blessed in life enough to take "a bit frustrating".
Just set your default behavior.
I have only ever used simply "git push". I feel like this is a "how to say that you barely know how to use git without saying that you barely know how to use git" moment:-D.
Hold Up
You can default git to using your current branch and a specific upstream so you don't have to put anything after git push
Thanks didn't know that
Has git never told you that you should use git push -u origin <branch> when you push a new branch for the first time?