by Leon Rosenshein

FI/RI, Flag, Merge, Rebase, Trunk

How do you develop a feature? Do you go off into your own little world (feature branch), develop for a few weeks/months, then spend another week dealing with merge issues and releasing your shiny new feature on the world fully formed and integrated? Or maybe after weeks of work you just rebase, handling the text conflicts relatively easily, but then dealing with hidden logic changes for a week. Or you might have tried to just live in master (trunk) and make small, innocuous changes all along until somehow there's enough there there for users to notice and ever so slowly becomes a full feature? Or maybe you've got 1000's developers working on "features" that are roughly the size of most applications and you ~want~need to share code and release them in a big-bang event?

Lots of different options. And of course, when there are lots of options there's no one right way that always works. It's far more fluid and personal. It depends on the level of coupling between the changes you're making and the changes others are making. It depends on how long you expect to be different than everyone else. It depends on the overall velocity of the codebase. It depends on the size of the codebase and the size of the teams. It depends on your personal style and workflow, and the team/org's style and workflow.

So what's a poor software engineer to do? Compromise of course. Find the best solution for your current set of constraints. The worst thing you can do is blindly do things the same way all the time. So next time you have an option, think about it. Think about where you want the branch/PR to go in the future. Discuss it with someone. And do it mindfully, not out of habit.

So what's your preference and why? Put it in the thread.