Okay, first off, this isn’t going to be a detailed explanation on the eccentricities of git, git rebase and git merge. If you want, that there’s some internets for you to use. (This explanation is pretty good). It’s going to be my thoughts and experience with them.

Git Merge

I’m most familiar with git merge. You switch from your branch over to master, pull down master, switch back over to your branch, merge master in, fix any conflicts, switch back over to master and merge your branch in. The handy thing about git merge is that what you’ve done on your branch doesn’t get overwritten by master. When you do your merges though, you’re going to get all the revision histories for the branches. So if you’re working with a master branch that has a lot of contributors, then your history is going to look a bit messier.

Git Rebase

Rebasing gives you a cleaner revision history. Everything is pretty and linear and your git log will be prettier too. Super cute and fun. However, you’re going to have not as much fun when it comes to conflicts or someone’s been editing the same files you’ve been editing. I’ve had issues where what I’ve written on my local branch was overwritten and it was such a pain to fix and keep track of everything. You can fix all this, but it’s just more of a hassle to resolve, and I’ve gotten into these seemingly unending loops of resolving conflicts for each commit. You can also rebase more frequently which helps.

So which is better? Neither one is better, they serve their own purposes and they both have uses and how you want to use them is up to you. Any thoughts? What do you use most often?

More next time!

-Rachel