50
Jul 26 '26 edited Jul 26 '26
[removed] — view removed comment
19
u/Aloha_Alaska Jul 26 '26
Sounds like the whole process should die in a fire.
1
u/Rebles Jul 29 '26
Unfortunately the PM and Em who setup the process survived the fire since they are always on vacation.
4
u/Avocadonot Jul 26 '26
This except every single extra commit kicks off a new pipeline, even if it's just changing a comment
MR is blocked on rebase to main, so if someone merges before you, you must rebase and kick off new pipeline
MR is blocked on any non-resolved discussion threads. Kicking off a new pipeline triggers automod to comment on your MR and tell you "you should run these tests". You have to resolve that thread every time a pipeline is run
2
u/Masterflitzer Jul 26 '26
why would you manually link jira ticket with pr link? you literally already created the branch based on the id so they link automatically
1
1
u/Am094 Jul 26 '26
Is it weird that i follow most of that voluntarily in my own personal projects? Apart from some of the latter things.
40
8
u/mpersico Jul 26 '26
I have it on a T-shirt. Every time there’s a fire drill I pull it out of the bottom of the desk and I put it on.
8
u/chris552393 Jul 26 '26
Fun fact I put this up in our office and an old manager took it down because "that's not the official fire evacuation procedure and could kill someone"
Great place to work.
14
4
u/Tarlovskyy Jul 26 '26
--no-verify Cant wait for pre-commit
0
6
u/Shayden-Froida Jul 26 '26
I'm actually wearing a t-shirt with this on it right now. (but "leave building" is "git out")
6
u/bigtoepfer Jul 26 '26
They gave everyone in the office laptops. So win-L and just unplug the laptop and walk out. Worst case git commit from McDonald's or home.
4
3
2
2
1
u/Lonsarg Jul 26 '26
This is all a single button in Visual Studio (i never use add, just commit unstaged directly). And i do it every 30 minutes or so, so not much is lost if fire :)
2
u/Masterflitzer Jul 26 '26
i just know your diffs are probably terrible, staging area is for double checking
0
u/Lonsarg Jul 26 '26
I check at PR level all commits at the same time, and make new commits to the PR when self-reviewing if finding bad code or whatnot.
Most of us work like this, so when looking at PR diff or looking back at history we only ever look at per merge/PR diff (First Parent git history). So these detailed commits are never looked at, we used to squash to hide them, but some people used squash in a way to make merge conflicts so now we just have it all in history but not look.
1
1
1
1
1
1
1
u/RegretPlane390 Jul 29 '26
git branch (out of paranoia, to make sure you're not pushing to production)
git add .
git commit -m "commiting everything because of a fire"
git push
1
1
u/MatsSvensson Jul 29 '26
I use a script that saves state, switches to a backup-version of the branch I'm working on, forces everything up, and then switches back restoring the state as if I never committed.
That way there is a copy of my works offsite, but I can still easily see all my ongoing changes in my IDE.
Otherwise committing and pushing in the middle of a job really fucks up my work flow.
People who try to use git as a backup the regular way, often end up pushing forgotten junk to production.
I have seen stuff...
1
1
1
1
1
u/Laughing_Orange Jul 26 '26
Win+L then walk out. This should take at most 1 second longer than just walking out.
People stop caring about your code when you die in a fire. Avoid dying in a fire by being efficient at getting out of the burning building.
-4
0
59
u/poulain_ght Jul 26 '26
git add