Ben Rubinger writes:

> Hi Steve,
> Thanks for your reply. Your input is helpful. I've spent the past five
> days reading through this book:
> My hesitancy around rebasing was around the fact that (if I understood
> correctly) all rebased checkins are deltas, having different hashes
> from their original with the implication that if others have checked
> out your branch, they will feel pain after you perform a rebase. I'm
> not sure if I captured this correctly, but in general it seemed like
> rebasing can be inconsiderate to others with whom you're working. What
> advice do you give to people you're training around this? And, if
> rebasing does introduce certain risks, is merging possible while
> avoiding polluted PRs?

Your intuition is completely correct, rebasing *is* inconsiderate to
your collaborators.  Personally I deal with it like this:

1. If possible I do not publish things that I know I'll have to rebase
later on.  Of course that's rather rarely possible :(

2. I've chosen a prefix for published branches that may be rebased,
"devo/".  I then make sure to communicate to the rest of the team that
it's not safe to base any work on branches named liked that.

3. Finally I try to keep my "devo/" branches as short-lived as possible.

I'd love to hearother people's strategies.


Magnus Therning              OpenPGP: 0x927912051716CE39
email:   jabber:
twitter: magthe     

There's a big difference between making something easy to use and
making it productive.
     -- Adam Bosworth

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
For more options, visit

Attachment: signature.asc
Description: PGP signature

Reply via email to