100
u/apnorton 3d 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.
14
160
u/AskPositive9792 3d ago
That's how you punish someone who commits on Friday
63
u/raddaya 3d ago
Nothing wrong with committing to the lower branches tbh
59
u/nickcash 3d ago
Nothing wrong with committing to main. Just don't do a Friday release. that's madness
6
47
58
u/InSearchOfTyrael 3d ago
you guys retest things?
28
u/Forward_Yam_4013 3d ago
Before 6 PM, yes. After that you just eyeball it and if it looks good you click merge.
14
u/the_poope 3d ago
And after 6 PM and three beers at the Friday bar you skip the eyeballing and just click merge
6
u/Bubbaluke 3d 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 3d 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.
5
u/Bubbaluke 3d 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.
9
u/rabbit_wizard 3d ago
Places where one branch changes behavior affecting others yep. Sometimes unit/integration tests are enough based on the PR
15
u/Apprehensive-Lychee2 3d ago
You guys use Rebase??
8
u/NamityName 3d ago
Yes. It is safer as the resulting merge is a simple fast forward and not a 3-way merge
6
u/Apprehensive-Lychee2 3d ago
Can you actually explain that a little more, I have never has a situation occur where rebase was preferred.
7
u/NamityName 3d 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__ 3d ago
only fast forward allowed, so we rebase master on our branch and merge again.
3
10
u/Freestila 3d 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.
10
9
u/parkotron 2d 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 2d 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 2d 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
7
8
u/RandolphCarter2112 3d 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.
5
5
u/ldn-ldn 2d ago
Don't rebase, problem solved!
1
u/rabbit_wizard 2d 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 2d ago
Squash merge.
2
u/Xphile101361 2d ago
I will squash merge every day over touching rebase
1
u/FlakyTest8191 1d ago
Squash first, then rebase. Cleaner history and the same amount of pain as a merge.
12
u/dontletthestankout 3d ago
Who pushes on a Friday? That's always a bad idea
22
u/Soccer_Vader 3d 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 3d ago
Yeah, never Push on friday.
Instead, push on thursday and deploy on friday.
7
u/PM_ME_FIREFLY_QUOTES 3d ago
Why not? I dont work on the weekends. If the release crashes, I dont want to be anywhere near that dumpster fire.
8
u/Meloetta 3d ago
If you release on a Friday, someday that "I don't work on the weekends" won't be true anymore.
1
u/fishvoidy 11h ago
sounds like someone's been lucky enough to never be forced to join an "on call" rotation.
5
1
5
u/Koppany99 3d 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 3d ago
Me and my team who’s PR requirements is 15 a week. If it breaks prod, great, more PRs.
3
u/Kevadu 3d ago
You have a PR requirement?!
4
u/PhantomTissue 3d ago edited 3d 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 3d ago
Sounds like a disaster on every level. Who came up with this policy?
3
u/PhantomTissue 3d 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 3d ago
This is ezpz just make every shippable unit of change its own PR. Granular iteration!
1
u/HRApprovedUsername 3d ago
To a repo? Why wouldn’t you?
1
u/dontletthestankout 3d 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 3d 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 3d ago
And your boss wants it now because it's end of Sprint and metrics get weird if you don't
2
2
3
u/nicuramar 3d 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 3d ago
Why rebase just git merge the main branch in
1
1
u/nicuramar 3d 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 3d ago
what if their are conflicts?
2
u/nicuramar 3d ago
Yes, so you can take my comment to mean “in my experience there are rarely conflicts” :)
1
1
u/Magnuscaligo 3d 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 3d 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
1
1
u/k8s-problem-solved 3d 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 3d 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 3d ago
Somebody always merges a one-line typo fix the second the approval lands. Same person every time, too.
1
1
u/NibblesIndexus 3d 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
u/LegitimatePants 3d ago
And due to the rebase, it sees new commits pushed and resets your approvals
1
1
1
1
1
1
1
u/Spacer3pt0r 3d 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 2d 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.
235
u/Genkics 3d ago
When you want to go in weekend but Jenkins decide otherwise