So I started using git with my latest project, just to get a feel for what all the Ruby on Rails guys were talking about when they weren't bragging about the size of their Macbooks. The koolaid is delicious. Even in a one-man, one-repo world, I spend a lot less time fighting my VCS for dominance.
Example from today: I was working on my deploy branch, where I typically only make to-be-deployed-within-the-hour microchanges. Then I saw another bug, so I squashed it. Commit. Then I saw another bug. So I squashed it. Commit. Then I saw a major opportunity for a simplification with a refactoring. Then I realized the refactoring was under-tested and that failures would be catastrophic, so I started adding extra tests. Now I'm fifteen commits past the last deploy, I have code that I'm 85% positive works on my must-not-fail deploy branch, there is one commit in there which addresses a bug which I want dead, and it is quitting time.
I have been in this state in SVN before. Recovery is NOT fun.
git branch all-the-work-i-did-today #Creates a new branch whose history looks exactly like deploy's does.
git reset --hard production_deploy_92 #Moves head of deploy branch to the tag of the last deploy, essentially forgetting commits afterwards.
git cherry-pick carefully_copy_pasted_hash #Nabs the one bug fix that I really wanted to deploy today.
Git makes my development and deployment processes better. Transformatively better, in some cases.
I don't think you would have this problem if you were working against a branch rather than the trunk. I feel like it is very simple to merge one file or change from a branch into the trunk and continue working on the branch. Rather more simple than your git solution, but perhaps I am missing something. Do you gain something special by working against the master?
Is this common? Usually we have a hard freeze on a release branch a couple of weeks before actually releasing it. I'm working on embedded systems so the test cycles are usually slower due to heavy HW involvement.
In web development, outside of large corporations, I'd say that near-realtime deployment is the norm. Fix the bug, test the bugfix, deploy to servers, all in the same day. git does work well for this. In Open Source projects, as well, folks tend to work directly on HEAD and only go back to old branches/tags for security fixes (if at all). Again, git is tight for this kind of work; which shouldn't be a surprise since it was built for Linux kernel development.
Embedded systems have to be damned-near perfect before you ship. Web systems, not so much.
Example from today: I was working on my deploy branch, where I typically only make to-be-deployed-within-the-hour microchanges. Then I saw another bug, so I squashed it. Commit. Then I saw another bug. So I squashed it. Commit. Then I saw a major opportunity for a simplification with a refactoring. Then I realized the refactoring was under-tested and that failures would be catastrophic, so I started adding extra tests. Now I'm fifteen commits past the last deploy, I have code that I'm 85% positive works on my must-not-fail deploy branch, there is one commit in there which addresses a bug which I want dead, and it is quitting time.
I have been in this state in SVN before. Recovery is NOT fun.
git branch all-the-work-i-did-today #Creates a new branch whose history looks exactly like deploy's does.
git reset --hard production_deploy_92 #Moves head of deploy branch to the tag of the last deploy, essentially forgetting commits afterwards.
git cherry-pick carefully_copy_pasted_hash #Nabs the one bug fix that I really wanted to deploy today.
Git makes my development and deployment processes better. Transformatively better, in some cases.