In this course we will use Git and Github for collaboration, version control, and homework submission. Git, along with other version control tools, are widely used in the software industry. This guide will show you everything you’ll need to use git in this course
Git is a version control system that keeps versions of your files in a “repository”, which we will provide for you using the Github hosting service. The repository will enable you to retrieve (“clone”, “pull”), locally save (“commit”), and share (“push”) your files from multiple locations, and it will enable us to easily access your code for grading. It also provides a backup mechanism for you in case you ever need to revert to older versions of your code.
The first thing you will need is a Github account. To do this, go to:
Follow the registration instructions.
After you’ve registered, you will need to join the “p532-13” organization. To do that, you should communicate your github username to the course staff so they can add you to the organization.
Github provides clients for both Windows and Macs at the following URLs:
An alternative git client is TortoiseGit:
You’re welcome to use whatever git client that suits your needs. The course staff prefers using the git command line program. Examples of using the command line are given below.
The git plugin for Eclipse is "Egit".
You will use git to (1) keep track of revisions as you work on your assignments, and (2) submit your assignments for grading. You will also use the github bug tracker to manage issues.
Each pair will form a team, and each team will create a repository for their work. Within this repository will be a directory for each assignment.
In order to set up a team, you will have to communicate the team members to a member of the course staff so they can create the team for you.
Once your team is established, you can create a repository for your work. All homework should be done in private repositories, so make sure to create a private repository.
To create your pair’s repository, log in to github.iu.edu. Be switch to switch your account context to p532-13. Create a new repository. The name of repository should be pairNN where NN is your two-digit pair number. The repository should be marked private. Since we’ve already created teams, your partner should immediately have access to this repository. At this point, you need to clone the repository to your computer and can start working.
There are a few important git concepts you need to be comfortable with. To begin with, there are “repositories”. At first cut, a repository is just a bundle of files that have a history of modifcations. When you created your pair repository, you made an empty bundle with no history. That repository lives on github. In order to make changes, you will need to bring that repository to your local computer, make changes, commit them, and then communicate those commits back to github.com.
Clone - cloning is a one-time operation you do to copy a repository from a server to your computer. Once you’ve done this, you now have the repository on your local machine. You can add, edit, or delete files within this repository as you would any other set of files.
Once you’ve made changes that you want to save to the repository, you’re ready for a commit.
Using the command line, the following clones a repository and changes into its directory:
git clone email@example.com:p532-13/pairNN.git
Status - you should always check the status of your repository before making changes.
Add - when you want changes or new files to be included in a commit (described below), you need to add those files. This step is often handled in the GUI clients by selecting files interactively during a commit. At the command line, the following adds a file to the set to be committed:
git add blah.txt
Commit - when you’re ready to save your changes to your local repository, you need to commit them. You can select any files in the repository that have been modified for a commit. You can also add new files to the repository or remove files. Once you’ve selected what you want to save, you can commit giving an informative message about the change.
At this point, it’s important to remember that you’ve made changes only to your local repository. Your team members cannot see these changes. If your hard drive failed or your laptop got stolen, those changes would be gone forever.
So once you’ve committed (perhaps several times) and are ready to save this batch of commits to the server—
and make them available to other team members— you need to push.
At the command line, the following will open an editor for you to compose the commit message and then commit everything that’s been added:
git commitIf you want to specify a message on the command line, you do so with:
git commit -m "My commit message"
If you want to skip the add step above, you specify the files to commit:
git commit -m "My commit message" blah.txt
Push - a push communicates a batch of commits on your computer to a server. Once commits have been pushed, they are forever a part of the history of the repository. Team members (and graders) can see the changes, and if something happens to your computer, at least those commits you’ve pushed will still be available on the server.
Pull - a pull communicates a batch of commits on the server to your computer. A pull is how you update your local repository will changes your team members have made. It’s a good idea to always do a pull before you start any new work to avoid potential conflicts.
There are a couple things that you want to make sure you do.
Commit often. Push often. There is nothing worse than losing work and this will help minimize the awfulness in case something bad happens to your computer.
Don’t forget to explicitly add new files to your repository. If you create a new file within your repository, this is not actually a part of the repository until you add and commit it.
Write informative commit messages. Documenting the evolution of your work will help you understand what you were thinking when months later you’re trying to make a change to your code. It will also help other people (partners, graders, users) understand your project. Good programmers always write informative commit messages and value others who do the same. Messages such as “some changes” or “fixed some stuff” convey nothing useful.