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.
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
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.
No I know. But it was “good enough” for the company and we never had any serious issues working that way either. If someone pushed a faulty commit, we just reverted it and reloaded the data from the source system.
A lot of companies have kind of bad solutions for this sort of stuff, but it’s not talked about and nobody is proud of it. But it keeps the environments simple to work with.
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”.
Yeah that’s fair, I can see how that would be annoying for sure. I think that frustration stems more from company policy though, not necessarily the standard changing. And you know what they say, there’s nothing certain in this world except for death, taxes, and standards changing
It is trash code for sure, but most of the world’s code is trash, so we do have to accommodate trash code when we design stuff. That said, they do need to do this to comply with laws and make sure code doesn’t get lost (it’s finance), and this was the easy way to do it. Doing it better would have taken time and attention away from other stuff.
And standards do change, but they usually change to accommodate new features, or a new software product displaces an old one. I don’t really know any tech standard that changed because of cultural reasons. Point is, change is a cost. It may be worth to pay the cost, but here the benefits were US cultural sentiments that most of the world doesn’t care about.
And the stupid thing is that even when standards change, you are not usually labelled as culturally out of touch if you don’t follow it. Most big orgs don’t follow changes that they don’t need to. Nobody calls you a bigot for running COBOL mainframes in 2023, but they might if you predominantly have master branches.
I guess my perspective is that some people I know were mildly annoyed before lunch about it one day two years ago, since nobody cares about US identity politics, with my personal opinion being if the US didn’t fill up its for-profit prisons with black people who it then those prisons profit off of (just as an example), the word master would not bite as hard, and the whole thing would be moot.
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 really wish to work in a team where people have naming conventions for branches that are concerned about stuff like that. Must’ve been a nice place to work at.
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.
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.
I can follow along re-typing the same commands told to me by a more senior dev just like any average monkey!
This reminds me of something I made a long time ago:
Since I am calling myself dumb, I estimate my progress to be somewhere perhaps at the 20th percentile marker? :-D One of these days I’ll RTFM and rocket all the way up to be dumb enough to properly qualify for “below average”! :-P
The first time you manually push like that, you can add the -u flag (git push -u origin master) to push and set the branch’s default upstream. Afterwards, a plain git push while that branch is checked out will push the branch to that default upstream. This is per-branch, so you can have a main branch that pulls from one repository and a patch branch that pulls and pushes to a different repository.
My strategy is to just type git push and get some kind of error message about upstream not being set or something. That’s a signal for me to take a second to think about what I’m actually doing and type the correct command.
Interviewer: It’s
git push origin mainnow. 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?
👆 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.
Hey there were like 3 of us lol! No joke that’s what I have done at a few of the smaller shops as an SRE/System Engineer
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.
We did a similar way with tag based releases, first a test tag, the production tag when signed off.
That’s kinda the whole point of trunk-based development.
Lol no it is not
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.
deleted by creator
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.
No I know. But it was “good enough” for the company and we never had any serious issues working that way either. If someone pushed a faulty commit, we just reverted it and reloaded the data from the source system.
A lot of companies have kind of bad solutions for this sort of stuff, but it’s not talked about and nobody is proud of it. But it keeps the environments simple to work with.
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
You mean “I just sent you zip file with my new changes via email, get fucked looser”?
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 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.
Just ran
git initin a brand new empty directory, and while it did create amasterbranch 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
masterbranches are eternal.I’ve had a company that had some automation built on git but below GitLab that would not let you delete
masterbranches. Whenmainbecame 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
mainas the default, and then had to change it over tomasterso that it lined up nicer with the rest of the stuff, I’ve had a few dozen orphaned undeletable emptymainbranches 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”.
Yeah that’s fair, I can see how that would be annoying for sure. I think that frustration stems more from company policy though, not necessarily the standard changing. And you know what they say, there’s nothing certain in this world except for death, taxes, and standards changing
It is trash code for sure, but most of the world’s code is trash, so we do have to accommodate trash code when we design stuff. That said, they do need to do this to comply with laws and make sure code doesn’t get lost (it’s finance), and this was the easy way to do it. Doing it better would have taken time and attention away from other stuff.
And standards do change, but they usually change to accommodate new features, or a new software product displaces an old one. I don’t really know any tech standard that changed because of cultural reasons. Point is, change is a cost. It may be worth to pay the cost, but here the benefits were US cultural sentiments that most of the world doesn’t care about.
And the stupid thing is that even when standards change, you are not usually labelled as culturally out of touch if you don’t follow it. Most big orgs don’t follow changes that they don’t need to. Nobody calls you a bigot for running COBOL mainframes in 2023, but they might if you predominantly have
masterbranches.I guess my perspective is that some people I know were mildly annoyed before lunch about it one day two years ago, since nobody cares about US identity politics, with my personal opinion being if the US didn’t fill up its for-profit prisons with black people who it then those prisons profit off of (just as an example), the word
masterwould not bite as hard, and the whole thing would be moot.Obligatory
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…yeah, I already said that if there is another branch starting with those letters it should be deleted. You need a naming convention.
I really wish to work in a team where people have naming conventions for branches that are concerned about stuff like that. Must’ve been a nice place to work at.
Whoever named the “final final fixed” one seems to have missed the point of version control. 😑
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.
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.
Normal distribution curve meme makes sense here - experts and noobs can both
git pushsafely (but for different reasons)I can follow along re-typing the same commands told to me by a more senior dev just like any average monkey!
This reminds me of something I made a long time ago:
Since I am calling myself dumb, I estimate my progress to be somewhere perhaps at the 20th percentile marker? :-D One of these days I’ll RTFM and rocket all the way up to be dumb enough to properly qualify for “below average”! :-P
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?The first time you manually push like that, you can add the
-uflag (git push -u origin master) to push and set the branch’s default upstream. Afterwards, a plaingit pushwhile that branch is checked out will push the branch to that default upstream. This is per-branch, so you can have amainbranch that pulls from one repository and apatchbranch that pulls and pushes to a different repository.My strategy is to just type
git pushand get some kind of error message about upstream not being set or something. That’s a signal for me to take a second to think about what I’m actually doing and type the correct command.… google the error and randomly try stack overflow answers without really understanding them.
( I have changed)