Even better: use pre-commit. It supports all kinds of stuff without a lot of config. This gets you (and GP) a lot of the features of a full-blown CI pipeline, but it all runs locally before anyone breaks anything.
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.
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.
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.
I agree. I absolutely hate when some pesky git hook rejects some debug code I wrote that I want to commit. Mind you, commit, not integrate. This is the situation where I whip out git commit -n.
Pre-commit hooks don’t require a pipeline nor any money. In most cases it’s one line of code to make the tests run every commit
Even better: use pre-commit. It supports all kinds of stuff without a lot of config. This gets you (and GP) a lot of the features of a full-blown CI pipeline, but it all runs locally before anyone breaks anything.
Stop me from committing my work and I will hunt you down to the ends of the earth.
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.
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?
Take down prod while I’m on call and seeing my kid and I shall return the favor
I get that a lot
Getting threats over one line of code is called senior development
Don’t worry I’m too lazy to hunt you down farther than the coffee shop next to me.
I agree. I absolutely hate when some pesky git hook rejects some debug code I wrote that I want to commit. Mind you, commit, not integrate. This is the situation where I whip out git commit -n.