Git How-To

Public Key

Before using Git, you have to get access to our repos. The software we use to manage Git access requires your "public key."

To get access, follow the instructions in this link to generate the public key for your computer. [1]

This process will produce a public key file (~/.ssh/id_rsa.pub) You should send or copy this email to the IGVC project manager, who will add it to the Git system and grant you appropriate permissions.

Getting Code from the Server

Currently, the software team uses Git, so you will need to clone your team's repository to your machine as follows in the folder of your choice:

Robocup

git clone ssh://[username]@robojackets.org/git/robocup/software software

IGVC

git clone ssh://[username]@robojackets.org/git/igvc igvc

This will check out a copy of the repository. For those of you that have used SVN before, remember that committing only commits to the local (on your machine) repository, and you need to "push" to put something on a different machine.

Changing Remote to the Server

If you got the code off of a flash drive, you will need to reset your local copy of the git repository to use the server instead. Go into your software folder and execute:

git remote rm origin
git remote add -t master -m master origin ssh://[username]@robojackets.org/git/robocup/software

Committing Local Changes

As you add changes and make something work, you should commit your changes to your local repository. This will allow you to manage changes by making use of git, if you want to go back. Once you have something working, execute the following command:

git commit -a

You will add a meaningful commit message to say what you did. This is important so that other people can understand what you are doing. After committing, you can check that you have committed things by running status:

git status

Updating Your Local Repository

Because other people are making changes to the repository on the server, you will need to update your local repository from time to time to get these new changes. You should do this just before any commits to a server so that you don't break the build on the server.

git pull

You may need to jump through some hoops to merge things properly if there are conflicts.

You can set up an alias to automatically update multiple repositories. For example, if you have the software, electronics, documentation, and mechanical repositories inside a folder called robocup, you can add the following line to your .bashrc file located in your home folder.

alias update_robocup='echo "Checking..."; cd /home/UserName/robocup/electrical; echo "Electrical: "; git pull; cd ../mechanical; 
echo "Mechanical: "; git pull; cd ../robocup_docs; echo "Documentation: "; git pull; cd ../software; echo "Software: "; git pull; cd ../; echo "Done!";'

You'll probably have to edit that to work with the exact file structure you are using.

Committing Changes to the Server

Once you think you have something that should go on the server, you should first check to make sure it works, because if your code breaks the build no one will like you any more and all of the cool kids won't invite you to cool things and everyone will point fingers at you when you walk around campus. Commit all of the changes to your local repository and then push:

git push