A Simple Introduction to Git: a

distributed version-control system

CS 5010 Program Design Paradigms
“Bootcamp”
Lesson 0.5

© Mitchell Wand, 2012-2014

This work is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License. 1
 Learning Objectives
• At the end of this lesson you should be able
to explain:
– how git creates a mini-filesystem in your directory
– what commit, push, pull, and sync do
– the elements of the basic git workflow
– how git allows you to work across multiple
computers
– how git allows you and a partner to work together

2
Git is a distributed version-control system

• You keep your files in a repository on your local

machine.
• You synchronize your repository with a repository
on a server.
• If you move from one machine to another, you can
pick up the changes by synchronizing with the
server.
• If your partner uploads some changes to your files,
you can pick those up by synchronizing with the
server.
3
Git is a distributed version-control system

• Terminology: In git-speak, a “version” is called

a “commit.”
• Git keeps track of the history of your commits,
so you can go back and look at earlier
versions, or just give up on the current version
and go back some earlier version.

4
 A simple model of git
• Most git documentation gets into details very
quickly.
• Here’s a very simple model of what’s going on
in git.

5
 Your files
my-project docs manual.docx

user_docs.docx

src
main.rkt

module1.rkt

module2.rkt

module3.rkt

Here are your files, sitting

in a directory called my-
project

6
Your files in your git repository
.git

my-project docs manual.docx

user_docs.docx

src
main.rkt
When you have a git repository, you have an
module1.rkt
additional directory called .git, which points
module2.rkt
at a mini-filesystem.
module3.rkt

This file system keeps all your data, plus the

bells and whistles that git needs to do its
job.

All this sits on your local machine.

7
 The git client

.git

my-project docs manual.docx

user_docs.docx

src
main.rkt
This mini-filesystem is highly optimized and
module1.rkt
very complicated. Don’t try to read it
module2.rkt
directly.
module3.rkt

The job of the git client (either Github for

Windows, Github for Mac, or a suite of
command-line utilities) is to manage this for
you.

8
 Your workflow (part 1)
• You edit your local files directly.
– You can edit, add files, delete files, etc., using
whatever tools you like.
– This doesn’t change the mini-filesystem, so now
your mini-fs is behind.

9
 A Commit

.git

my-project docs manual.docx

user_docs.docx

src
When you do a “commit”, you
main.rkt
record all your local changes into
the mini-fs.
module1.rkt

module2.rkt
commit
module3.rkt
The mini-fs is “append-only”.
Nothing is ever over-written
there, so everything you ever
commit can be recovered.

10
 Synchronizing with the server (1)
a server, somewhere on the
your local machine
internet, eg. github.com

.git push
manual.doc
my-project docs x
user_docs.d
ocx
src
main.rkt

module1.rk
t

module2.rkt

At the end of each work session, you need

module3.rkt

to save your changes on the server. This is

called a “push”.

Now all your data is backed up.

• You can retrieve it, on your machine or
some other machine.
• We can retrieve it (that’s how we collect
homework)
11
 Synchronizing with the server (2)
a server, somewhere on the
your local machine
internet, eg. github.com

.git pull
manual.doc
my-project docs x
user_docs.d
ocx
src
main.rkt
pull
module1.rk
t

module2.rkt

To retrieve your data from the server, you

module3.rkt

do a “pull”. A “pull” takes the data from the

server and puts it both in your local mini-fs
and in your ordinary files.

If your local file has changed, git will merge

the changes if possible. If it can’t figure out
how to the merge, you will get an error
message. We'll learn how to deal with
these in the next lesson. 12
 The whole picture
a server, somewhere on the
your local machine
internet, eg. github.ccs.neu.edu
push
.git
my-project docs
manual.doc
x
pull
user_docs.d
ocx
src
main.rkt
pull
module1.rk
t

module2.rkt

module3.rkt

commit

13
 The whole picture using GHFW
a server, somewhere on the
your local machine
internet, eg. github.ccs.neu.edu

.git sync
manual.doc
my-project docs x
user_docs.d
ocx
src
main.rkt
sync
module1.rk
t

module2.rkt

module3.rkt
In Gihub For Windows or Github For Mac,
“push” and “pull” are combined into a
commit single operation called “sync”. So in these
clients, there are only two steps (“commit”
and “sync”) to worry about, not three.

14
Your workflow (2)
sync

edit Best practice: commit your

work whenever you’ve
commit gotten one part of your
problem working, or before
trying something that might
edit
fail.

commit If your new stuff is screwed

up, you can always “revert”
edit to your last good commit.
(Remember: always
“revert”, never “roll back”)
commit

sync
15
Using Github for Windows/Mac

16
Your workflow with a partner
Your Partner (or
you on another
You computer) You

sync sync sync

edit edit edit

commit commit commit

edit edit edit

server server
commit commit commit

edit edit edit

commit commit commit

sync sync sync

Your partner You get your

gets your work partner’s work
from the server from the server 17
 The new github desktop
• In the next few slides, we’ll give you the
updates for 2015.
• We won’t be using github.com. Instead we will
be using “Github for Enterprise” at
https://github.ccs.neu.edu
• The user interface for GHFW/GHFM has
changed. It’s now called “Github Desktop”.
• In the next few slides, we’ll show you how your
daily workflow looks with new interface.
18
 Starting your work session
• Here’s what your Github Desktop should look like when you
open it up. Observe that your repos will be in the section
labeled “Enterprise”.

19
 Where am I?
• The open blue circle indicates that you are looking at the most
recent local files

20
 Always start by syncing
• This will download any changes that you or your partner have
made on other machines

21
 Click on a dot to see a commit
• Clicking on the last dot will show you what was in your last
commit
• The dot turns blue

22
 This shows your commit SHA
• In this view, you can see the first 6 characters of the unique
identifier (“the SHA”) for this commit
• You’ll need it for your Worksession Report

23
 Now let’s work on our file
• Now the screen shows an uncommitted change.

24
 Next, we commit our work
• We write a commit message. Then we’ll click on “Commit to
Master”

25
 Here’s what you’ll see after a commit
• Now it says “No uncommitted changes” again.
• You can also undo the commit if you want.

26
 Be sure to record the commit SHA
• Click on the open circle to see what was in your commit, and
to record the commit SHA. Here’s that screen again:

27
 Be sure to sync!!!
• Your work is not saved on the server until you sync.

28
 Submit a Work Session Report
• At the end of your work
session, submit a work
session report via the web.
• The URL for the work
session report will appear in
each problem set.
• The report will ask for the
SHA of your last commit.
You can get this from the
Github Desktop, as we’ve
shown you.

29
 Summary
• In this lesson you have learned
– that git creates a mini-filesystem in your directory
– what commit, push, pull, and sync do
– the elements of the basic git workflow
– how git allows you to work across multiple
computers
– how git allows you and a partner to work together

30