Understanding the Git Workflow
The minute I learned about "rebase -i" and "add -p" has changed how I think about commits. I learned how I could easily keep the history clean and conversely, I learned the huge value that a clean history has for maintenance.<p>Now, building the commits as self-contained entities that don't break the build in between not only helps me while searching bugs later on, it sometimes helps me detect code smells around unneeded dependencies.<p>That said, I still like to merge big features with --no-ff if they change a lot of code and evolved over a long time, as that, again, helps keeping history clean because a reader can clearly distinguish code before the big change from code after the big change.<p>Of course the individual commits in the branch are still clean and readable, but the explicit merge still helps if you look at the history after some time.<p>"you said 'a long time in development' - surely the merge target has changed in between. Why still -no-ff?" you might ask.<p>The reason, again, is clean history: before merging I usually rebase on top of the merge target to remove eventual bitrot and in order to keep the merge commit clean. Having merge commits with huge code changes in them which we're caused by fixing merge conflicts, again, feels bad.<p>But this is certainly a matter of taste.