Because Jaap finally convinced Gert-Jan, we have moved to the Git version control system for the main Floorplanner repository. Now we can use branches for different functionality far more easily. As an easy reminder to some common Git tasks I will need regularly, I have written down some Git recipes. This is basically meant for me and my fellow developers, but maybe it can help you as well. Suggestions to improve my workflow are welcome!
Displaying the current branch in your prompt
Because I will be using branches more regularly now, it is nice to know what branch I am currently working in. git branch will provide this information, but it can be more direct by including the current branch in your terminal prompt.
To display the current git branch in my terminal prompt, I have added the following to my Bash configuration file ~/.profile:
parse_git_branch() {
git branch 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/ \[\1\]/'
}
PS1='\[\033[01;37m\]\w\[\033[00;35m\]$(parse_git_branch)\[\033[00m\] \$ 'I use a black, semi-transparent terminal with white text, and pink branch names. Change the colors to your own liking!

Working on a remote branch that is not available locally yet
If you want to help out on a branch that somebody else started and has pushed it to the remote repository, you can checkout this branch and make it “track” the remote branch.
$ git checkout -b newbranch origin/newbranch
In this example, origin/newbranch is the branch in the remote repository. Locally, this branch will be called newbranch. A simple git pull will update my branch with the latest changes from the remote branch later on, git push will send my changes to the remote server.

Creating a new branch and pushing it to the remote server
Sometimes I want to start a new branch myself if I want to work on a new feature or on disruptive refactoring of the main codebase.
$ git checkout -b feature
The feature branch is now available locally. After some time, I want to share my current changes in this branch with other developers. I should make the branch available in the remote repository so other can access it like I described above.
$ git commit -m "Added initial version of %feature%" $ git push origin feature

The feature branch will now be available to other developers as well. Note that the local feature-branch is not tracking the remote branch of the same name. This can be enabled by changing the configuration of the repository.
Merging a branch
After work is completed on my feature-branch and it is tested thoroughly, I want to merge the branch with the master branch of the project. To make sure the merge with the master branch is seamless and all possible merge conflicts are handled beforehand, we first run git rebase. This ensures that the changes in the feature branch are relative to the latest commit to the master branch and can therefore be applied by a “fast forward”. It is best to run git rebase from time time to time while you are developing in the feature branch to make sure your work does not divert to much from the main development in the master branch.
# make sure that the current branch is seamlessly # mergeable with the master branch $ git rebase master # switch to the master branch $ git checkout master # now, merge the feature branch $ git merge feature # publish the merge to the remote server $ git push origin master

I can now delete the local and remote feature branch, as the changes have been incorporated in the master branch:
$ git branch -d feature $ git branch -d -r origin/feature
Tags: bash colors, branches, checkout, git, origin, pull, push, remote



December 14th, 2008 at 10:31 pm
Thanks for the post. I will need to improve my git skills asap.
February 23rd, 2009 at 1:25 pm
Just a few remarks:
There’s a bash completion script somewhere in git’s contrib/ directory that has a more powerful function for showing the current branch in the prompt. For example, it can also tell you that you’re in the middle of a rebase.
“git checkout -b newbranch origin/newbranch” is a purely local operation. IOW: The remote’s branch is already available locally, in the remote tracking branch origin/newbranch. What the command does is just to create a local branch head from it (and it checks it out).
To actually get stuff that is not available locally yet, you need “git fetch” (defaults to “git fetch origin”).
And about “rebase”, that’s rewriting history. If you share that branch with others (e.g. by pushing it to some remote repo), using rebase is a generally a bad idea. See “RECOVERING FROM UPSTREAM REBASE” in git-rebase(1).
And “git branch -d -r origin/feature” also deletes your local remote tracking branch, not the branch that exists in the remote repository, for that you’d need “git push origin :feature”