Version Control System.
DVCS, Git, tips and tricks.

@itspoma / CURSOR Education

v1.91

Agenda

  • Generations of Version Control Systems
  • DAG & VCS
  • Basic operations & terms
  • SVN overview
  • Git \w commands
  • Branches, Merging and Conflicts
  • Github.com
  • GitHub Pages and Forks
  • Best Practices

Generatios

  • 0gen - No VC
  • 1gen - File locks
  • 2gen - CVCS (Centralized)
  • 3gen - DVCS (Distributed)


RCS - pessimistic approach, "ci" and "co" actions
CVS - multiple users, concurrent
SVN - as tree
Git - distributed, branching model, git-flow, rev checksums

Purposes?

Version/Revision Control System

  • allows multiple people to work on a single project in the same time
  • integrates work done simultaneously by different team members
  • gives access to historical versions of your project

example: Wikipedia history of changes

example: history panel in Photoshop

example: Wordpress rollback post

example: Wordpress previous post diff

Generation 0

Without version control - backup.zip

One developer - ok.
Two developers - danger!
Five developers - madness!

No VC

Local version control

copy to separate directory
(project-25-12-2015, backup-qweqwe15, New Folder 283, ...)

problems? weaknesses? milestones?

Local version control weaknesses?

Generation 1 - File Locks

Generation 2 - Central VCS

Centralized version control diagram


problems? weaknesses? milestones?

Generation 3 - DVCS

Distributed version control diagram

DAG

Directed acyclic graph

Graph

Nodes & lines (edges)

Directed Graph

Lines have arrows (directed edges)

Directed Acyclic Graph

example of Directed Acyclic Graph

DAG in VCS

Basic operations

  • Clone
  • Commit
  • Push
  • Pull
  • Merge

Clone

Local Commits

Push to Server

Branches

  • Clones
  • Labels

Branches

Labels as Branches

Essentials terms

Repository

is a database of all the edits to,
and/or historical versions (snapshots) of your project.


local repository and the central (remote) repository

Working copy (checkout)

your personal (local) copy of repository

Checkout / Clone

action to copy a remote repository to your local

Commit

action, that you made to share your changes with other teammates.
uploading your local changes to repository

Revision

a version of document

Update (git pull)

action, that you made to make your working copy up-to-date with remote repository

Changeset / Changelist

a named set of changes

Branching

Branch

a copy of repository

Trunk / Master

a main branch for work

Conflict

a case, when few users made not-similar changes in one file

Head

a latest version for branch

Merge

an action to combine independent changes to one version

Tag

a label for specific version of document

Distributed vs Centralized

Distributed and centralized version control

  • centralized
    example: Subversion
  • distributed (DVSC)
    more modern, runs faster, is less prone to errors, has more features, more complex to understand
    example: Mercurial, Git



there is just one repository.

  • You commit
  • They update


there are multiple repositories

  • You commit (to your local)
  • You push (to remote)
  • They pull (from remote)
  • They update (to their local)

Merge: a diff

Merge

Conflicts

the final version is a merge of original version and edit.

occurs when two different users make simultaneous, different changes to the same line of a file

General Workflow

Initial initialization

clone the project (tree of files/directories)
from remote to local (filesystem)
with specific version

The Daily Cycle

  • update the local copy to latest
  • make changes on local
  • sharing (saving) local changes with others

Git

is a:

  • essential professional tool
  • directory content management system
  • tree history storage system
  • content tracker

Why Git?

because:

  • simple
  • fast (save time)
  • no central repo (work offline, no network needed)
  • easy reverts
  • branching make life easier
  • ideal for development in team

Git: Evolution

  • 1991-2002 - Linux root, archives & patches (BitKeeper)
  • 2005 - Linux developers implemented own VCS (Git, Subversion)
  • 2007 - SVK
  • 2008 - Git (push/pull)
  • 2009 - Git (master, feature branches)
  • 2011 - Git (git flow, topic branch, rebase)

Git

Git: Directory structure

.git/

  • config files
  • hooks
  • index
  • object database
  • references

Hash functions

Any sequence of bytes -> (hash function) -> hash

SHA1

Git & SHA1

Every object (commit, state, action) has own SHA1.

SHA1 Collisions

1 chanse in 175.000.000

Git flow

Git flow (simple)

  • branches: master & dev
  • master - stable, dev - working
  • detailed commit message (with issue ticket)
  • pull requests (for code review)
  • dev automatically to testing server
  • master release

Git flow (simple)

  • feature branches
  • release branches
  • hotfix branches


from where? to where?

Git: install

Git: configuring


$ git config

$ git config --global user.name "John Doe"
$ git config --global user.email johndoe@example.com

$ git config --list
$ git config user.name
              

Git: help


$ git help command
$ git command --help
$ man git-command
              

Git commands

Git: Creating an Empty Project


# initializes a directory as a Git repository
$ git init
              

Git: Getting a Project


# copy a git repository so you can add to it
$ git clone git://github.com/schacon/simplegit.git
              

The Four Areas

The Working Area

...

The Repository

...

The Index

Moving data to Right

Moving from Working Area to Index (add) and to Repository (commit)).

Moving data to Left

checkout

Removing files

...

Renaming files

...

Git: Basic Snapshotting

git add

adds file contents to the staging area


$ git status -s
?? README
?? hello.rb

$ git add README hello.rb
$ git add *.rb

$ git status -s
A  README
A  hello.rb

# edit & save the "README" file

$ git status -s
AM README
A  hello.rb
              

git status

adds file contents to the staging area


$ git status -s
AM README
A  hello.rb

$ git status -s
M  README
 D hello.rb
              

git diff

shows diff of what is staged and what is modified but unstaged


$ vim hello.rb
$ git status -s
 M hello.rb

$ git diff
diff --git a/hello.rb b/hello.rb
index d62ac43..8d15d50 100644
--- a/hello.rb
+++ b/hello.rb
@@ -1,7 +1,7 @@
 class HelloWorld
   def self.hello
-    puts "hello world"
+    puts "hola mundo"
   end
 end
              

git commit

records a snapshot of the staging area


$ git config --global user.name 'Your Name'
$ git config --global user.email you@somedomain.com

$ git add hello.rb 
$ git status -s
M  hello.rb

$ git commit -m 'my hola mundo changes'
[master 68aa034] my hola mundo changes
 1 files changed, 2 insertions(+), 1 deletions(-)

$ git status
# On branch master
nothing to commit (working directory clean)
              

git reset

undo changes and commits


$ git status -s
 M README
 M hello.rb

$ git add .
$ git status -s
M  README
M  hello.rb

$ git reset HEAD -- hello.rb 
Unstaged changes after reset:
M hello.rb

$ git status -s
M  README
 M hello.rb
              

git rm

remove files from the staging area


$ git rm hello.rb
              

Git: Branching and Merging

  • branch
  • checkout
  • merge
  • log
  • tag

Three types of Merging

  • Regular Merge
  • Fast-forward Merge
  • Rebase

Regular Merge (before)

Regular Merge (after)

Regular Merge (cleanup, delete branch after)

Fast-forward Merge (sample case)

Fast-forward Merge (we can create a merge commit)

Fast-forward Merge (just move a label)

Fast-forward Merge (cleanup)

Rebase (sample case)

Rebase (sample case)

Rebase (move label)

Rebase (squash commits)

Git: Sharing and Updating Projects

  • fetch, pull
  • push
  • remote

git remote

list, add and delete remote repository aliases


$ git remote
origin

$ git remote -v
origin  git@github.com:github/git-reference.git (fetch)
origin  git@github.com:github/git-reference.git (push)
              

git fetch

download new branches and data from a remote repository


              

git pull

fetch from a remote repo and try to merge into the current branch


$ git fetch github
remote: Counting objects: 4006, done.
remote: Compressing objects: 100% (1322/1322), done.
remote: Total 2783 (delta 1526), reused 2587 (delta 1387)
Receiving objects: 100% (2783/2783), 1.23 MiB | 10 KiB/s, done.
Resolving deltas: 100% (1526/1526), completed with 387 local objects.
From github.com:schacon/hw
   8e29b09..c7c5a10  master     -> github/master
   0709fdc..d4ccf73  c-langs    -> github/c-langs
   6684f82..ae06d2b  java       -> github/java
 * [new branch]      ada        -> github/ada
 * [new branch]      lisp       -> github/lisp
              

git push

push your new branches and data to a remote repository


$ git push github master
Counting objects: 25, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (25/25), done.
Writing objects: 100% (25/25), 2.43 KiB, done.
Total 25 (delta 4), reused 0 (delta 0)
To git@github.com:schacon/hw.git
 * [new branch]      master -> master
              

Git: Inspection and Comparison

  • log
  • diff

git log

filter your commit history


$ git log --author=Linus --oneline -5
81b50f3 Move 'builtin-*' into a 'builtin/' subdirectory
3bb7256 make "index-pack" a built-in
377d027 make "git pack-redundant" a built-in
b532581 make "git unpack-file" a built-in
112dd51 make "mktag" a built-iner
              

git diff


$ git diff v0.9 --stat
 README  |    2 +-
 ruby.rb |    4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)
              

Working from

  • Command Line
  • Graphical Client APps
  • IDE Integration

  • twitter
  • facebook
  • Yahoo!
  • jQuery
  • Ruby on Rails
  • node.js
  • symfony
  • mongodb
  • ...

GitHub Pages

http://pages.github.com/
http://your-name.github.io/your-repo/

TortoiseGit: right click

TortoiseGit: commit

GitHub: Forks

is a publicy visible clone.
contributor owns fork.

Fork flow

Fork flow

Fork flow

Fork flow

GitHub: Branching

TBD

GitHub alternatives

  • bitbucket
  • gitlab
  • ...

Version Control best practices

Use a descriptive commit message

write a good commit message
to indicate the purpose of the changes

Make each commit a logical unit

each commit should have a single purpose
and should completely implement that purpose

Little and often commits!

Avoid indiscriminate commits

make a commit with specific files

Little and often commits

CVCS: commit when you're ready.
DVCS: commit when you want. push when you're ready!

Save-points!

Advice: Incorporate others' changes frequently

work with the most up-to-date version of the files as possible

Advice: Share your changes frequently

share a logical unit of work with your colleagues as soon as possible

Advice: Coordinate with your co-workers

strive to avoid conflicts.
to talk with teammates is the best way to avoid conflicts

Advice: Don't commit generated files

they aren't necessary in version control

Additional materials