My Git Knowledge
My Git Knowledge
176 comments
-
-
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 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.
-
-
“Fixed issue with ssl python libs,” or “Minor bugfixes.”
In other news, never work more than one person on a branch (that's why we have them). Make a new related issue with its own branch and rebase whenever necessary, and don't even think about touching main or dev with anything but a properly reviewed and approved PR (in case they aren't already protected), or I'll find and report you to the same authority that handles all the failed sudo requests!
Also, companies that disable rebasing are my bane. While you can absolutely do without, i much prefer to have less conflicts, cleaner branches and commits, easier method to pull in new changes from dev, overall better times for the reviewer, and the list goes on. Though, the intern rewriting multiple branches' history which they have no business pushing to is also rather annoying.
-
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.
-
Why does
git rebase
work sometimes?
Yeah git can get quite complicated when there ate lots of people working on the same things.
-
It's not git that's complicated. The work is complicated. git is just one of the tools that programmers use to manage the complexity.
I also think that some people get too hung up on having a "clean" history, and trying to "fix" the history after it has already occurred. I usually have enough problems to worry about in the present, without also trying to worry about the past.
-
-
Your lead sounds like someone who thinks you're charged per line of code you commit.
-
-
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".
-
I might be the dumb one in this one, but HR asked me if I know "design patterns".
"I mean, yes, I know some design patterns. Any specific?"
"No, just if you are familiar with design patterns."
"I mean, there are builder, strategy, sigleton, factory etc. Is the question really not more specific?"
"My paper just asks if the dev is familiar with design patterns."
"Ok. Yes."
-
Ahh, that must be where the DEVs use LUA and JAVA and whatever else always irks me. grumps irkily, for emphasis and illustration
-
-
So do you guys pronounce it git or jit
-
Is that what we're going to do tonight, we're gonna fight?
-
lol it's on now!
-
-
I pronounce it the correct way you silly git!
-
Git off my lawn. Git!
-
-
Don't start this. Its not like gif. Git is clearly pronounced like git. There is no possible argument you can make otherwise.
-
Same could be said about gif yet here are
-
-
The holy war we deserve.
-
no
-
jean, we pronounce it jean.
-
The same as in giraffes giving ginormous gifts
-
So, it's pronounced "jight"?
-
-
Yit
-
-
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.
-
This I call decapitation
-
git gud
-
git: 'gud' is not a git command. See 'git --help'.rekt
-
-
git rekt -
zsh: command not found: rekt -
git help
-
-
-
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 bisectthat can narrow down the exact commit that broke your app is an absolute life saver. Knowing how togit cherry-pickis also a git skill professionals should be comfortable doing. Migrating work from one branch to another without merging the entire branch is pretty common. -
If you happen to forget the -m though, you may also need to have mastered exiting vim
-
The day I configured
gitto use Geany for commit messages with a separate config specifically tuned for this, it improved my life by 300%~$ cat ~/bin/gitedit #!/bin/sh exec /usr/bin/geany -i -s -t -c ~/.config/gitgeany $@Then in git config:
git config --global core.editor "gitedit" -
What developer uses Linux in professional work? Maybe for on the side stuff but I haven't seen any corporate Linux machines.
-
Hello, I use a linux machine for dev work and all the servers and containers I touch are linux, all managed through gitlab CI/CD.
git scm is my daily driver and I use it for not taking and documentation as well as active python development.
-
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. -
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.
-
Macs are basically BSD, and Windows has WSL.
-
Everyone at Mentor Graphics did before it got gobbled up by Siemens in 2017. I don't know if they still do.
-
-
If you're pushing to
master, then you're doing it wrong.-
Yeah
mainhas been the defacto default branch name for like half a decade now -
Different workflows.
-
git send-email
-
-
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
-
Yes, I think we all like to blame git
-
-
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
-
Another good one, entirely browser based, is https://learngitbranching.js.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.
-
These threads drive home the point that a GUI of some sort is far superior for most users. I use git kraken, but in the past I've used git extensions as well, and I take advantage of so much more git has to offer than pretty much everyone here.
I swear people just want the cli to be better so they claim it is, but I really don't get how. Especially for quickly scanning the repo, doing diffs, commiting partial files, history, blame, etc.
-
-
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.-
With automated CI, I've had very few times where bisect is useful. Either the bug was introduced 1-2 commits ago, or it's always been there and the exact commit is irrelevant to the solution, since you just fix it forward.
-
-
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 pusharguments.-
I use this in my bash profile in case anyone else finds it helpful. Usage is:
gao fixing a typo
function gao() { git add . git commit -a -m "$*" git push origin `git rev-parse --abbrev-ref HEAD` }
-
-
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
-
git commit -am-
You don't just git to edit past commit
-
-
I can git... But not CLI. Idk why, but those commands ain't staying in my brain.
-
Just need more terminal time, it comes with experience.
You should run Arch, btw
-
The commands are notoriously poorly named. The underlying tech is cool and sensible, the text interface isn't.
-
-
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.
-
How about
git commit-tree [Hash] -p branch1 -p branch2 … -m "Dummy Message" -
My git knowledge:
git clone <url> -
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 agit statusbefore to make sure you didn't stagefile-with-all-the-production-secrets-
The comma and ampersand are plain English, not one big command
-
Pffft... all of my api keys are open source. Having more eyes on them will make them more secure!
-
176 comments
Interviewer: It's
git push origin mainnow. Get out of here!👆 This guy gits it
Employees who push first win and get to leave early. The rest would be the suckers who would merge whatever mess left behind by the early employees.
Single person operation pushes directly to main.
Our changes land in main at my workplace, once they've received a code review and all CI checks pass (which includes tests, E2E tests, etc). We use feature flags rather than feature branches, so all diffs / pull requests are against main. We use continuous deployment which means changes are automatically deployed once landed. Changes roll out just to employees, then to servers used by a small percentage of users (2% I think), then everywhere. All risky changes are gated by feature flags so they can be enabled or disabled without a code push.
That's kinda the whole point of trunk-based development.
No kidding. Never push to main, and you most likely can’t. While I get the joke of the meme, I’d send the person packing if they don’t understand branching, and branch flow, rebasing or reverting. Even if you look up the command or do it all through your IDE, understanding the workflow of using git is important
They laid off everyone else so there's no one to the code reviews now. So fuck it, we'll do it live!
I never worked anywhere where they had this set up. I would push to branches and make pull requests, but always work in the production environment.
I was mainly working as a data engineer though so that's probably why. It's hard to have test environments since you can't replicate all the enormous amounts of data between environments without huge costs.
Do you not use a fork as your origin, separate from the production upstream repo? I’ll push to my fork’s main branch for small or urgent changes that will definitely be merged before anything else I’m working on.
You kids with your fancy branch support back in my day we had CVS and RCS liked it
https://en.m.wikipedia.org/wiki/Revision_Control_System
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.
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.
git checkout ma<tab>If you don't have autocomplete set up for your shell, get it working. If someone has a different branch named
ma..., ask if you can delete it, and get your team to adopt a decent branch naming convention.I think the reasons was ridiculous. The fact that people didn't like the word master anymore. But I'm used to it now, so fine, let's use main. It makes sensitive people feel better.