I’ve already written a time or two how you can use git rebase to change your commit history as you work. Handy handy.. I think everyone should know how to do that.
Next up.. what if you pushed a commit and realize it’s not so great. First of all, everyone discourages this of course. The encouraged way is to just make another commit that fixes what you want different. We all want to break that rule every now and then though. Here’s how…
Continue reading “How to fix that mistake commit you just pushed to your git repository”
So there you are, using git to store, track and share your code with a few others. Maybe many others. You make a change, someone else makes a change, one or the other of you pulls the others changes and BAM.. you get that merge commit. It really isn’t harmful of course, but it cleans up your repository a lot to get rid of them. So…
- When you pull, use –rebase.
git pull --rebase
There. It did it for you. All your commits go after the commits on the remote origin.
- You forgot to do that. No prob…
git pull # oh man.. I forgot.. merge commit
git rebase origin/master # There. Pretty easy isn't it.
So of course, you might have the same issue if you were working on a branch. You check out master, make some commits, go back to your branch, make some more, etc. It works the same way.
# on your branch
git rebase master
There. You can pull in the master branch changes but put all your branch changes after so you don’t have to have the merge commit again.
So you wrote that branch, changed master, and then you merge your branch back to master and get a merge commit again. In this case there isn’t a ref to rebase off of so intuitively like remote/origin or master. No prob, just use gitk or git log or whatever to find out what the sha1 of the old master was before you made your merge.
There. No merge commit again.
Now, there are a bunch of more advanced things rebase can do. You can use it to edit commits that weren’t quite right. You can also change the order of commits, edit the commit message, drop commits completely, and other cool things. You can do it all interactively too…
git rebase -i # fun for all!
I leave you to study that part on your own.
So you just committed 15 things to your git repository and now you want to push your changes. Oops, commit #2 added your password file. Or perhaps you misspelled words in the commit message. Now, being a git expert, you think to yourself, I’ll just create a temporary branch, cherry-pick the commits that are correct, re-commit correctly the incorrect commit, and then merge/push my temporary branch instead of this flawed branch I have. That all works fine, but luckily there is a much easier way to do it.
> git rebase -i
When you use ‘-i’ with rebase, you get an interactive edit screen that gives you an option for each commit _after_ the sha1 you enter. For each commit you can either delete the entry entirely or replace the word “pick” with “edit”. Deleting an entry causes that commit to lost. Editing a commit gives you the option to unstage some of the files, edit the commit message, or really, to do whatever you want to change it how you intended. If you edit, or the rebase has a conflict, after setting things how you like, just use rebase –continue to go on your way.