This project is read-only.

GIT Explained

GIT differs a lot from "conventional" source code managers.
GIT uses a distributed model and works offline/disconnected locally on your harddrive. Being disconnected and working locally on your harddrive instead of connected to a central has huge benefits for performance when doing operations such as branching and merging. GIT has a highly optimized model for doing these kinds of operations.

More on why we picked GIT can be found here

Some tutorials:

GIT Basics
Contributing with GIT

Linus Torvald on GIT at Google


If you're new to GIT, there are a great deal of resources out there to help you get started. What toolset to chose is entirely up to you for what you prefer; command line tools, UI tools that comes with MSysGIT or Tortoise GIT on the Windows platform for that matter.


The development is focused on providing a stabile version of the source code at any given time. Continuous Integration along with test-driven-development helps us achieve this goal. Below is a drawing of the main branches used. The master branch is what is considered production ready code and is maintained by even fewer persons than the other branches. The development branch is where core development is done, only a few selected persons has access to this and the contribution branch. The contribution branch is used as a place were we do what is known as cherry picking from other forks (look below for explanation on contribution), all build scripts apply to this branch as well. If contributions are considered safe and working, they are merged into the development branch together with core development. When the merge is considered good and quality assurance has been done, code is merged down to the master. Our goal is to provide an automated build for any changes to the master branch that will publish binaries automatically to the Codeplex site.

Core development branching:

Branch by purpose

We recommend to use branching a lot, as it is so cost-effective in GIT. Branching by purpose means that you should do a branch every time you want to change path. If you're looking to add a new feature, fix a bug or just do a spike, branches will help you organize your code and help you get back to where you started without you having to track that information manually. Whenever one is pleased with the result, one can either commit the branch directly, or as we would recommend; merge it back to were you started the branch and commit and push from there. This gives a cleaner history and a lot easier to follow what is going on.


We really would love it if people would like to contribute to Balder, that being said. In order for Balder to remain in a stabile condition, we have decided to limit the number of people that has access to change the main branches.
In order to contribute, one needs to use the forking mechanism found on GITHub and create your own fork and then commit to that, team members will then do what is known as a cherry-pick from the fork-queue of any forks that has been created. To read more about how forking on GITHub, please go here.

For details on how to do this, please go here for a more indepth tutorial.

Last edited Oct 22, 2009 at 6:21 PM by adept, version 10


No comments yet.