It's killing me.

This senior keeps doing all his fixes in the the same branch (named "develop-copy-{hisname}") and keeps merging it directly into develop and deployment branches. He has a lot of experience and therefore the manager gave him direct access to the branch.

The problem will arise when the QA team sends back one of the issues in the release back for changes. This never happened till date (his fixes are early and we vet all in-team changes, therefore he gets time to clean up his mess before the release date) but someday this will bite us in the ass.

I'm really unsure about ratting him out to the manager but I couldn't convince him to use separate branches (or separate commits) for different fixes. I couldn't convince him to add JIRA links/numbers into the commit messages either.

And, the junior devs I manage are getting inspired by him, and won't listen to me when I try to enforce separate branches, creating a political mess (probably I'm kinda like a contractor and they are permanent employees).

Sucks.

Have your colleagues blindly click approve on all pull requests, never link work to stories, no unit tests, 2000 line functions that you scroll right on as much as down, and microservices that are actually poor SOA as they RPC each other, and therefore must be in sync without any story / ticket to piece the release together, and also multiple bug fixes and indeed multiple entire features per branch. Get back to me xD

Well, as long as merges to develop are squashed and reviewed, it should be alright

but yes, I see your point. It's messy

I most all of my development on master. I'm also one of two developers at the company. Neither of us care a whole lot. Whatever floats your goat dude.

Sound like your senior knows what he's doing.

People who merge commit in git are the worst.

That's agile for you. People over process.

For real though, I've dealt with the same kind of senior developers. This stems from finding the whole version system a bother. Instead of seeing it as a great tool to aid the development process and tracing history (rime and reason) of the code. they see it as hampering their coding and commenting out sections as version history.

Their world view does not match development in teams or CI/CD driven development. Fortunately I'm also a senior developer, responsible for devops and a lot of pull with the board of directors. So I made a presentation for them and the directors with the comparison of the old and new way with some very pointy examples.

We used to have it all. Developer name and other long lived branches (calling me to solve the massive merge conflicts), commits with "Fix" or "." Commit messages. Massive commits with style changes, new features and completely unrelated bugfixes all in one commit.

This mostly changed (still see old code in comments) and devs are very happy with it.