Getting started with BitBucket & SourceTree – Part 1

I have been using version control for a little while now and although I am not a developer, I really got into it once I was involved with a web app project. The developer had done most of the work, but due to time constraints he couldn’t always get around to all the bug fixes. I initially started making small changes like fixing typos, but once I got used to the idea of version control I started getting braver as I knew I could easily roll back changes if I screwed up bad.

Recently I needed to start up a new repository for a project so I thought it would be an opportune time to document the process. Of note is that repositories don’t necessarily have to be restricted to traditional coding projects. I use a repository for my SQL Server Reporting Services, and if you wanted to you could use it for other tasks such as switch configs or Powershell scripts (assuming you are OK with having them sit in the ‘cloud’).

So without further ado, let’s get started with Part 1: Creating a BitBucket repository and setting up SourceTree.

You’ll need to visit BitBucket and sign up for a free account. Once you get all of that stuff out of the way, you can login and you’ll be sitting at your home screen. From there, go to the Repositories dropdown and choose ‘Create repository’. Give some thought to the name as you may end up with a bunch of repositories down the line and the last thing you need is to have them all named ‘Test Project’ or ‘Files’.

Most of this is fairly self-explanatory; with regards to Forking, it will likely be based very much on a case by case basis of who will be using the repository and what the expectations are. There may be times where only one person uses the repository, but you still want the ability to fork. Other times you may have a team working on code and you’ll want to ensure that there are no forks so that everyone has the same base.

In this case I have setup a Git repository. I typically use Issue Tracking as having the integration is nice. With Issue Tracking enabled, I can directly relate a commit to an issue which lends itself nicely to finding what changes were made in order to fix a problem.

Once you have your repository settings customized, click on the ‘Create repository’ button. This should bring you to your new repository’s Overview page.

As the page suggests, the next step should be to download and install SourceTree. SourceTree is a free Git and Mercurial client that integrates nicely with BitBucket. It allows you to do all the important repository actions such as Pulls, Pushes, Commits, etc. and all with a decent interface on it.

The install is fairly straightforward, so I am going to skip over that part and jump right into the setup. After the install is finished, the first thing you will need to do is login with your BitBucket account.

Once you have logged in, you should see the repository that you created. You can highlight it and then select a local directory to sync to using the button at the end of the Destination Path field. Once you hit OK you will start syncing the repository to your disk. After this is done you will be asked if you have an SSH key that you would like to use. If you have an existing one, you can import it, otherwise you can choose No.

Now for the meat and potatoes: managing files. In this case I have a piece of code locally that I would like to commit. By default it appears in the ‘Unstaged files’ section. Once I click the check box next to it, the file will be moved up to the ‘Staged files’ section – this means that it will be part of the next commit that I push out.

To push the code out to the repository, click on the Commit button. After that you can type a description in the text box down on the lower right. This is important because if you find that you ever need to roll back to a previous commit, chances are you will be referencing the comments to figure out which revision you want and/or where things went wrong.

Lastly, I like to check off the ‘Push changes immediately to …’ box. This automatically pushes the change back out to BitBucket. If you want, you can queue up a whole bunch of commits and push them out all at once – I  like to push them out as I do them so at the very least if I screw up that file at a later point I can still roll back fairly easily.

Once that is all done, just hit the commit button and you’ll be good to go.

That’s it for now; I’ll do up another post real soon covering things like rolling back and finding the changes between files. In the meantime, enjoy.