61
u/apnorton 15h ago
Just git push --force, deploy to prod at 4:59pm, and enjoy your weekend.
Follow for more tips on how to make your coworkers love you.
7
134
u/AskPositive9792 16h ago
That's how you punish someone who commits on Friday
57
u/raddaya 16h ago
Nothing wrong with committing to the lower branches tbh
50
u/nickcash 15h ago
Nothing wrong with committing to main. Just don't do a Friday release. that's madness
5
43
54
u/InSearchOfTyrael 16h ago
you guys retest things?
24
u/Forward_Yam_4013 16h ago
Before 6 PM, yes. After that you just eyeball it and if it looks good you click merge.
13
u/the_poope 16h ago
And after 6 PM and three beers at the Friday bar you skip the eyeballing and just click merge
4
u/Bubbaluke 15h ago
We physically can’t merge until the tests pass. Fortunately it’s all automated on push and they only take like 20 minutes.
3
u/Suspicious_State_318 15h ago
Wait your CI takes 20 minutes? Are you running integration tests too? For us we only run unit and contract tests and then have bugbot run on every push.
3
u/Bubbaluke 13h ago
Small codebase, it’s like ~800 unit tests and some linters. Functional tests get started by hand because they have to run on specific hardware with serial connections, etc. those still don’t take long.
8
u/rabbit_wizard 16h ago
Places where one branch changes behavior affecting others yep. Sometimes unit/integration tests are enough based on the PR
10
u/Apprehensive-Lychee2 14h ago
You guys use Rebase??
7
u/NamityName 8h ago
Yes. It is safer as the resulting merge is a simple fast forward and not a 3-way merge
1
u/Apprehensive-Lychee2 7h ago
Can you actually explain that a little more, I have never has a situation occur where rebase was preferred.
5
u/NamityName 5h ago
The normal merge is called a 3-way merge. It compares 3 commits to determine what the new commit will look like: the HEAD of the branch being merged, the HEAD if the branch being merged into, and the common ancestor. The end result is a commit that does not necessarily match either of the two branch heads.
However, if the common ancestor of the feature branch being merged is the HEAD of the branch being merged into, Git does a fast forward merge instead of a 3-way merge. It will simply move the base branch's HEAD to the HEAD of the branch being merged. The base branch will exactly match the feature branch, guaranteed. No questions. No funny business. No side effects. The code you reviewed in the feature branch will be the code after the merge.
Getting back to rebasing. A rebase will move the branch being rebased and all of its commits going back to the common ancestor to the HEAD of the base branch. The rebase process will resolve any conflicts. Then, when you merge, git will do a fast forward merge instead of a 3-way merge.
3
u/__Invisible__ 5h ago
only fast forward allowed, so we rebase master on our branch and merge again.
5
u/RandolphCarter2112 16h ago
Or your code gets rolled back from production because it was in the same release as another unrelated change that was bad and wrong and needed to be backed out.
6
11
u/dontletthestankout 16h ago
Who pushes on a Friday? That's always a bad idea
20
u/Soccer_Vader 15h ago
The goal isn't to not push anything on Friday, the goal is to not deploy anything to prod on Friday. Who tf is not pushing and testing anything in pre-prod for one whole day lol.
24
u/xaomaw 16h ago
Yeah, never Push on friday.
Instead, push on thursday and deploy on friday.
7
u/PM_ME_FIREFLY_QUOTES 16h ago
Why not? I dont work on the weekends. If the release crashes, I dont want to be anywhere near that dumpster fire.
4
u/Meloetta 13h ago
If you release on a Friday, someday that "I don't work on the weekends" won't be true anymore.
5
1
5
u/Koppany99 16h ago
Depends on the exact environment. For us we have dev and prod workspace, so pushing to dev should not affect any productipn stuff, if it does, the fault is on someone connecting prod stuff to dev stuff.
5
2
u/PhantomTissue 15h ago
Me and my team who’s PR requirements is 15 a week. If it breaks prod, great, more PRs.
3
u/Kevadu 15h ago
You have a PR requirement?!
2
u/PhantomTissue 15h ago edited 15h ago
Yep. Testing? Doesn’t happen. Reviewing? Doesn’t happen. Designs? Doesn’t happen. Had a team meeting yesterday where we considered standing up a bullshit package to commit literally anything to just to hit this absurd requirement. People are making changes to agent.md and readme files with “revised for clarity” daily. It’s so bad that Ops joke is literally an hourly occurrence. Most PRs are merged within 1-2 minutes.
In fact, a lot of the team actually pushes code they know will break the pipeline because a bugfix means another PR. Management of this team has become a satire come to life.
2
u/Kevadu 14h ago
Sounds like a disaster on every level. Who came up with this policy?
5
u/PhantomTissue 14h ago
Organization director. So my managers managers manager. It is exactly as disastrous as you think it is and then some.
I’m applying to literally everything and anything right now because I’m watching this org crumble in real time.
1
u/DisheveledJesus 5h ago
This is ezpz just make every shippable unit of change its own PR. Granular iteration!
1
u/HRApprovedUsername 13h ago
To a repo? Why wouldn’t you?
1
u/dontletthestankout 13h ago
I mean as long as there is no pipeline attached to said push it's fine but where I've worked push was synonymous with deploy
3
1
u/GenericFatGuy 11h ago
I'll push to the personal branch I'm working on. I'm not pushing to main until the coding is done.
1
2
2
u/frikilinux2 15h ago
And your boss wants it now because it's end of Sprint and metrics get weird if you don't
2
4
2
u/nicuramar 9h ago
Why? Don’t people have pipelines that automatically do this in the PR? In my experience there is rarely a need to rebase manually.
1
1
u/Poat540 8h ago
Why rebase just git merge the main branch in
1
1
u/nicuramar 1h ago
If you end up with a squash, sure. But for complex situations, definitely. Much simpler to conflict resolve in many situations.
1
u/Magnuscaligo 7h ago
I think this is even describing those automated pipelines. You might need to manually restart them, but you still have ti watch it and wait for it to merge without issue, so mentally you might need to keep it in the back of your mind for a few hours instead of relaxing on a Friday
0
u/EvaristeGalois11 7h ago
Rebease and turn on auto merge? Failing pipeline will notify you by email or by slack
At least this is the setup I pretty much always worked with
1
u/rix0r 6h ago
what if their are conflicts?
2
u/nicuramar 1h ago
Yes, so you can take my comment to mean “in my experience there are rarely conflicts” :)
1
1
1
u/k8s-problem-solved 16h ago
Been working on a native app pipeline today. 20000 tests across emulators etc, 10gb build artifacts. No TLC for pipeline for a while and now takes 1 hour to run.
Super busy with commits as well. Miss the gap, thats another 1 hour for you
Oh 1 or 2 flaky tests in there as well. 19998 of 20000 tests pass. Fuxk you lol
I am making it better
1
u/MapNo2659 14h ago
I feel this on a spiritual level. Merging conflicts always seem to pop up at the worst possible time. Anyone else have a horror story about a merge gone wrong?
1
u/Spacer3pt0r 14h ago
I ma shocked so many people don't use claude to rebase stuff nowadays. It is the one task that i have never had it mess up and i do it a lot.
1
u/DogmaticParadigm87 14h ago
Somebody always merges a one-line typo fix the second the approval lands. Same person every time, too.
1
1
u/NibblesIndexus 10h ago
This is why we defer testing to the merge queue, no such problems and no dozen test runs for a pr. The savings pay for bigger test runners so we're done testing faster also. Big happy
1
1
u/LegitimatePants 3h ago
And due to the rebase, it sees new commits pushed and resets your approvals
1
1
180
u/Genkics 16h ago
When you want to go in weekend but Jenkins decide otherwise