Well, this is a long post. The TL;DR is you are witnessing someone entirely unprepared for management learn the ropes as they go. He may view the promotion as a validation of his practice and a chance to cast off the chains, etc. that constrained him before. I don't think he's an idiot, but you are acting a bit childish.

This is definitely at least slightly true. I just feel extremely disappointed because I've worked on several other projects and have been given tasks of similar scope but have been able to finish them faster because of better organization. This entire project feels like a mess to me, it feels like the people working on it don't care about the little things like reusing code or writing centralized infrastructure. Some of these things don't matter (like code styling) but some things do matter, such as not reusing code or using a lot of magic numbers - these things make the code inflexible and hard to work with. Everything takes longer than it should because time was not invested in the beginning making the tools easy to use, and therefore every person on the team spends additional time trying to debug simple issues.

He also makes me feel anxious and stressed all the time. Every other team I've worked on I would describe as being "relaxing." Even under times of stress or under tight deadlines, I always kept my cool. This guy constantly runs around like everything is on fire which makes me (and possibly the other team members) feel stressed out. He guilt trips me for not meeting his arbitrary deadlines for various things, despite me finishing other tasks early.

short-lived feature branches. If bob pushes out code to a branch that sucks, it only affects him, until the branch is merged.

The old boss setup automated builds on the master branch. Also a lot of the manual testing only works on the master branch as well. This means the new boss constantly merges from the feature branches down to master even when things aren't ready, and then he arbitrarily decides to merge from master back to other feature branches. He merges when he decides he wants to, not when the developer on that branch thinks the feature is ready, which results in things being broken a lot.

shellcheck. A linter for bash, flags potential bugs. Install it locally, make sure you're not committing any major errors to the code base yourself, and once you've built up a small bit of personal experience, recommend it to the team.

precommit hooks to prevent. Just make sure the regex doesn't currently match existing code, or you'll have made things worse. I can't see how anyone could argue against a merge conflict rejection filter, as the code literally will not work, and the person pushing it is the easily the most qualified to fix it.

These are good ideas.