Good luck to the merged Rails team and hopefully Rails 3 will kick ass! Let’s hope git will really deliver on this gig! Try to refrain from using git blame too much when resolving merge conflicts.

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

We switched to Git this morning. Before making this switch Gert-Jan (CTO of Floorplanner) asked me: “what is the advantage of Git over Subversion?”. I answered him and thought I’ll make a post of the answer as it can be useful for other bosses like Gert-Jan.

Since we started using Subversion, which was a couple of years ago, using a code versioning tool helped us a lot. We could work on Floorplanner with the whole team together without storing the “repository” on our remote FTP location (early days) or emailing changes up and forth (ancient times ). But when working with Subversion for some time, little things started to bother, i’ll sum them up:

1. We needed tutorials for creating a branch in SVN every time again
2. When merging the branch back, SVN didn’t know where that branch started.
3. When merging the branch back, each change was recorded back as the user who did the merge.

The consequences of these disadvantages.

We avoided creating branches.

Why is not creating branches bad practice?

I’ll give you an example. Sometimes when we were working on some big feature, we didn’t create a branch (it was a lot of work), we just committed it into the trunk when it was “kinda” ready. Then a sudden exception in the software that was online occurred, we now had a problem! That bug had to be fixed NOW, but the changes we just committed into the trunk were not fully tested and couldn’t go online. You understand this was a tedious process and resulted in more downtime sometimes.

But why is Git better?

1. Creating branches in Git is a lot easier than doing this in SVN.
2. Git keeps track where branches come from. So when creating a branch, merging back is very simple.
3. It keeps commit messages intact, when merging.

Conclusion

The whole point, remember this post is called “Git vs SVN for bosses”, branching is a joy in Git and this results in better being able to have access to different versions of the same software at the same time, which again results in being able to fix that bug NOW.

Other resources

http://git.or.cz/gitwiki/GitSvnComparsion

I just started working on an old Rails project after having neglected it for 15 months. Most of the view files still had the good old .rhtml extension. I was too lazy to rename these files by hand, both on my file system and in the git repository. I used the following Bash commands to do the job:

First, I renamed all the partials to the .erb extension. Note: I am not using .html.erb, as some of these partials are used in js-formatted responses as well:

for i in `find app/views/**/_*.rhtml`; do \
  git mv $i `echo $i | sed s/\\.rhtml$/.erb/`; \
done

The remaining files could now be renamed to .html.erb with a similar command:

for i in `find app/views/**/*.rhtml`; do \
  git mv $i `echo $i | sed s/\\.rhtml$/.html.erb/`; \
done

Note that this technique works with Subversion as well: just substitute git with svn in the command above. A regular rename is possible as well by leaving out git altogether!

Now my file names are Rails-compliant again, I can start refactoring all the code that is not up to current Rails standards anymore. Ah, the virtues of developing with a rapidly evolving framework…

I have been using git for a while now, and I believe I have the the basic workflow under control. Committing, reverting, using local branches for major refactoring work: been there, done that! However, I recently got some collaborators on my github-projects, I had to start working with other remote repositories and branches.

I found this blog post, which was really helpful. I am sharing some others things that helped me in the last couple of weeks. Hopefully, this saves other people some time Googling. If you know a better ways to accomplish these tasks, please let me know!

Things to remember about remote branches

Because I had some troubles discovering how to properly work with remote repositories, I am sharing what I found. The most important things to remember:

• Your local branches are not really connected to the remote branches. It is therefore possible to mix up branches, but this is usually not what you want
• Never forget to switch to the correct local branch (using git checkout local-branch.
• The names of the local and remote do not need to match.
• Before you can push changes from a local branch to a remote branch, all the commits of the remote branch have to be included in your local branch. This can be done using by executing git pull remote-name remote-branch in your local branch.

Checking out a newly created branch in a remote repository

Bart is implementing Merb log parsing for request-log-analyzer. He has put his progress in a separate branch of the github project. My local repository does not yet include this branch, but I want to check it out. Note that I am using a different name than the branch name on the github project.

$ git branch merb origin/generic_base
$ git checkout merb

When the new functionality is finished, the following commands will merge the changes in the merb branch to the master branch.

  # goto my local master branch and merge the merb-branch
$ git checkout master
$ git merge merb
 
  # push the changes to the master branch on github
$ git push origin master

Merging back a fork

Wes Hays is helping me out on the scoped_search plugin. He implemented OR in the query language in his own fork. I wanted to merge his changes back to master branch:

  # add a reference to the remote repository
$ git remote add gbdev git://github.com/gbdev/scoped_search.git
 
  # create a local branch for the fork to follow a remote branch
$ git branch gbdev-fork gbdev/master
$ git checkout gbdev-fork

Now, my local gbdev-fork branch contains Wes’s code. Because Wes’s repository was forked from my repository, git will know that most of the history of my master branch and gbdev-fork branch is the same.

After some testing, I was ready to include his changes by merging the gbdev-fork branch into my local master branch:

  # go back to my master branch, and merge the changes
$ git checkout master
$ git merge gbdev-fork
  # push the changes to the master branch at hithub
$ git push origin master

Pushing tags to a remote repository

You can create tags locally, but you probably want to send them to the remot repository as well:

  # create a local tag "tagname" with the given message.
$ git tag -a "tagname" -m "message" 
  # send your tags to the remote repository "origin"
$ git push origin --tags

I personally am a fan of the git version control system. The best part of git is its speed, and the simplicity of using local branches.

Local branches are very helpful if you are working on different features at the same time but want to keep them apart. An example: it happens all the time that I am working on some feature and than I have to put my current work aside to work on a high priority issue. Once this issue is solved, I need to commit the changes and usually do a deploy of the web application so that the problem is solved as soon as possible. With Subversion, I sometimes commit files that were part of the unfinished feature I was working on before I started on the high priority issue. If I am not careful and deploy those files, unfinished work will be put into production and this can go horribly wrong, like every page request returning a 500-error of our high traffic site .

Using git, I can put my current work aside easily by using git stash. When I am finished with the high priority issue, I can revert to my previous work with git stash apply.

Another option: branching the project (using git branch feature) if the feature I am working on is invasive and than switch branches for high priority issues using git checkout master. I can go back to the feature branch with git checkout feature, followed by git merge master to merge back the changes I just made in the master branch. Branching and merging is very fast in git and merging is not the PITA like it is in Subversion.

However, our main code repository will probably remain in SVN for now. Luckily for me, I can use git-svn locally to profit from these advantages. I found an informative page on installing and getting started with git-svn on OSX. If you know Subversion, this page is helpful to translate Subversion commandos to their git alternatives.