Trunk Based Development requires your developers to be disciplined, willing to work in-step with each other, and to know what they’re doing.

Why do branch-based approaches not demand these things? What happens if you don’t have these things?

When I read or hear “I pushed up a non-trivial PR”, I understand that as “I couldn’t be bothered to do this work in a safe way by making small changes that worked at every step, so now I’m offloading understanding all the changes of 50+ files onto YOU! Good luck!”.

I’d argue this is pure laziness and shows a lack of discipline in the craft.

Then again, I think a PR process is a lack of discipline as well, but that’s another story.

command to get just the changed files from git and run in rubocop:

git ls-files -m | xargs ls -1 2>/dev/null | grep '\.rb$' | xargs rubocop

Regarding branches and merge conflicts:

Doubling down on using branches means these problems will continue.

Personally, I don’t want to live with problems that are solvable and the only reason we can’t fix them is … what exactly? The resistance to collaborating? Learning how to work in a way you haven’t experienced yet?

If you have problems with merge conflicts, adding more tooling to allow your branches to go on longer without being merged isn’t going to help.

What am I missing? How am I the crazy one for saying this?

Man, I feel sorry for workplaces that require developers jump through the git hoops such as constant squash, fixup, drop, edit, cherry picking, branching, and merging, etc.

There are safer, saner ways to work with way less git-wrangling.

Congrats on knowing so much Git, I guess.

I keep forgetting how to change the remote for a git repo.

1) View existing remotes

git remote -v

2) Change the ‘origin’ remote’s URL

git remote set-url origin https://github.com/user/repo2.github

3) Verify new remote URL

git remote -v

I will always prefer one of these ways of working over the other.

I have an extremely hard time to understand how the other is reasoned about or chosen.

1

2

If you like to work in long lived branches:

Why do you think that your work needs to be able to work in isolation from everyone else’s work?

At the end of the day, it’s one product. Your code needs to work with everyones code.

While you are probably not concerned if you find yourself in a bad merge conflict, you are just as likely to inflict a bad merge conflict on others.

Why are you okay with setting your teammates up like this?

There are ways you can work that doesn’t do this to your teammates.

Would you be willing to learn another way?

You can avoid having complicated git setups, rules, when to merge, when to rebase, etc, if you work to get your small commits that don’t break the build into main sooner. Instead of rebasing/merging 25 commits, get your code into main after 1-3 commits. The pain goes away.

Think you can’t work in such small steps?

I think you can. I believe in you if you try.