git rebase

The most common review comment on a request is to "squash the commits together, and to rebase on top of the master".

Simplest rebase: local squash

Before I push my commits, I can always squash my local commits into 1.  Let's say I have 10 local commits to squash into 1.  Then I can begin the interactive rebase with this command:

git rebase -i HEAD~10

The oldest commit in the series should be left at "pick", and the rest should be changed to "s" (for squash).  When the temporary rebase directive file is closed, git will open another editor window, where I can change the comments.  This is the simplest rebase scenario.  When I work with another developer who already has my commits and I STILL want to rebase, the other developer has to jump through some hoops.  In the simple case, where he does not have any local changes:

git pull

Otherwise, git pull --rebase

When all else fails, cherry-pick

In the worst case, he can reset to the current AFTER writing down his commits.

git log --oneline or

git log -l 5 --oneline to see the latest 5 commits, and copy the comits ids of the changes to keep.  Then

git fetch

git reset --hard origin/<branch name>

git pull

to sync to the repo 'as is' and proceed to "git cherry-pick" your changes.

Rebase after cherry-pick

The whole idea, if you end up fixing conflicts with rebase is to get rid of your local merges, so in a worst case scenario, before pushing back to the server you could do:

git rebase -i <FROM_ID>

with <FROM_ID> being the commit id of the change before the point you'd like to start an interactive rebase.