Hacker News Reader

Adding a new feature is the main reason you'd want to refactor something. Refactoring for its own sake is nice in theory, but ain't nobody got time for that. If you are doing real refactoring in a practical setting, it's probably a situation like adding a feature that closely parallels an existing one and now some of the stuff the old feature does can be factored out.

View on HN

Refactoring is often done in order to implement a new feature, but that doesn't mean they need to be done in the same commit. A common workflow is to be implementing something, realize a refactor is needed, "git stash", refactor, commit, "git stash pop", continue feature work.

I'm a fan of creating two commits in that case:

- Refactor to prepare for Feature X - Implement Feature X

Note that these can be written in parallel, but just submitted as two separate commits (guess which side of the history editing debate I come down on :) )

Reply on news.ycombinator.com