I preserved for posterity a colleague's unique commit style:
back
3 comments
In case anyone looks at that and thinks it's cute or clever or fun... it's not. People will end up hating you for doing that. Okay, maybe hate is too strong, but it will certainly engender some strong negative feelings in anyone who has to try to figure out what you did (and when and why you did it).
Agreed.
A common objection from new developers is that "commit messages are hard and they slow me down", so if that's how you feel (for example, you're starting a fresh project): go crazy with your commits and don't let them slow you down. But then rebase, squash, and edit the commits before sharing them.
If a developer consistently pushes commits like this, they should be guided by their team lead to understand their importance. But if over time they refused to improve them, in many cases that would eventually be fireable. Commits are the technical paper trail: whether used when diagnosing issues, merging, compiling release notes, or whatever. Making the messages clear is extremely important.
> But then rebase, squash, and edit the commits before
> sharing them.
This is pretty simple to do outside of die-hard "continuous integration" shops -- most of the time I can just do
git rebase -i HEAD~4
(where '4' is the number of little dumb commits I made) and squash them all into the first commit.
But if I made a few commits, then pulled in someone's changes, then made a few more... well... http://xkcd.com/1597/
To his credit, these were usually on his/dev branch, and there were copious comments and docs.
On the other hand, a lot of this was on a large PHP codebase, so the result soon became the stuff of legend :)
I would hate to go searching for a commit that broke something in this mess. Your colleague should be more descriptive.
http://i3.kym-cdn.com/photos/images/newsfeed/000/731/143/3e3...
> 88642ba Fix all the conflicts
> fbd2658 Conflict all the fixes
Sounds like some amount of made-up work!
Merge conflicts never end when I think they will.