A personal blog
Git isn’t just something you have to put up with when working with other
developers. Git is a wonderful tool that allows you to manage your code, its
evolution and help you recover from mistakes should they arise. One of the
things that people are intimidated by is
Let’s look at an example. You’re working on a team with two other developers. You have a blessed repository that sits on your company’s server. Everyone is working on the same project but on slightly different tasks. Everyone is working on the master branch. You write a bit of code here and there, you commit a bunch of times and then it’s time to share your code with the rest of the team by pushing it up to the shared repository.
git push but receive an error saying that there are changes on the
server and your commit cannot be fast-forwarded. No big deal, right? You run
git pull to download the changes that you don’t have and automatically
merge your changes in. Then you can
git push again and it will work just
The problem is that it makes the history of your project messy.
* 9:35 - Nancy - Merge branch 'master' |\ * | 9:35 - Nancy - Second commit | | | * 9:30 - Brad - First commit |/ * 9:12 - Nancy - First commit
As you can see, there is this strange <strong>Merge branch ‘master’</strong> commit that’s a little out of place. If everyone on your team is regularly pushing to the shared repository, the history gets littered with these weird commits pretty quickly.
You may have guessed that there is a better way. We’ll replay the above
git rebase. Instead of running <cite>git pull</cite>, we will run
git pull --rebase. What this will do is temporarily hide the commits that only you
have, then pull the changes from the remote repository, fast-forward (no merge
commit) and then re-apply your commits on top of the current HEAD. The end
result from a code point of view is the same, but the history is much cleaner:
* 9:35 - Nancy - Second commit * 9:30 - Brad - First commit * 9:12 - Nancy - First commit
See? Isn’t this so much better? The only difference to your current workflow is
that instead of
git pull you will run
git pull --rebase. Easy!
This article was first published on May 14, 2011. As you can see, there are no comments. I invite you to email me with your comments, criticisms, and other suggestions. Even better, write your own article as a response. Blogging is awesome.