Last Updated: February 25, 2016
·
519
· mysterycommand

How to Worry About a Clean Git History

Piggy backing off of Krzysztof Hasiński's pro tip Please, oh please, use git pull --rebase.

… a colleague shared this additional bit of wisdom(? … I see that rebase is somewhat controversial). I haven't yet had to worry too much about cleaning my Git history, but as I'm using it more and more lately this might come in handy at some point:

Via Jansen Price (a.k.a. sumpygump on Github and Twitter):

If you try to pull when your repo is dirty (you have modified tracked files), it will complain and not let you. Your options are to either commit what you have so your repo is clean again, or sometimes you want to pull in the latest changes upstream before committing your changes, so in that case you can do this:

git stash
git pull --rebase
git stash pop

What this will do is stash your current changes in a temporary holding place (the stash) and then pull in the changes from the remote, and then pop those changes back into you working directory.

You might end up with conflicts after the stash pop. In this instance, just correct the conflicting lines and then do a regular git add and commit and push (when you're ready).

You might end up with conflicts during the git pull --rebase command. When that happens you need to fix the file (resolve the conflict) and then issue a git add <filename> to denote that you are done fixing the file and then run git rebase --continue (It has instructions about this when it happens) until it finishes rebasing all the changes.

If you want to make it so all your branches from all your repos always use this rebase strategy, you can run this command:

git config --global branch.autosetuprebase always

Hope you find it useful (future self)!

//Matt Hayes