Git is quite an awesome version control system. Why? Because it’s lightning fast, even for large projects (among other reasons).
But, how do you use Git effectively for development on a daily basis? Let me explain to you.
Branches
With git you normally have a ‘master’ branch. This is also the branch you use to sync your code with other repositories. That is also the reason why you should never code in the ‘master’ branch. Always create a new branch and develop your code there.
$ git checkout -b new_feature # add, commit, repeat
Rebase
Now, while you are working hard on your new feature, other developers complete theirs and push their changes to the remote master branch. When you’re done with your project, you need to first get the most recent version of the project’s code.
$ git checkout master $ git pull
Now, to make merging your new feature easy, you should rebase your new_feature_branch. What this does is add all the commits you just pulled in to your new_feature branch. Any conflicts that arise will happen in your new_feature branch as well, leaving your master branch clean and in order.
$ git checkout new_feature $ git rebase master
Merge
Now, you have resolved all (if any) conflicts with the current code and your new_feature, you can now merge your new_feature into the project’s master branch without any problems.
$ git checkout master $ git merge new_feature
This will create a new commit, containing your new_feature. Now is also the time to push your changes to the remote repository.
$ git push origin master
What’s next?
More often than not, you’ll encounter conflicts when running rebase. That’s okay, but you’ll need to know how to approach a situation like that. I’ll spend another blog post on that topic later.
Need Git training?
I’m currently available to provide on-location Git training. Please contact me for more info.
thanks for nice & useful post, but you should be more consistent with branch names. i do not know git almost at all and for a moment i was confused “another branch? what for?” ;)
@nickers: I’m used to branching like a madman ;-) It keeps your code clean and easy to share with others.
@Ariejan: I get the idea. My complains are about “new_feature” and “my_new_feature” – this was confusing for me. I thought that he created another branch :)
@nickers: You’re right. I updated the post. Thanks!
Great blog.
Am I wrong, or wouldn’t that ‘git merge new_feature’ be a fast forward merge, since you just rebased it on top of master? So the ‘This will create a new commit, containing your new_feature.’ comment is not really correct – it will just move the ‘master’ branch pointer up, it should not create a new commit.
Is it possible after “git rebase master” to push changes to origin/master from
new_feature, then (if push successful) checkout master, git pull that and delete
new_feature branch.
In this case the window for unwanted opportunity that origin/master changes
between updating master before rebase, and “git push origin master”
can be avoided.
[...] http://ariejan.net/2009/06/08/best-practice-the-git-development-cycle/ Categories: Git Tags: Comments (0) Trackbacks (0) Leave a comment Trackback [...]
Do u have an easy way of delivering patches with git ? I was used to svn and could easily do an
svn up myfolder/myfile.whatever
with git I am struggling, pulling commits/files from a tested stage environment into a live one.
Or another approach of this question… How can I merge single files from one branch into another one without copying them into a stable branch and commit and push them again ? … I heard some cherry picking rumor..
A post like “the git deployment cycle” would be handy ;-)