Squashing can be useful but discarding potentially hundreds of commits and replacing them with one commit called "1.0.0" is very puzzling.
Instead, each developer should handle this on their own: commit often, once they're happy with their progress, theh rebase -i, squash and reorder their commits to make them look nice and push that tidy commit to master or release.
This gives you the best of both worlds: an accurate version of your history that doesn't contain throwaway or half baked commits.
I think this point is overlooked all too often. With git, just mashing out code and committing at regular intervals is not using git to its full potential. You're supposed to spend time crafting proper commits, consisting of logical, well-separated changes. The staging area and rebase feature make it easy, but it still requires effort that most developers are not used to.
Good, logically separate changesets make merging, backporting (cherry-picking), bisecting and reverting much easier. It is worth the trouble.
The version history of the git project itself serves as a magnificent example of what a commit history should look like. It's actually possible to read the logs and understand each committed change. (Most of the time)
Comments
Squashing can be useful but discarding potentially hundreds of commits and replacing them with one commit called "1.0.0" is very puzzling.
Instead, each developer should handle this on their own: commit often, once they're happy with their progress, theh rebase -i, squash and reorder their commits to make them look nice and push that tidy commit to master or release.
This gives you the best of both worlds: an accurate version of your history that doesn't contain throwaway or half baked commits.
I think this point is overlooked all too often. With git, just mashing out code and committing at regular intervals is not using git to its full potential. You're supposed to spend time crafting proper commits, consisting of logical, well-separated changes. The staging area and rebase feature make it easy, but it still requires effort that most developers are not used to.
Good, logically separate changesets make merging, backporting (cherry-picking), bisecting and reverting much easier. It is worth the trouble.
The version history of the git project itself serves as a magnificent example of what a commit history should look like. It's actually possible to read the logs and understand each committed change. (Most of the time)
This is what I always liked about darcs (it's still the DVCS I use at home): separating checkins into logical change sets.