Hacker News new | comments | ask | show | jobs | submit login

I'm an avid supporter of rebasing over merging. I'll refrain from getting into my workflow, but here's what i want to say: For the love of all that is holy, never squash a merge commit nor squash onto a merge commit.

Squashing a merge commit is a perfect way to reintroduce old code back into master.

Squashing onto a merge commit is great way to lose changes. It's been a while since I have tried this, but creating a didactic repo if fairly easy. Create a repo with two feature branches, a file on each of master and the feature branches, merge featureA to featureB, make some changes or delete a file, `commit --amend` on the merge, and merge featureB to master. Then use `git cat-file` to look at those commits and commit trees. I've seen mysterious things such as simple as unreported changes to files mysteriously being deleted from the repo.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: