Hacker News Reader

Comment by pgr0ss | Hacker News Reader

I actually just wrote up a blog post as well about why I don't like feature branches: http://www.pgrs.net/2011/08/29/why-i-dont-like-feature-branc...

My main reasons are that git history gets messy, builds don't run on feature branches (although github seems to have a work around here), and refactoring is harder.

My opinions are largely based on working on larger projects (more than 10 devs working in the same codebase).

View on HN

Learn to use rebase and squash commits! It solves a lot of the issues you talked about.

Squashing commits can fix up git history, but it does not address the bigger issues: refactoring, lack of builds, and having to deploy multiple branches to test features. The first two make it very hard to do any significant code reworking on a feature branch.

GitHub seem to have solved both the lack of builds issue and the challenge of deploying multiple branches (their bot can deploy a branch to staging with a single command) - which just leaves refactoring. I imagine they deal with refactoring by broadcasting a message to the team saying "I'm working on refactoring area X, try not to touch that code until I'm done if you don't want to deal with a painful merge".

I intend no ill will with this response, but it is worth pointing out that "the first two" "bigger issues" have nothing to do with your revision control system.

Lack of builds is something about which you and your CI server need to have a chat, and refactoring is something about which you and your people need to have numerous chats before, during, and afterwards.

Ironically, it seems like more feature branches is the solution to the "feature branch problem". :) With more, smaller branches, their changes will be laser-focused and easier to squash.

Reply on news.ycombinator.com