Interviewer: It’s git push origin main now. Get out of here!
It’s git push origin branch and then merge after submitting a pull request from branch to main after a successful lint check, build, deployment, and testing in a non-production environment, and PR approval. What kind of wild west operation allows pushing 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.
What kind of wild west operation allows pushing directly to main?
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!
We just had a customer escalation caused by exactly this. One group relied too heavily on tribal knowledge for code reviews and didn’t want any other process. Once the tribal elders were gone, no one knew all the things to look for, and there was no other way to catch issues
As a Continuous Integration and Test guy, I was standing in the corner yelling “I thought you were DevOps. Where’s the automation?” Fine, Puppet/YAML doesn’t work with a traditional build and test, but you could have done syntax validation and schema validation that would have caught before the code review could have happened (and I showed them how a year ago, even offered to do it for them) and set up some monitoring to discover when you break stuff, before customers discover it.
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.
If it’s a private repo I don’t worry too much about forking. Ideally branches should be getting cleaned up as they get merged anyway. I don’t see a great advantage in every developer having a fork rather than just having feature/bug branches that PR for merging to main, and honestly it makes it a bit painful to cherry-pick patches from other dev branches.
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.
There are many strategies for maintaining test environments for that kind of thing. Read-only replicas, sampling datasets for smaller replicas, etc. Plenty of organizations do it, so it’s not really an excuse, imo.
You kids with your fancy branch support back in my day we had CVS and RCS liked it
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.
Normal distribution curve meme makes sense here - experts and noobs can both git push safely (but for different reasons)
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 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.
git checkout ma<tab>
mai_new_chenges
march_deploy_second_final_final_fixed
main_fixes
mast_not_farget_to_delete_it
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
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.
“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.
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.
I find the “clean history” argument so flawed.
Sure, if you’re they type to micro commit, you can squash your branch and clean it up before merging. We don’t need a dozen “fixed tests” commits for context.
But in practice, I have seen multiple teams with the policy of squash merging every branch with 0 exceptions. Even going so far as squash merging development branches to master, which then lumps 20 different changes into a single commit. Sure, you can always be a git archeologist, check out specific revisions, see the original commits, and dig down the history over and over, to get the original context of the specific change you’re looking into. But that’s way fucking more overhead than just looking at an unmanipulated history and seeing the parallel work going on, and get a clue on context at a glance at the network graph.
I like to rebase on my feature branches before the PR because it’s a gift to my future self that resolves all the conflicts (if any) before my work goes in. I just find trying to figure out how those conflicts got resolved when there are a bunch of merges in more difficult if there’s a problem later. It’s easier to understand for me. YMMV, this does not work for everyone. Etc etc.
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.”
One of my first interviews in Canada I was asked what a “zed-index” is and was like what? A what now?
Whenever I hear someone say “zed”, it always throws me for a loop. I follow a Canadian streamer, and they use it in place of “zero” the letter “zee”.
I’m not Canadian, but as a Brit I also say Zed instead of Zee but I’ve never heard someone say Zed instead of Zero. WTF.
So do you guys pronounce it git or jit
Don’t start this. Its not like gif. Git is clearly pronounced like git. There is no possible argument you can make otherwise.
fortunately this one isn’t an acronym. so the pronunciation is obvious. 😊
Acronyms are still pronounced like the words they most closely resemble though
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.
Honestly I’ve come to realise that being precise is the simplest in the long run
Oh fuck. I didn’t think of that. Than you for reminding me.
Edit: Ah but you can only run this in your local repo. If you happen to push anything, you might not be able to run it on the remote. Many DevOps platforms won’t allow it.
