[neebz]

Unfortunately rebase doesn't fit well with our team workflow (team is geographically distributed). we use branches and commits to check which user is on which task. everyone pushes code at the end of the day even if it's incomplete. Pushing code prevents rebase usage.

Rebase is really good especially when you are contributing in open source repositories but our experience has been limited in our private repositories.

[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.

[shuzchen]

I personally don't subscribe to the "you should never rebase commits that you have pushed to a public repository" tenant. For me it's more "you should never rebase commits that you have pushed to a repository other people use".

That is, your personal WIP branches are fine, so long as you're the only person that pushes/pulls from it. These WIP branches should be labeled in such a way that the team knows at a glance which are WIP.

This also means your team members need to get used to doing a `git push -f`, as well as making sure their push.default is configured to "current".

[threedaymonk]

Rather than normalising the rather risky behaviour of "push -f"ing all the time, I think it's probably better to treat WIP branches as linear and refrain from reorganising/reordering/squashing until you're ready to merge them into a shared branch.

I'm with you on the push.default = current, though. I'd forgotten that wasn't standard, I've had it in my .gitconfig so long. I can't see why you'd want anything else!

[antris]

> we use branches and commits to check which user is on which task. everyone pushes code at the end of the day even if it's incomplete

I think your fundamental problem is trying to use git for task management. There's better software for doing that, e.g. Trello.

[michaelmior]

I occasionally do the same thing, but as long as I know no one else is working off the code I push, I still feel comfortable rebasing after pushing.