git config --global pull.rebase true
to make your pull becomes pull --rebase
git fetch
a lot
git rebase origin/develop
sometimes
git push --force-with-lease
after a rebase
git reset --hard origin/my_branch
to get back the remote branch
git cherry-pick
is a good friend when mixed with some rebase
git reflog
could save you after a mistake
Before synchronizing remote and local, go see the commit history and be sure to know if a rebase happened or not. So DO COMMUNICATE about rebase with people on your branch.
If you have more commit on the local than the remote branch
~/path/to/project my_branch ⇡
git push ## Push your commits on the remote branch
If you have more commit on the remote than the local branch
~/path/to/project my_branch ⇣
git pull --rebase ## Pull commits from remote to local
If NO REBASE HAPPENED on the remote version of your current branch
~/path/to/project my_branch ⇣⇡
git pull --rebase
git push
If REBASE HAPPENED on the remote version of your current branch
~/path/to/project my_branch ⇣⇡
git fetch
git reset --soft origin/my_branch ## Reset your local branch to the origin history (all your not pushed commits will be converted into untracked changes)
It's better to be sync with the remote before rebasing, see above.
Communicate with anyone working on the branch you will rebase.
Tips: think about squashing commits on your branch sometimes, the less commit you have, the quicker the rebase will be.
git fetch ## Update local git refs
## Synchronize your local and remote branch before rebasing
git pull --rebase ## If you have remote commit not yet on your local branch
git push ## If you have local commit not yet on the remote
## Do the rebase
git rebase origin/develop ## Do the rebase
git push --force-with-lease ## Push force the new branch history
## IF the push is rejected, that mean someone pushed something on the remote branch while your rebase
git cherry-pick <hash1> <hash2> ## Get the new commits on your local history, you can get the hash from gitlab
git push --force-with-lease ## Retry to push
## IF the push is still rejected, someone pushed again, you're up for another cherry-pick :)
Given my_feature
was created from develop
and my_branch
was created from my_feature
.
Also, my_feature
was rebased on develop
and you want to update my_branch
with new changes from develop
and my_feature
.
~/path/to/project my_branch ⇣⇡
git fetch ## Update local git refs
git reset --hard origin/my_feature
git cherry-pick <hash1> <hash2> ## Get commits from my_branch that are not on my_feature, you can get the hash from gitlab
git push --force-with-lease
git reflog origin/my_branch ## Get the action history on origin/my_branch
## You will get some hash corresponding to action done on the branch
git checkout <hash> ## to go back in time on a specific action
## Check that all is like you want
git checkout - ## Return on the last branch you where before last checkout (my_branch)
## /!\ --hard will erase any difference on your local branch, beware, be sure of the hash, --hard do bite
git reset --hard <hash> ## Reset your branch on the correct hash
## /!\
git push --force ## Reset the remote branch on the recovered history
It can be very useful when cherry-pick (after a rebase failed push or if you have local commit and someone pushed a rebase).
git rev-list --right-only --cherry-pick --no-merges --reverse origin/A...origin/B
OR
git rev-list --right-only --cherry-pick --no-merges --reverse A...origin/A