1. Git
From basics to workflows

2. What is Version Control?
Version Control (or Revision Control) allows
tracking of changes throughout a collection of
files.
These files can be anything, but they are
typically used to track changes of files
containing code.

3. How does it work?
Most people know
version control in a
centralized model
(CVS, SVN), in that a
single repository
contains and controls
all change records,
logs, and other data
associated with the
project.
Master
John
Jane
Josh

4. What's wrong with this model?
If the master server is
down or network
connectivity is limited
to nonexistent, the
client cannot commit
new changes nor
typically access past
revisions, remote
branches, or other
information not stored
or cached locally.
Master
John
Jane
Josh
I'm helpless

5. Git is different
Distribution solves the
problem by making
the client and the
server the same,
ensuring everyone
has a full copy of the
Repository and any
changes made go to
the local one first
before being "pushed"
to others.
Master
John
Jane
Josh

6. Git is different (cont.)
This allows full, bi-
directional
communication
between any two
repos. In addition,
work is committed
locally prior to sending
off the changes to
anyone else.
Master
John
Jane
Josh

7. Git is different (cont.)
However, most
implementations of git
infrastructure call for a
master repository to
which contributors will
work on, similar to the
centralized model, but
ensuring each client
has exactly the same
data as the server.
Master
John
Jane
Josh

8. Using Git
git init
git add <file1> [...]
git commit -m "msg"
git push <remote> <branch>
git pull <remote> <branch>
git branch <branch>
git checkout <branch>
git merge <branch>
git log
git tag <tagname>
Initialize a Repository
Add File to stage area
Commit staged files
Push updates to remote
Pull remote updates
Create a new branch
Change current branch
Merge branch into current
View commit activity
Tag current state

9. Branches
● Are cheap
● Are local unless
pushed
● Can be merged into
each other

10. Branch Workflows
One common
workflow is to have a
master and develop
branch. master has
stable code, develop
is code that might not
be stable.
Programmers will
commit and push to
the develop branch
and some sort of
project leadership will
merge the develop
branch into the
master when the
time comes for a
release.

11. Branch Workflows (cont.)
This red line represents the master branch's
history.
master

12. Branch Workflows (cont.)
The blue line is the develop branch.
master
develop

13. Branch Workflows (cont.)
Each dot is a commit
master
develop
John:
Fixed bug
#223
Jane:
Added
Widget
Josh:
Cleaned up
doc/
directory

14. Branch Workflows (cont.)
Each arrow is a merge into master
master
develop
John:
Merged
develop
into master
John:
Merged
develop
into master
John:
Merged
develop
into master

15. Branch Workflows (cont.)
And each square is a tag
master
develop
John
Tagged:
v1.0
John
Tagged:
v1.1
John
Tagged:
v1.2

16. Branch Workflows (cont.)
This is the most common workflow for working
in teams. The master server will see this the
most.
master
develop

17. Branch Workflows (cont.)
As presented, this model is kind of limited, as
it forces everyone to put code in development
on the develop branch.
master
develop

18. mail-unstable
Branch Workflows (cont.)
Members of projects can create unstable
branches, branched off the develop branch, to
work on features that will make the develop
codebase unstable.
master
develop
(Delete branch)

19. mail-unstable
Branch Workflows (cont.)
Sometimes, however, you might need to do a
hotfix, which bypasses the typical
development cycle. This is used sparingly,
and is typically reserved for security issues.
master
develop
(Delete branch)
(Delete branch)