Rebasing is often thought of as a mystical and complex tool. This video will demystify one of the primary uses of Git rebase—integrating branches without merge commits.
So, you’ve worked on your project, you’ve pushed it to GitHub, and now you decide you really must rebase. You’ve promised the necessary favors/servitudes/unnatural acts to your collaborators and are now ready to move forward. You perform the rebase in your local repo. All of that, you covered (well, not the unnatural acts). From playing around with it, it seems to me the remaining steps are:
git push --force to overwrite the repo on github and leave it matching the state of your local repo.
Each collaborator deletes his local version of your branch
Each collaborator checks out the branch from github to create his own new, unconfused local copy.
Each collaborator collects as agreed beforehand.
Did I miss anything? Is there a better way to do it?
@rcritz that sounds exactly right to me—that’s certainly the way I’ve approached it in the past.
If you’re working on feature branches, it’s often the case that there aren’t many people working on the same branch, so rebasing post-pushing isn’t as arduous as I made it sound. The key thing is the process of coordination between your collaborators, as you correctly pointed out.