SETUP
1. Setup a catkin workspace for your own ROS packages (indigo or higher):
   => http://wiki.ros.org/ROS/Tutorials/InstallingandConfiguringROSEnvironment
2. Go to the 'src' folder of your catkin workspace. 
3. Clone git repository
        git init
        git remote add origin <git-repository url>
        git pull origin master
4. Set git configurations:
        git config --global user.name <username>
        git config --global user.email <email>
5. Create the file '.gitignore' and add the following lines:
        .gitignore
        /CMakeLists.txt
        *.pyc
   Also include any other files/folders that you do not want to commit to the
   git repository. In particular any files that are generated by the
   IDE/editor you use for coding.
6. Check out "Running sml_world for the first time" in the wiki

RULES
1. Do NOT add commits to the 'master' branch when working on a new feature! 
2. ALWAYS work in a personal branch.
        git branch <personal_branch_name>
        git checkout <personal_branch_name>
        OR
        git checkout -b <personal_branch_name>
3. MERGING to the master branch is done ONLY by the Research Engineers, never
   by students.
4. To integrate your personal branch into the master branch create a 
   'pull request' on bitbucket.org and add AT LEAST ONE Research Engineer as
   a Reviewer.

TIPS
1. Work with micro-commits, committing important changes indivudally in small
   chunks.  This makes rolling back errors easier.
2. Comment thoroughly!  Your future self and people that work with your code
   in the future will be thankfull.
        * However, not every line of code needs to be commented.  Write
          meaningfull comments.
                var = 1 # variable var is set to 1
          Comments like the above one describe the obvious, more important
          is to know why 'var' is set to 1. If that is also obvious,
          commenting is not necessary
        * Use docstrings to describe what your function does.
          Ideally make use of the epydoc markup-language in these docstrings.
          => http://epydoc.sourceforge.net/manual-epytext.html
          This allows the automatic generation of a throught documentation
          of your code and the code of all other contributors.
3. If you code in python try to follow the style guide for python code:
   => https://www.python.org/dev/peps/pep-0008/
   This makes you code more readable and consistent through different
   contributors.