My Git Knowledge

Interviewer: It's git push origin main now. Get out of here!

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."

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".

So do you guys pronounce it git or jit

Once you understand that everything is similar to a tag, like branch names are basically tags that move forward with each commit, that HEAD is a tag that points to your current commit location in history, and what command moves what kind of tag, it becomes easier to understand.

Suddenly having a detached HEAD isn't as scary as you might think. You get a better understanding of fast forward merges vs regular 3-way merge.

Also understanding that each commit is unique and will always remain in the history and can be recovered using special commands. Nothing is lost in git, unless you delete the .git sub-directory.

git gud

If you're pushing to master, then you're doing it wrong.

If you happen to forget the -m though, you may also need to have mastered exiting vim

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.

Average linux user managing his dotfiles.

Yes I'm guilty of that, only thing more I know is creating new branches.

git blame is another good one

As someone who knows that they know very little about git, this thread makes me think I'm not alone.

Well, if anyone wants to learn more about Git, I can recommend this: https://ohmygit.org

I made do with my IDE, even after getting a developer job. Outside shenanigans involving a committed password, and the occasional empty commit to trigger a build job on GitHub without requiring a new review to be approved, I still don't use the commandline a lot.

But it's true, if you managed to commit and push, you are OK. Even the IDE will make fixing most merges simple.

Learn to use git bisect. If you have unit tests, which of course you should, it can save you so much time finding weird breakages.

Every once in a while, you can refresh your memory by reading the man page.

Or if, like me, you use Emacs, Magit exposes everything quite clearly.

Woah look at mr. fancy pants with his git push arguments.

Seeing Peter Griffin labelled as "HR", I automatically pronounce the R as "Ah" in my head.

I think HR is just ill equipped for technical interviews, but they try to conduct them regardless.

Was denied a position because HR felt my experience "lacked depth" which I still can't understand 3 years later.

Did the same role at a larger company. Had more responsibility than they were giving me. Developed my own tools for job automation. Grew their business from nothing to half a mil a month. Experienced all stages of growth and realized massive success.

After that interview I kept getting technical interviews and getting passed on because I was too senior for the position

Gut clone

git commit -am

I can git... But not CLI. Idk why, but those commands ain't staying in my brain.

One of my system engineers started using TFS a few weeks ago. All he knows how to do is click Sync Changes in vscode and call me if there's a problem.

Relevant xkcd.

My git knowledge:

git clone <url>

How about git commit-tree [Hash] -p branch1 -p branch2 … -m "Dummy Message"

All these comments and no one is going to point out that this is invalid?

The git stage and git commit don't have any terminator, so it's all one "command" and will fail. Then there's a single & between git commit and git push, so it would run in parallel, so it would also fail.

Also, don't git stage . people. Or at least do a git status before to make sure you didn't stage file-with-all-the-production-secrets