BITlab: Behavior Information Technology

BITlab
404 Wilson Rd. Room 251
Communication Arts & Sciences
Michigan State University
East Lansing, MI 48824

GIT Workshop

Installing GIT

First Change

First, we will do a very basic change

Identify yourself

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 "wash@msu.edu"

Retrieve a copy

First, we need to clone a copy of the BITLab website. This only has to happen once:

git clone git@bitlab.cas.msu.edu: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.

Check status

Run the 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 command:

git add index.html

If you run git status again, it should now list the change as a staged but not committed.

Commit change

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.

git commit

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 push and pull.

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

git push

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 repository:

git pull

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:

git push

If this worked, you should see your changes on the workshop webpage. (You may need to

Everyone else can do this now, also.

Conflict

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

git pull

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 add -> 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.

Branches

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: summer.html

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 "

Commit

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 master branch:

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:

git push

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.

Exercise!

An exercise for today:

  1. Create a new branch to work in.

  2. 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.

  3. Check in the new files to your branch.

  4. Merge the changes into the master branch.

  5. Push those changes to the server.

  6. Check and see if you appear in the people list.

  7. 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.

Advanced Topics

A few neat advanced uses of git.

Removing files

When you delete a file, you also have to tell git to delete the file. You do this with the command git rm:

git rm <filename>

If the file still exists, it will be deleted. Like all changes, this one needs to be committed.

Blame

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:

git diff

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 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

Extra

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

More Information

There is a very useful git book online: https://git-scm.com/doc