Assumes:
- feature branch is
feature/add_csv_file
- mainline is
deploy
If you want to rewrite Git history on your feature branch here is how to do it.
- Make sure you are on the branch you want to rewrite the history of:
git checkout feature/add_csv_file
- Next you want to make sure you have the latest changes pulled locally and rebase un-pushed commits on top of remote changes:
git pull --rebase feature/add_csv_file
- Now make sure you have the latest mainline (deploy) changes fetched locally:
git fetch origin deploy
- Now we will interactively rebase our feature branch changes on top of the mainline:
git rebase -i origin/deploy
- At this point git will ask you for the plan for your rebase with a list of commits in order which you can edit to tell Git how to reorder or squash your commits. When you want to squash one commit into the previous commit you will want to change the pick keyword for that commit to squash. The initial plan will look something like this:
pick d17582b Add instructions on safely rewriting history in Git feature branches
pick 2ed86d4 Add rebase plan example
You might decide to squash the last commit into the first one like so:
pick d17582b Add instructions on safely rewriting history in Git feature branches
squash 2ed86d4 Add rebase plan example
Other possible commit commands supported in the rebase plan are:
p
orpick <commit>
uses the commitr
orreword <commit>
uses the commit, but allows you to edit the commit messagee
oredit <commit>
uses the commit, but stops for user to amend its
orsquash <commit>
use commit, but meld into previous commitf
orfixup <commit>
likesquash
, but discards this commit’s log messagex
orexec <command>
run command (the rest of the line) using the current shellb
orbreak
stops at that point, forces a pause (to continue the rebase process later you would use ‘git rebase –continue’)d
ordrop <commit>
remove commitl
orlabel <label>
labels current HEAD with a namet
orreset <label>
resets HEAD to a label
Read more about these and other options in the git rebase manual pages or official documentation.
-
Once Git has rebased based on the plan you gave it above, you'll want to check the history in Git is what you expect it should be. You can use
tig
or variations ofgit log
. -
If you have rewritten history that was previously on the remote branch you will not be able to simply push as usual, so the following typical push command will fail git server checks:
git push origin feature/add_csv_file # this will not work
To rewrite the remote branch's history with your changes safely you can use the --force-with-lease
flag which will ensure that your history rewriting was done with the latest remote branch history:
git push origin feature/add_csv_file --force-with-lease
If you get an error here you will want to start over since someone has pushed to the remote branch in the time it took you to rewrite your history. Go back to the first bullet above to restart.