7 ms·
We've had good success encouraging daily merges of master into feature branches, and then using `git merge --squash` to avoid hopeless polluting of your history
by dankohn1 12y ago
We've had good success encouraging daily merges of master into feature branches, and then using `git merge --squash` to avoid hopeless polluting of your history graph.
Git merge squash essentially takes a diff of your feature branch and master and applies the diff as a single commit. See http://stackoverflow.com/a/25387972/1935918 http://stackoverflow.com/a/25387972/1935918
You lose the history of the feature branch, but we don't want that history anyway, since once tests are passing and the branch has been reviewed, we treat it as an atomic unit. That is, we might revert the whole commit, but we're not interested in reverting part of the commit.
- rtpg 12y agoDoesn't this make commits too big? On the team I'm working with right now, most people are making really small commits, but it makes git's history mechanism really useful. A single line change can be linked to a relatively small commit, it's extremely useful to figuring out the "why" of something. Having one commit for an entire feature would make that utility completely disappear
- dankohn1 12y agoYes, the downside of aggregating history is that you've aggregated your history. So far, it has worked well for us, partly because we try to keep feature branches small.