Only before you collaborate with anyone else. After that, don’t ever use rebase, or they’ll get an error, and will have to overwrite their local history with the one you’ve rewritten.
The way I structure my commits, it is usually (but not always) easier and more reliable for me to replay my commits one at a time on top of the main branch and see how each relatively small change needs to be adapted in isolation–running the full test suite at each step to verify that my changes were correct–than to be presented with a slew of changes all at once that result from marrying all of my changes with all of the changes made to the main branch at once. So I generally start by attempting a rebase and fall back to a merge if that ends up creating more problems than it solves.
Anyone mind explaining to me how
git rebaseis worth the effort?git mergehas it’s own issues but I just don’t see any benefit to rebase over it.Only before you collaborate with anyone else. After that, don’t ever use rebase, or they’ll get an error, and will have to overwrite their local history with the one you’ve rewritten.
The way I structure my commits, it is usually (but not always) easier and more reliable for me to replay my commits one at a time on top of the main branch and see how each relatively small change needs to be adapted in isolation–running the full test suite at each step to verify that my changes were correct–than to be presented with a slew of changes all at once that result from marrying all of my changes with all of the changes made to the main branch at once. So I generally start by attempting a rebase and fall back to a merge if that ends up creating more problems than it solves.