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.

The only real integration branch is master.

Branches are a bandaid for working in too large and risky ways.

When you work on an isolated branch, you’re causing others to not know how you’re changing the code base. And they don’t get to see it or work with it until you’re done. If you refactor anything and others are depending on the current version of that code in their branch, you are directly causing them pain if you merge before they do.

I know working with branches and Git Worktrees feel very productive and efficient, but there are hidden costs. It’s a trap when viewed throught the lens of the team. It makes you think about only your work and not think about the whole.

Git Worktrees are bandaid on top of branches. When you work in too large of chunks, you will be interrupted and need to work on something else mid-work, so you need yet another tool because your existing tools aren’t sufficient.

Continuous Integration, and the discipline required to work in small, safe ways, removes the need for all this.

It gets your code changes into main faster so others can build off of it. If there’s a conflict, it’s noticed sooner, and it signals who you need to talk to before proceeding. It prevents the rework and frustration that comes from late merges.

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?

Deploy “commits”, not “complete features”. It will make managing “features” much easier.

❌ Don’t: “Here’s 40 commits, encompassing an entire feature; Deploy to prod and release to users immediately!; LETS GO!!!!!”

✅ Do: Safely nudge production just a little bit in this small way over and over again.

Deploying features maximizes the blast radius of the change.

Working in many small steps reduces it. This is the safer way to work.

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.

Continuous Integration is a thing developers do, not a software build tool.