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.
Lead of a small team of scripters here. The “Why. Not What” is defo a good way of encouraging cleaner code.
Had to request changes recently on a PR like this, big function with comments telling me what it was doing. When they resubmitted for review they had broken it down into smaller functions with good variable/function naming. following what was going on was much easier
Same strategy here, but recently found myself commenting on the “what”. There was a perfect built-in, but not really readable and I couldn’t figure out how to make it readable, so fine
We solve that problem using naming conventions. Branch names must start with the issue key (we use Jira). You don’t do anything in that branch that’s not part of that issue. If you do, you must prefix the commit message with the issue key that it goes with. The commit itself identifies what changed. The Jira issue provides all the backstory and links to any supporting materials (design docs, support tickets, etc). I have to do a lot of git archeology in my role, and this scheme regularly allows me to figure out why a code change was made years ago without ever talking to anyone.
To be honest, when I ask a candidate about git, I’m looking for them to describe this workflow.
Heck, I have a new person who I tasked with minor config change, just to make sure she knows how to use git in a professional environment
“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.
deleted by creator
To be honest, this is a simple rejection that really doesn’t waste anyone’s time except the perpetrator
Your lead sounds like someone who thinks you’re charged per line of code you commit.
git gud
git: 'gud' is not a git command. See 'git --help'.rekt
deleted by creator
zsh: command not found: rektgit help
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!
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
no
The holy war we deserve.
jean, we pronounce it jean.
The same as in giraffes giving ginormous gifts
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.
For folks unaware, the technical git term, here, is a ‘ref’. Everything that points to a commit is a ref, whether it’s HEAD, the tip of a branch, or a tag. If the git manpage mentions a ‘ref’ that’s what it’s talking about.
Right. I just wanted to keep it as simple as possible.
Honestly I’ve come to realise that being precise is the simplest in the long run
People get overloaded with words. You have to focus on one concept at a time. Let them ask for others.
Oh, no worries, just figured I’d add that extra little bit of detail as it’s a useful hook into a lot of other git concepts.
This I call decapitation
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"Me as an Emacs user, who omits -m on purpose to practice quitting vi in case I really need it
you’re an emacs user who has vi set up as the default editor on your system?
(You can change it altering the $EDITOR env var)
I only use $EDITOR to launch vi from git. Emacs runs as a single process and is always open.
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.
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?
I think someone else said what it actually is in another comment. It’s functionally identical 90℅ of the time for me anyway,and I use CLI and vim on it.
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.
Macs are basically BSD, and Windows has WSL.
But Mac or WSL are not Linux.
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.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 nowgit whoosh --hardWait. It’s that long?
Felt like we joke about the announcement 2 years ago. Time fly lol
Imma be honest I pulled that estimate out of my ass lol, but I feel like it was pre-pandemic? which would put it at at least 4 years ago and so holy shit I’m gonna go cry in a corner because it’s been 4 years since the start of the pandemic
Different workflows.
git send-email
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.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.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
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.
