Monday, March 22, 2010

Non-intuitive aspects of Git: handling of remote branches (especially creation)

Lately I have gotten to use Git as it is the production SCM of choice for my new employer (having recently taken over from Subversion). This is generally a good thing: while I had learnt to like p4 after using it for a while (and especially after reading "Practical Perforce"), and appreciate svn's finally replacing cvs as the "default open-source SCM, there is something to be said about efficient distributed SCM system. And there is lots of excitement behind svn: consensus is building that Git will become the de facto SCM for open-source development.

For the most part Git has proven to be worth the hype it has generated and working with it has been easy. But the first real speed bump for me was trying to get branches to work. Most documentation focuses on working with local branches (which are usually "personal", single user branchs), which have their uses for development by large teams, or heavily shared codebases. Nothing wrong with that.

But for my own uses day-to-day uses with open source projects, it is so-called remote branches (ones that live on shared "master" repository) that matter more. Specifically, branches used for "legacy" versions, needed for adding patches for versions other than the most recently released stable: having "1.3" and "1.4" branches while trunk/mainline/master being used for upcoming "1.5" version (for example).

And this is where things get bit unintuive and complicated. Fortunately, after googling for an hour, I found this article, which gave me specific recipe I needed:

# 1. Create the remote branch
git push origin origin:refs/heads/new_feature_name

# 2. Make sure everything is up-to-date
git fetch origin

# 3. Then you can see that the branch is created. # (this should show ‘origin/new_feature_name’) git branch -r # 4. Start tracking the new branch git checkout --track -b new_feature_name origin/new_feature_name # 5. Make sure everything is up-to-date git pull

plus absolute necessary follow-up for "Cleaning up Mistakes":

# If you make a mistake you can always delete the remote branch
git push origin :heads/new_feature_name

and that's it. I hope. If not, I'm sure to gripe about that in future. :-)

blog comments powered by Disqus

Sponsored By


Related Blogs

(by Author (topics))

Powered By

About me

  • I am known as Cowtowncoder
  • Contact me at@yahoo.com
Check my profile to learn more.