1

Version Control Systems

Created by <Academia de Código_>
 2.1

Version Control Systems (VCS)

management of changes in documents/code/information
 2.2

No Version Control
 2.3

File Locks
File locks allow a developer to lock a file while working on it.
e.g. SCCS and RCS
 2.4

Centralized Version Control Systems (CVCS)

client client client

e.g. CVS, SourceSafe, Perforce, SubVersion

 2.5

Distributed Version Control Systems (DVCS)

e.g. Git, Mercurial, Bazaar, Bitkeeper

 3.1

The stupid content tracker

 3.2

{ Hands On }
First-Time Git Setup
# check if git is installed
$ git version

# set user info and default editor

$ git config --global user.name "John Doe"
$ git config --global user.email [email protected]
$ git config --global core.editor vim

# dump the git configuration and repo configuration if executed inside repo
$ git config --list

# getting help
$ git help config
 3.3

Fake it 'til you make it

We'll learn what git is and how it works by using it.
Let's start off creating a fictitious project.
# create a new directory for your fake project, and move inside
$ mkdir my-vegan-restaurant
$ cd my-vegan-restaurant
 3.4

Greetings, my name is git

It's time for git to know about your project.
Programmers would say we're initializing a local git repository inside
your project root directory.
All your local repository data is stored inside a directory called .git.
It is created as soon as you initialize the repository.
# initialize a local git repository
# (make sure your current directory is your project root directory!)
$ git init

# list all files (including hidden ones)

$ ls -a

Don't mess with the .git directory!

 3.5

What are we doing here?

By now, you have successfully created a directory for your project
and initialized a local git repository to manage its versions.
Git has nothing to keep track of, because there are no files inside
your project directory.
Let's create your first file and check what that means to git.
# create your restaurant description
$ echo "We've got the best fresh vegetables all day, every day." > description.txt
# check your current repository status
$ git status
 3.6

I might want to remember this

You are happy with the description you've come up with. You'd like
to be able to come back to this one in case it changes for the worse.
This is where you make a new "version". Git calls it a commit.
A commit stores the state of your project (the content of your files)
with an associated date and description.
Your commits are kept in a chronologically ordered list, and you are
able to navigate between them (changing files' content on the fly).
 3.7

It's okay to be picky

In most VCS, you would create a commit of your files content now.
In git, you must add it to the staging area first. This area is where you
place all the files you want to be stored in your next commit.
# add the file to the staging area
$ git add description.txt
# check your current repository status again
$ git status

You may use unix metacharacters for pattern matching.

e.g: ., *, *.txt, etc..

 3.8

File Status Lifecycle

 3.9

File Lifecycle - Tracked/Untracked

A file is said to be tracked if there is evidence of it in the last

snapshot in the Local Repository.
If no story of it is available (files not yet committed for the first time),
we say the file is untracked.
 3 . 10

File Lifecycle - Add a file

When you add an untracked file, it goes directly to the staging area.
It will be added to the repository during the next commit
 3 . 11

File Lifecycle - Commit a file

When you make a commit, staging area will flush and your files in
the working directory will be in unmodified state.
This means the files in the working directory are the same as the snapshot in the local repository
 3 . 12

File Lifecycle - Modify a file

When you change a file in the working directory,

it changes to the modified state
A modified file won't be automatically staged. You must manually do it (with the add command) if you want it to.
 3 . 13

File Lifecycle - Stage a modified file

All the files in modified state can be added to the staging area
and will be ready to be part of the local repository during the next commit
 3 . 14

File Lifecycle - Remove a file

A file can be removed from the unmodified state.

This action will force the file to be untracked again
It won't be deleted from the working directory. You can always add it again, if needed
 3 . 15

Ignoring files

We don't want git to track every file in our working directory

Do we always remember not to stage those files?
Does everyone in the team know what files not to stage?
No! So there must be a better way to do this!
 3 . 16

.gitignore
.gitignore is a file that tells git
which files in the repository should be ignored
# create file .gitignore
$ vim .gitignore
 3 . 17

{ Hands On }
Ignore the rat problem in your restaurant
 3 . 18

This is where it all started

After adding the file to the staging area,
you are ready to make your first commit.
The commit needs to be accompanied with a brief description
of what has changed.
It will be useful when navigating through hundreds of commits,
or when you want to have an overview of what has been done in a
series of commits.
# commit your staging area
$ git commit -m "Initial commit. Add restaurant description."
# I think you know what this means
$ git status

Remember this core concept: commit often, perfect later!

 3 . 19

I'm getting the hang of this

Now that you've made your first commit, you are able to safely
keep working on your project.
Let's add some menus to our restaurant!
# create a menus directory
$ mkdir menus
# create the fried cuttlefish menu
$ echo "Bean Burrito | Sweet Potato Fries | Beer -> \$5" > menus/bean-burrito.txt
# create a new menu you're still not sure about it's price
$ echo -n "Vegetable Curry | White Rice | Wine -> \$7" > menus/vegetable-curry.txt

$ git status
 3 . 20

{ Exercise }
Make a new commit
It's time for you to create a new commit
with both files and a nice description.
 3 . 21

A piece of history
The two commits you've made are stored in your local repository
and it's possible to see them in a chronologically ordered list.
A unique key is assigned to each commit that is used as an identifier.
You'll use it whenever you want to reference a particular commit
# check your commit list
$ git log
 3 . 22

{ Exercise }
Raise your prices, and commit those changes
 3 . 23

Change is inevitable
Just like you have changed your prices,
a software project keeps evolving over time.
As commits store the files content at a point in time, git also
provides a tool to compare file differences across versions.
# see the differences between two commits on a particular file
$ git diff COMMIT_ID menus/bean-burrito.txt
# see the differences between two commits (every file that has changed)
$ git diff COMMIT_ID
# see the differences between the last commit and the current project state (excluding
$ git diff
# see the differences between the last commit and the current staging area
$ git diff --staged
 3 . 24

Get into the time machine!

Why would we store multiple versions of our files if we didn't want
to check them in the future?
The clients didn't like the changes you've made to your prices, and
you want to revert them as soon as possible.
Of course you could remember what the prices were in this
situation, but imagine a restaurant with hundreds of menus that
keep changing their price.
# revert a file to it's state in a particular commit
$ git checkout COMMIT_ID menus/bean-burrito.txt
# the file is automatically added to the staging area, you may commit the price reversi
$ git commit -m "revert burrito menu price"
# check your log for an overview
$ git log
 4.1

Working with Remotes

Remote repositories are versions of your project that are hosted on
the Internet or in a network somewhere.
 4.2

{ Hands On }
Setup a Remote Repository
# Connect to the bootcamp server
ssh [email protected]

# create a new git shared repository

git init --bare myrepo.git

# logout from the bootcamp server

exit

# Connect the local and remote repositories

git remote add origin [email protected]:myrepo.git
 4.3

{ Hands On }
Adding Remotes
# cloning a remote
$ git clone [url]

# adding a new remote repository, origin is a common shortname

$ git remote add [shortname] [url]

# listing all remotes with urls

$ git remote -v
 4.4

{ Hands On }
Pulling and Pushing
# pull a copy of the master branch from the remote repository named origin,
# and merges it with the current checked out local branch
$ git pull origin master

# merges current checked out local branch

# with the remote branch the local branch was created from
$ git pull

# push data from local checked out branch

# to master branch in the remote named origin
$ git push origin master

# push data from local checked out branch

# to the remote branch the local branch was created from
$ git push

Remember that you won't be able to push

if any changes are waiting for being pulled.
 5.1

Branches

In a collaborative environment, it is common for several developers

to share and work on the same source code
Branches allow each developer to branch out from the original code
base and isolate their work from others.
 5.2

Branch Master
Let's start simple

Let's assume this is our repository history. There's a pointer called master pointing at commit a5c3eb
That's all branches are: movable pointers.
 5.3

Add a new feature

$ git branch feature

We just created another pointer called feature pointing at the exact same commit.
 5.4

Head
Now that we have two different branches pointing to the same
commit, how does Git know in which branch are we working on?

The HEAD is a special pointer that simply points to the currently checked out branch or commit.
 5.5

Switch to the new branch

$ git checkout feature

All that happens is that HEAD is now pointing to feature instead of master
 5.6

Do some work
$ touch anotherFile.txt
$ git add anotherFile.txt
$ git commit -m "working hard"

We created a new commit c57e22 and the feature pointer moved on to it.
 5.7

What about the master branch?

$ git checkout master

the HEAD pointer changed to master and the state of the entire working directory
changed to what it was at a5c3eb.
 5.8

Another commit from master

$ touch yetAnotherFile.txt
$ git add yetAnotherFile.txt
$ git commit -m "minor changes on master"

A new commit 3aa2ff appeared and master moved on to it. At this point our history has diverged.
This is the whole point of branches. They enable parallel evolution of a code base.
 5.9

{ Hands On }
Working with branches
# list of branches with the last commit
$ git branch -v

# create a new branch

$ git branch feature

# change to the new branch

$ git checkout feature

# shortcut: create and change to the new branch

$ git checkout -b feature

# delete a branch
$ git branch -d feature
 5 . 10

Merging Branches
The git merge command lets you take independent branches and
integrate them into a single commit.
 5 . 11

git merge
Git can merge other branches into the current branch.
The current branch will be updated to reflect the merge, but the
target branch will be completely unaffected.
This means that git merge is often used in conjunction with git
checkout for selecting the current branch and git branch -d for
deleting the obsolete target branch.
# create a branch to develop a new feature, and automatically checkout to it
$ git checkout -b new-feature
# develop a new feature..
$ git add .
$ git commit
# merge the new branch into master
$ git checkout master
$ git merge new-feature
# delete the newly merged branch
$ git branch -d new-feature
 5 . 12

Conflict resolution
If two developers are working on the same file in parallel,
conflicts may arise.
When merging both commits, git is often able to automatically
resolve these conflicts based on a number of factors (e.g: date),
but sometimes the process may require human interaction.
 5 . 13

Manual conflict resolution

Git will modify the file to combine the content of both commits, with
separators indicating where the conflicts are.
Conflicts may be resolved manually by editing the conflicted files
or using third party software for creating the merge commit.
 5 . 14

{ Hands On }
Generate and solve a merge conflict