Using git and GitHub

Developing on pioneer means using the version control tool 'git' and the github website. git especially has a reputation for having a steep learning curve, so here we'll try to give you enough knowledge to be dangerous!

Prerequisites

A working installation of git, a GitHub account, and comfort with using the command line of your chosen operating system.

The GitHub sign-up page is here. Make a note of your user name as you'll need it to make your local pioneer repository.

If you're on Linux you quite quite likely have git installed already. If you can type git --version at the command line and get a version number back you're good to go. If you don't have it the package repository for your distribution almost certainly will. Use your distribution's package management tools to download and install it.

If you're the type of Linux user who builds everything from source, rolling your own kernels, I'm going to assume you're already quite familiar with git, and this was not the page you were looking for :)

On Windows you have two options, Git for Windows aka msysgit, or Github for Windows which is essentially msysgit but with some extra stuff bundled. Some of which is good (posh git) and some of which is well, not (github's 'friendly' gui). Since both include the same command line tools and cross platform gui tools, either is fine for our purposes here. The github one may be more convenient to install.

On Mac OS X, git will have been installed with XCode as git is built into the XCode IDE. However, usage of git from from within the XCode isn't something I'm familiar with so isn't covered here. If you want to follow along with this document then if you elected to install the XCode command line tools, then the git commands below should work unaltered from a terminal window. If you didn't then you'll need to use xcrun to run the commands in terminal, either by adding xcrun in front of each of the commands or aliasing git and gitk to xcrun git and xcrun gikt in your ~/.profile. Have a look at this guide for details.

Creating your pioneer repositories

Git, as a version control system, stores all source files for Pioneer (or any other project you've chosen to store in git) along with their histories in repositories (usually shortened to just 'repos'). These are areas of a computer's file system where has git has been told to track and manage changes to the files placed in them.

There are three different repositories that you mainly deal with when developing pioneer.

• The upstream repo. This is the main Pioneer repository stored on GitHub. This is read-only except to the core team (and even they don't do their development there).
• The origin repo. This is a public Pioneer repository personal to you, but stored on GitHub under your username, so other people can see your changes. This is read-only to everyone except you.
• The local repo. This is your personal Pioneer repository on your computer, not accessible by anyone else.

Before you can start developing you need to setup both your origin and local repositories.

git clone git://github.com/<your gituhub username>/pioneer.git

git remote add upstream git://github.com/pioneerspacesim/pioneer.git

Basic operations

git branch

git status

git checkout <branch-name>

git branch <branch-name> ; git checkout <branch-name>
git checkout -b <branch-name>

gitk

git add -A ; git commit
git commit -a

git push origin <branch name>

Updating your branches

git fetch upstream

git merge

git pull --ff-only upstream master

git merge master

Getting code from other branches

git checkout <branch-name> -- <file-name>

git merge <branch-name>

Getting other developer's branches

git remote

git remote add <remote> <url>

git remote update

git checkout -b <branch-name> --track <remote>/<remote-branch-name

Keeping things tidy

git branch -d <branch-name>

git branch -D <branch-name>

git push origin :<branch-name>

git clean -n

git clean -f

Rebasing and cherry picking

Warning: Rebasing and cherry picking, although sometimes useful, can cause problems for other developers if you use them on commits that have already been published to github. Be careful and give sufficient warnings if you find you needing to use them in that situation.

git cherry-pick <commit>

gitk

git rebase <branch-name>

git rebase -i <branch-name>