Improved importing to bitbucket

Earlier, I wrote about a way to import an exisiting git project into bitbucket. I’ve since discovered a much easier way to do this using git’s own commands. Instead of having to use git’s daemon mode and have bitbucket import your repository, you should setup a new bitbucket repository and push to it. Assume you have a new repository, do the following two commands at your terminal. The key is the -u switch, which sets the master branch to track the remote repository.

git remote add origin git@bitbucket.org:user/newproject.git
git push -u git@bitbucket.org:user/newproject.git master:master

This blog serves as a good way to document what I learn.

Importing to BitBucket

When bitbucket added git to their code hosting service, I signed up to try out the service. Primarily since they offer unlimited free private repositories, which is perfect for one-coder projects like this blog. Each repository also gets a wiki and an issue tracker.

Creating an account was straight forward, I then had to import my self-hosted git repository to bitbucket. This wasn’t too difficult, after opening port 9418, which is used by the git protocol, I did the following.

1. Let git know that I wanted to export my repository


cd /var/local/git/foo.git
touch git-daemon-export-ok

2. Run the git daemon, temporarily.


git daemon --base-path=/var/local/git --export-all

You could run it idefinitely, but I’d rather it run when I need it to.


git daemon --base-path=/var/local/git --detach --syslog --export-all

3. Import the repository into bitbucket with this repository URL.


git://oscarm.org/foo.git

Once the import was successful, I stopped the git daemon. The final thing to do, is update any repositories that used my local bare repository as the origin to use bitbucket as the origin. In each repository, I had to edit the .git/config file and update the origin url to something like:


url = git@bitbucket.org:omerida/foo.git

Working with git branches

I can’t seem to remember the specicfic magic git switches when pushing and pulling branches between different git repositories, so I am writing it down here.

1. Create your local branch for development

git checkout -b my-branch

2. Push local branch to remote server & track it.

git push -u origin my-branch

3. Checkout and track a remote branch

git fetch<br />git checkout -b my-branch origin/my-branch

Alternatively:

git pull<br />git checkout -b my-branch origin/my-branch

Use git and subversion together.

Are you still using SVN but have some users clamoring to try out git? Kris.me.uk details all the commands and workflow to make it work.  While I’ve known that git had some svn integration available, I prefered to switch cold-turkey to git.  You can read the reasons I switched to git.

This article looks at not replacing subversion but continuing to use it as the master source repository and use one or more git mirrors to provide git for those that are familiar or wish to try it. Having subversion as the master repository can also alleviate management worries around authoritative sources, learning curves and any lost productive during upskilling, and other barriers to change. Those users using git can interact with both the subversion master and git mirrors, committing any work to be shared with all users back to subversion as and when appropriate.

Subversion Master With Git Mirrors – kris.me.uk

Why switch to git?

Get ready to clone.

Clone … What could possibly go wrong?

If you’re a coder, you’ve already heard about distributed version control systems (DVCS) and git in particular. I was content, almost complacent, in my usage of subversion to manage my source code, both for personal projects and at work. Subversion was intended as a “compelling” upgrade for CVS, and the next version control system (VCS) I used had to be equally as compelling. I think git has cemented itself as the preferred DVCS within the Open Source community. No doubt services like github have helped popularize it over bzr and mercurial. I’ve switched over to git over the course of the last month, these are some of my motivations and a record of what I learned along the way.

Why not stick with Subversion?

Subversion, since it has been around longer, enjoys better support in text editors, IDEs, and GUI front ends . It’s easy to setup a repository that you can share with a collaborator, or sign up for a hosted repository. It’s killer feature is the ability to fetch parts of a remote repository via the svn:externals feature. I’d used that extensively to organize projects and track 3rd party software such as Pressflow or Zend Framework. Git does not have an alternative as straightforward as svn:externals.

Over the last year I noticed that I wasn’t committing code as often as I should be, resulting in a lot of conflicts when I did try to do an inevitably large commit. Ideally, I would want to have a lot of frequent and small commits. When I tried to use branching and merging in Subversion, it was tedious and felt that one misstep would result in lost work or a bad merge. Even though merge tracking was added to subversion in version 1.5, my early exposure to it has caused me to avoid it like the plague. That’s a shame, because branching and merging is very useful for keeping new features from mixing in with mainline development until it is ready. Finally, at work we’d moved to a repo hosted on assembla.com and lost some useful pre-commit hooks for keeping PHP syntax errors and debugging code from being committed. A year later, it seems our group is the only ones still using this repo so I’ve been contemplating moving back to one under our control.

I know one option would be to use git-svn to use git locally and somehow push changes to the subversion repo, but I preferred to ditch the latter wholesale and not worry about having two systems in place. There’s enough to keep track of as it is and version control should simplify things, not complicate it.

Git has quite a learning curve

Understanding the terminology of git is confusing, particularly if you’re used to working with subversion. It’s not just your working copy and the repository anymore – now there’s a stash, the index where your commits are staged, the local repository, and the remote (or origin) repository. A good front-end can really help, if you are on a Mac I’d recommend using one of the active forks of GitX. This interactive cheat sheet also helped me to figure out git and what some of its commands do (Hint: click on the colored boxes). I think you’d be better off if you could somehow forget everything you ever learned about subversion.

You’re work flow has to change too, since you now have to remember to push, that is send, your commits to a shared repository, and also fetch and merge (or pull) the commits that your colleagues have pushed to a shared repository. A good front-end or first-class support in your editor/IDE of choice really helps here.

Git is useful once muscle memory kicks in

Once we initialized our repository and started committing changes, it didn’t take more than a day to get comfortable with using git. There were a couple instances where I was jumping to my co-workers cubicle to figure out how to send my changes to him, or to learn about the difference between git’s fetch and pull commands. Google and StackOverflow were most helpful in finding answers to our questions and explaining the commands we needed to invoke.

I’ve found myself committing again quite frequently, after finishing small and discrete fixes and features. In the long run, having a more fine-grained record of changes will be useful. As promised, git also makes branching and merging extraordinarily easy. Its trivial to be working on a new feature branch, switch to the mainline development branch to commit a minor fix, the switch back to your branch and merge in the fixes you just committed. It takes just a handful of commands and you don’t need to worry about version numbers or direction, it just happens. I’ve found myself doing that 2 or 3 times during the day without worrying that I was one command line switch away from total devastation. Another cool feature we found in git, via the GitX front end, is the ability to stage and commit just some of the changes within a file.

If you’ve recently switched, or are contemplating a switch, to using git, please share your thoughts and experiences below. In the near future, I’ll be sharing the details of the work flow we’ve established and how to take advantage of git’s hooks to do useful things before and after commits.

Using git to deploy website code

Jow Maller outlines a straightforward system for using git to manage code from development copies and branches through production. The fact that deployment to live is automated, but I’d be worried about broken or unreviewed code getting deployed unintentionally. I think the best way to prevent that is to have live be its own branch, and then pushing changes to the live branch once they’ve been reviewed, tested, and blessed.

While his approach doesn’t require moving or redeploying the live site, I don’t think that works when you’re using Drupal.  You’ll want to track drupal core, sites/all, and your local site’s folders in different branches, per this setup.

The key idea in this system is that the web site exists on the server as a pair of repositories; a bare repository alongside a conventional repository containing the live site. Two simple Git hooks link the pair, automatically pushing and pulling changes between them.

A web-focused Git workflow | Joe Maller