Git Basics for Students

Knowing how to use source control is, in my opinion, an essential skill. It keeps you productive, can save you from unnecessary headaches, and is a major part of the toolchain at your future job. And yet it most schools either gloss over or don’t cover source control at all.

If you’re wondering why you would want to use git while you’re at school, here are just a few reasons:

• someone copies your code and you get accused of being the copier, your commit history save you
• you accidentally rm -rf your local code directory, you can just clone down from your remote repository
• working on a project with multiple people, no need for ugly systems like Dropbox or emailing each other code
• simply clone down the repository from the remote repository instead of copying the latest version of your code onto a USB drive every time you switch computers

A few months ago I walked by a lab where the instructor was attempting to teach Git. Everything coming out of his mouth was incorrect. For all students who haven’t already learned how to use Git, here you go.

Note: This post isn’t going to make use of any Git GUI programs, command line only. Also, the topic of working in a repository with multiple people deserves it’s own post, and so I won’t be covering it in this one.

Creating and Cloning a Repository

The easiest way to start out is via Github. It’s simple enough to git init inside a directory, but setting everything up from scratch isn’t as basic as I’m going for. So set up an account on Github (or BitBucket) and create a repository for whatever assignment you’re working on right now.

Github’s repo. create page has nice drop downs for .gitignore and licenses.

Next, clone down your repository using git clone <url>. Unless you’ve previously set up your Github account for ssh just use the HTTPS url.

You can click the clipboard to automatically copy the url.

Note that the format of the url is always the same. If you can remember this it saves you the trouble of going to the repositories page to get the url.

SSH: git@github.com:username/repoName.git
HTTPS https://github.com/username/repoName.git

Making Commits

After making changes to code, adding or removing files, updating your readme, etc. you’ll want to commit those changes. A commit represents a snapshot of all the files in your repository in their current state, meaning if you need roll back to a previous commit at some point in the future you can do that.

In order to make a commit we need to stage modified files. Typing git status will let you see what files have changed, and git diff <filename> will show you the changes made to that file since your last commit. You can use git log to show a list of your commits. Note that when I say tracked I’m referring to files that have been included in at least one git commit, meaning their status is being tracked by git.

Here we can see that I’ve modified configfile.py since my last commit, and there is an untracked file main.py

There are a few ways to stage files to be committed.

stage a single file: git add <filename>
stage all tracked or new files, git add .
stage all tracked or deleted files, git add -u
stage all tracked, new, or deleted files, git add -A

Note the difference between git add . and git add -u. I generally use git add . and if I need to delete a file I’ll use git add <filename>. So, in the previous screenshot if I use git add . both configfile.py and main.py will be staged.

git status will also show you what files are staged and ready to be committed.

Next is the commit itself, type git commit -m “commit message”. Try write commit messages that are brief but descriptive of the changes you’re making, or just get some inspiration from http://www.commitlogsfromlastnight.com/.

Once you’ve made your commit, you can continue to make code changes and additional commits, or push to the remote repository on Github. The push command pushes all of your local commits to the copy of the repository on Github, so you or someone else could then clone the repository and have the latest code.

To push type git push <remote> <local branch>:<remote branch>. When starting out you shouldn’t worry to much about what remote, local branch, or remote branch are, you can just type git push origin master. After you push you’ll be able to see the update history on the Github page for your repository.

Other Tips

• to get new remote commits in a local repository use git pull
• if you make a commit and don’t like the commit message modify it

git commit --ammend

• you can also add stage add another file to the previous commit and keep the same commit message

git add <some file>
git commit --ammend --no-edit

• use the following command when you want a git log, write an alias for it and add the graph option if you want

git log — graph — pretty=format:’%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset’ — abbrev-commit

Conclusion

Once you’re comfortable with these basic commands you’ll probably want to start to working with git repositories with many contributors. This would involve things like branching, rebasing, and pull requests. There are plenty of guides out there for these topics, but I may write another post to cover some of them.

I’d recommend going through the patchwork tutorial.

Some good resources are the Atlassian tutorials:

Git - Branches

Git rebase

You should probably also learn about things unstaging, reverting, merging, etc. Honestly, spend as much time learning Git as you can.