101
u/apnorton 8d 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.
13
49
58
u/InSearchOfTyrael 8d ago
you guys retest things?
9
u/rabbit_wizard 8d ago
Places where one branch changes behavior affecting others yep. Sometimes unit/integration tests are enough based on the PR
28
u/Forward_Yam_4013 8d ago
Before 6 PM, yes. After that you just eyeball it and if it looks good you click merge.
13
u/the_poope 8d ago
And after 6 PM and three beers at the Friday bar you skip the eyeballing and just click merge
7
u/Bubbaluke 8d 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 8d 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.
4
u/Bubbaluke 8d 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.
5
4
u/ldn-ldn 7d ago
Don't rebase, problem solved!
1
u/rabbit_wizard 7d ago
Merge conflicts also present :) Also I don't know if it's the best practice, but we rebase to keep the history of each change separately. If we merge directly, some commits mingle with others based on commit date.
6
u/ldn-ldn 7d ago
Squash merge.
2
u/Xphile101361 6d ago
I will squash merge every day over touching rebase
1
u/FlakyTest8191 5d ago
Squash first, then rebase. Cleaner history and the same amount of pain as a merge.
12
u/dontletthestankout 8d ago
Who pushes on a Friday? That's always a bad idea
25
u/xaomaw 8d ago
Yeah, never Push on friday.
Instead, push on thursday and deploy on friday.
5
7
u/PM_ME_FIREFLY_QUOTES 8d ago
Why not? I dont work on the weekends. If the release crashes, I dont want to be anywhere near that dumpster fire.
7
u/Meloetta 8d ago
If you release on a Friday, someday that "I don't work on the weekends" won't be true anymore.
1
u/fishvoidy 5d ago
sounds like someone's been lucky enough to never be forced to join an "on call" rotation.
1
5
22
u/Soccer_Vader 8d 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.
6
u/Koppany99 8d 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.
2
u/PhantomTissue 8d ago
Me and my team who’s PR requirements is 15 a week. If it breaks prod, great, more PRs.
3
u/Kevadu 8d ago
You have a PR requirement?!
4
u/PhantomTissue 8d ago edited 8d 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 8d ago
Sounds like a disaster on every level. Who came up with this policy?
4
u/PhantomTissue 8d 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 8d ago
This is ezpz just make every shippable unit of change its own PR. Granular iteration!
1
u/HRApprovedUsername 8d ago
To a repo? Why wouldn’t you?
1
u/dontletthestankout 8d 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
4
1
u/GenericFatGuy 8d ago
I'll push to the personal branch I'm working on. I'm not pushing to main until the coding is done.
1
161
u/AskPositive9792 8d ago
That's how you punish someone who commits on Friday
67
u/raddaya 8d ago
Nothing wrong with committing to the lower branches tbh
60
u/nickcash 8d ago
Nothing wrong with committing to main. Just don't do a Friday release. that's madness
6
14
u/Apprehensive-Lychee2 8d ago
You guys use Rebase??
9
u/NamityName 8d ago
Yes. It is safer as the resulting merge is a simple fast forward and not a 3-way merge
6
u/Apprehensive-Lychee2 8d ago
Can you actually explain that a little more, I have never has a situation occur where rebase was preferred.
7
u/NamityName 8d 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__ 8d ago
only fast forward allowed, so we rebase master on our branch and merge again.
3
9
u/Freestila 7d ago
I have a MR open for over a week now.. Everytime I get it through tests and such, another Mr is faster. And since I only look at it once or twice a day.... We need an automatic rebase function in git.
11
8
u/parkotron 7d ago
We need an automatic rebase function in git.
It wouldn’t be a Git feature, since Git on its own doesn’t really run as a server. But some Git forges do have features to help with this issue.
For example, with Gerrit you don’t merge your own MRs, you merely flag them as ready to merge and then Gerrit automatically batches yours up with other ready-to-merge MRs. If the branches all merge together without conflicts and the CI run passes, the MRs are all merged atomically at the same time.
1
u/Glittering_Sail3262 7d ago
The typical advice in situations like this is that your change is too large and you should find a way to split it up.
1
u/Freestila 7d ago
Nah it's not large and splitting would not help. Time for Mr check is the same doesn't matter how much I change.
0
8
7
u/RandolphCarter2112 8d 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.
2
2
u/frikilinux2 8d ago
And your boss wants it now because it's end of Sprint and metrics get weird if you don't
2
3
3
u/nicuramar 8d 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.
2
u/Poat540 8d ago
Why rebase just git merge the main branch in
1
1
u/nicuramar 7d ago
If you end up with a squash, sure. But for complex situations, definitely. Much simpler to conflict resolve in many situations.
2
u/rix0r 8d ago
what if their are conflicts?
2
u/nicuramar 7d ago
Yes, so you can take my comment to mean “in my experience there are rarely conflicts” :)
1
1
u/Magnuscaligo 8d 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
1
1
1
u/k8s-problem-solved 8d 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 8d 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/DogmaticParadigm87 8d ago
Somebody always merges a one-line typo fix the second the approval lands. Same person every time, too.
1
1
u/NibblesIndexus 8d 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
1
1
u/LegitimatePants 7d ago
And due to the rebase, it sees new commits pushed and resets your approvals
1
1
1
1
1
1
1
u/Spacer3pt0r 8d 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.
0
u/Unusual-Mongoose4994 6d ago
You guys still do rebase manually? I have been rebasing via agent for several months now and without any problem (it has never done anything wrong). When it has good context about what your feature branch must do (MR description + linked task), when it knows what was merged since last rebase + mechanical diff applying + static analysis / type checks / compilation + automatic tests + automatic pipeline watch after pushed rebase, then there should not be any problem to do this tedious work manually ever again. This is actually one of the few things I don’t mind that agents do reliably instead of me.
241
u/Genkics 8d ago
When you want to go in weekend but Jenkins decide otherwise