Rolling, rolling, rolling back nothing I love more than communicating why we had to roll back again (ノಠ益ಠ)ノ
this post was submitted on 10 Jul 2025
425 points (96.3% liked)
memes
16151 readers
2979 users here now
Community rules
1. Be civil
No trolling, bigotry or other insulting / annoying behaviour
2. No politics
This is non-politics community. For political memes please go to !politicalmemes@lemmy.world
3. No recent reposts
Check for reposts when posting a meme, you can only repost after 1 month
4. No bots
No bots without the express approval of the mods or the admins
5. No Spam/Ads
No advertisements or spam. This is an instance rule and the only way to live.
A collection of some classic Lemmy memes for your enjoyment
Sister communities
- !tenforward@lemmy.world : Star Trek memes, chat and shitposts
- !lemmyshitpost@lemmy.world : Lemmy Shitposts, anything and everything goes.
- !linuxmemes@lemmy.world : Linux themed memes
- !comicstrips@lemmy.world : for those who love comic stories.
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Fix your shit and it won't stop you from committing.
It's also usually only on certain branches, so you can make a branch where you break things and then fix them before you merge to testing/main/whatever.
TIL precommit hooks can be set per branch. I was being facetious to begin with but this sounds pretty good actually.
Nah, at our place it's applied on all branches...
What do you do if you have code that isn't complete enough to work? Do you have to just leave it untracked?
I don't know what others do, but I personally whip out git commit -n and bypass the hooks in this situation.
If you have code that is not complete it is not qualified to be deployed. Cut work items into smaller chunks but never deploy not fully, 100% working and tested stuff. Not even on dev.
Every branch you have deploys on commit? You have to fully QA all of your code before it goes into any sort of source control?
Not quite.
That's an extremely very basic overview with many steps and concepts omitted but you get the idea.
That seems reasonable to perform on protected branches, but I'm not a fan of protecting all branches. That could leave valuable code with a single copy on a dev machine. I'd rather have it pushed to an unprotected branch and then be checked on merge instead of push.
Only main is protected, you can force push on feature branches.
So, what if I want to push some debug or preliminary code to a topic branch, would this system prevent this if all tests don't pass?
No, it does not prevent pushing (as long as the pre-hooks work) but you cannot deploy from a failed pipeline/branch because you have defective software, as proven by failed tests.
That is reasonable