This community is built on collaboration. And that is why all the code that comes up in the hackathons is open source.

In this blog post, we will try to encourage you to join your forces with us. As you have probably seen, we use github to share code and git as our version control system. But don’t let that scare you. Our projects are quite young and as such you’ll find that is very easy to get started. There are just two steps where git is involved: getting the code and sharing it with the rest of the community. Well, then there’s the hacking in between, but that’s where you get in .

First, you are going to need to get yourself a git client. If you are a linux user, I suggest that you get it using the usual package management system on your distro; Mac users can use macports and if you are Windows guy, have a look at msysgit. I’ll be using linux to walk you through, so take that into account if you are on a different setup.

Then, create an account on github. The image above, is what you will see when you have an account ready and you go to any repository page. So, once you are logged in, go to any of our projects and hit that fork button. We will use SoundFuse in our case. After you do that, you’ll be brought to your own repository where you can see the cloning URLs:

So now we are ready to execute our first git command. Copy the URL of your repository and execute the following command. Note that you cannot just copy-paste this command since the URL is unique to your user.

droid@host:~ $ git clone git@github.com:{your-user-goes-here}/SoundFuse.git

Also, if you want to keep up with the changes in the community repository (and you really should), I suggest you add a remote (or link) in your repository so that you can keep your repository up to date. This command is safe to copy paste:

droid@host:~ $ cd SoundFuse
droid@host:SoundFuse $ git remote add community git://github.com/AndroidAalto/SoundFuse.git

Now the code is yours and you can do whatever you want with it. If you have something in mind that you want to contribute I suggest that you think for a while how can you split that work in small pieces for your commits. Why is this important? Because you want to keep other people motivated about your code and the best way to do it is by helping them understand it.

So, after you have something you are willing to share, it’s time to push your changes to your github repository. You can do this for each commit or not: I’ll let you decide on that.

However, before you push your changes, I suggest you get the latest changes on the community repository. Note that this can lead to potential conflicts, since the repository could have changed since you forked. Now, there are two strategies to do this: merge and rebase. I suggest you use rebase always for now. So this is how you should do that:

droid@host:SoundFuse $ git fetch community
droid@host:SoundFuse $ git rebase community/master

Now, we have the most up to date code with our changes. Let’s push that to your personal repository. Note that after this your changes will be visible in your public github account.

droid@host:SoundFuse $ git push origin master

After you have something you are proud of, the next step is to notify the community about what you have done. Send a pull request and write a small description of what you have done in general terms (the specifics should already be contained in the commit logs, right? ). To do so, just go to your own repository page and click that “Pull Request” button that is next to the “Fork”. You’ll be greeted with the following:

Specially check the top part. You should really understand what it really means: “You are asking AndroidAalto to pull N commits into AndroidAalto:master from gerard:master”. That is you are asking a user to get N commit into the community repository from your own. It shouldn’t be that surprising by now, I hope .

And that’s about what I wanted to explain. Now, I’m sure that if you juggle with git for a while, you’ll want to do more fancy things with it. And there have been some side steps that I have avoided explaining. For instance, how to resolve a conflict or what is the difference between merge and rebase.

Why is that? It would be pointless to rewrite one of the many good manuals and howto’s that you can find in the net. So don’t be shy and show your google-foo. Feel free to point any good resource that you come up with. From my side, I’ll point out that git has possibly one of the best set of man pages that I ever seen, so be sure to check that (try git help {any-git-command}).

On the other hand, if you want to talk about git and have some questions, feel free to ask us in the comments or even better in one of the community events.

Happy Hacking.