- Mac OS X: Open up a
terminal, and type in the command
git. If it isn’t installed, it should prompt you to install it.
- Windows: Install Git for Windows. Right click on a folder and choose “Git BASH” to open up the command line.
First, we will do a very basic change
First, we need to tell git who we are. Everything we do will be labeled with our name and email address:
git config --global user.name "Rick Wash" git config --global user.email "email@example.com"
Retrieve a copy
First, we need to clone a copy of the BITLab website. This only has to happen once:
git clone firstname.lastname@example.org:workshop
This should download a new directory, called
workshop, that contains a copy of the BITLab website!
Open up that directory and explore the files.
Make a change
Open up the file
index.html in the main folder. This is the front page of the website. Just under the main paragraph
description of the lab, add a new paragraph that informs the world that you just joined the BITLab. Save the file.
git status command. It should list your changed file as having been modified.
Stage the change
Next, we need to tell git that we made a change. This is called staging the change, and is done with the
git add index.html
If you run
git status again, it should now list the change as a staged but not committed.
You can keep making as many changes as you want, and keep staging them. Git knows about them once you stage them, but that’s it. IT doesn’t actually do anything. Once you’ve got something you are happy with, you should commit it to the repository – make the change official and permanent.
This will prompt you for a commit message: a message where you can describe what changes you made in this commit. It should be conceptually what you changed.
Congratulations; you just made your first commit to git!
Interacting with the Central Repository
Remember: by default, git always works with your local repository. So your change is stored on the local repository,
but it hasn’t been moved to the central server yet. To do that, we have to learn
First Person: Push change
One person: since nothing has changed in the central server since you got your copy of the repository, you can just directly push your changes to the server with the command
If this worked, you should see your changes on the workshop webpage. (You may need to refresh the page in your browser.)
Second Person: Pull and Merge
Now, the second person should try to use that same command:
git push. You’ll get an error; something about a
non-fast-forward change. That means someone else has pushed their change since you last updated your repository. So
what you need to do is pull those changes down from the central repository, and merge them into your current local
It may just work, or it may ask you for a commit message if it had to do some kind of merging of content. Once that works, then you’ve got an up-to-date local repository with new changes, so you should be able to push them back to the server:
If this worked, you should see your changes on the workshop webpage. (You may need to
Everyone else can do this now, also.
OK, now everyone should open the
index.html page again and change the title of the page (the 2nd line of the file).
Save the file, then
git add index.html git commit
Since I did this first, everyone else is going to have a conflict: two conflicting changes to the same line of the file. Uh oh! Previously, git just automatically merged everyone’s changes. But this time it can’t; it doesn’t know what to do. To uncover this problem, run
This will pull the changes from the server. It will tell you that there is a conflict between the version on the server and your version, and it will ask you to fix it.
Open up that file and look at it. It will have both lines in it. Edit this file to make it look like how you want it
to, and then go through the normal
commit process to make your change:
git add index.html git commit
There. Now you’ve resolved the conflict, and you should be able to
git push the changes.
Next, we are going to create a branch: an easy way to separate out new ideas from your main line of work. For this
exercise, we will create a new branch to edit the summer REU job ad:
Create new branch
First, we need to create a new branch. Note: this only creates a branch in your local repository
git checkout -b summer
This creates a new branch from the current code, and sets your current repository to be using that branch.
Now, you can make your edits. Edit the
summer.html file. At the end of the line describing the project you are
working on, add that it was “Filled by
Next, you need to do a standard commit:
git add summer.html git commit
There, you should have your code checked in to your new branch.
You can easily switch back and forth between branches.
Switch back to the
git checkout master
Look at the files. They are back to before. Now switch back to your summer branch
git checkout summer
Your changes are back. You can work in either branch without disturbing the other.
Push to server (optional)
By default, branches are local; they only exist on your local computer and changes never get pushed to the server,
even when you
git push. If you want to specifically push a branch, do:
git push origin <branchname>
That will push your branch to the server, so it will exist on the server also. This isn’t always necessary.
Merge changes back in to master
Once you’ve made all the changes you want to in your branch, you usually want to merge those changes back into the
master branch. To do that, you first change to the master branch, and then you
merge in the other branch:
git checkout master git merge summer
That should pull the changes from summer, and merge them into the master branch. If it doesn’t produce any conflicts, it will be really smooth. If it does cause conflicts, it will ask you to resolve them to complete the merge. You’ll also be asked for a commit message about the merge.
Look at the log to see the changes:
git log --graph --oneline
Now that you’ve merged, you can push your changes in master to the server:
You should see your changes show up on the workshop website. You may need to pull (and possily resolve changes) before you can push if other people also made changes to that file.
An exercise for today:
Create a new branch to work in.
In that branch, I want you to add yourself to the people list. To do that, look under
people/undergrad. You’ll see a bunch of files for existing undergrads. Copy one of those files to your name, and then edit it to add your information. Find a picture of yourself, edit it to be exactly 50x50 pixel, and save it under
images/people. Put the name of that file as the thumbnail image in your page.
Check in the new files to your branch.
Merge the changes into the
Push those changes to the server.
Check and see if you appear in the people list.
Go back and fix any issues. Check in new changes, and push them to the server. Try to work in your branch, and only merge once you think you’re ready.
A few neat advanced uses of git.
When you delete a file, you also have to tell git to delete the file. You do this with the command
git rm <filename>
If the file still exists, it will be deleted. Like all changes, this one needs to be committed.
You can actually ask git to tell you who wrote each line of a file:
git blame summer.md
Seeing the changes
If you aren’t sure what all has changed, you can use the
git diff command to ask git to provide a list of all the
changes in each file:
You can specify only a specific file if you want:
git diff summer.md
You can also got back to old versions and look at the differences between now and then. To do this, you need to find
the name of the previous commit using
git log git diff 5d98d8e95
Labeling specific versions
Often, it is a good idea to label a specific version with a name, such as “version1.0” or “demo_for_emilee” or something
like that. In git, this is called a
tag. To label the current version, you just do:
git tag <tagname>
Tags are really useful because you can go back and easily find old versions of your code with checkout:
git checkout <tagname>
Tags by default are local – they only exist on your local repository. Even when you push, it doesn’t copy the tags to the server. If you want to, you can tell it to push all your tags to the server with
git push --tags
or you can just push a single tag with
git push origin <tagname>
Throwing away changes
If you want to throw away all of your changes, you do:
git reset –hard
This will reset your files back to the last checkin
There is a handy command called
git hist that will show you a nice, condensed history of the changes. To use it, you
have to first create an alias (only needs to be done once):
git config --global alias.hist 'log --pretty=format:\"%h %ad | %s%d [%an]\" --graph --date=short' git hist
There is a very useful git book online: https://git-scm.com/doc