Sometimes its nice to clean up commits before merging them into your main code repo; in this lesson, we go over using git rebase to squash commits together and then rename the condensed commit message. We also talk about potential issues with rebasing and where to be careful.
//First, you can fetch the remote branch git fetch //Then can see the logs between remote branch and local branch git log origin/master..
git rebase -i origin/master
One thing to note is that a rebase is destructive. It actually changes your Git history. You shouldn‘t use a rebase on code that‘s already been put in your master branch on your remote repository that other developers might be using. A rebase has the same function as a Git merge, but it cleans up and destroys history, whereas a merge preserves all history, and includes a merge commit.
The bottom line is that, as long as you only need to clean up commits that you‘ve made locally or in a pull request branch, you can use rebase to clean them up before you merge them into your main master branch.
If you have already pushed your commits to a pull request branch, then after you run the rebase, because it‘s destructive, you‘ll need to run:
git push -f
, for force, to let Git know that you‘re OK with destroying the history that‘s in a remote branch.
Again, be careful with this, and only use a rebase and a force push if you‘re working on code that hasn‘t been made public yet. One other thing to note is that, if at any time during a rebase, you realize you‘ve made a mistake, you can get run the Git rebase command with the abort flag to stop the rebase, and return your repo to its state before you started the rebase.
git rebase --abort