[threedaymonk]

In your scenario, it sounds like you'd be better served by pushing the incomplete work to temporary branches. At least, if I were working with you, I'd rather have working code in master than a bunch of "git commit -am Hometime" dumps.

[antris]

Even better is avoiding shared branches and just rebasing locally, merging to master whenever a task is complete.

[threedaymonk]

I frequently push work-in-progress branches as insurance. If my SSD dies, or I get mugged on the way home, I'll still have the code tomorrow.

[antris]

There's two possible answers:

1. Your are not merging to master often enough. If you split your tasks and use environment flagging effectively, there's no reason why you wouldn't want to merge to master on a daily basis.

2. If you absolutely need to diverge from master so much that you have many days of work sitting on your hard drive, you should be pushing to a non-shared repository in that case, or use other form of backup.

[threedaymonk]

Generally, I'm merging to master frequently (several times an hour). Things like upgrading Rails can be multi-day odysseys, however (even though there's sometimes an opportunity to make compatibility changes in master).

However, I don't see WIP branches as a problem, and certainly not one that justifies setting up additional repositories or backup systems just to avoid. If I'm working for someone else, it's not my place to set up shadow repositories all over the place, either.