Getting git




VERSION CONTROL SYSTEM (vcs)

Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later.

Useful for:
  • revert files back to a previous state
  • revert the entire project back to a previous state
  • review changes made over time
  • see who last modified something that might be causing a problem

Directory based VCS


Local VCS


(rcs)

Centralized VCS


(cvs, svn)

Yay

• Access control
• Central Backup

Nay

• Single point of failure
• Painful merges

Decentralized VCS


(git, mercurial, bazaar, bitkeeper, darcs)

Yay

• Every clone is a fork
•  Every clone is a backup
• No connectivity issues
• Fast. Really!


Nay

• Not good for large binary files

git


Git is an open source, distributed version control system designed for speed and efficency




Git design goals

  • Speed
  • Simple design
  • Strong support for thousands of parallel branches
  • Fully distributed
  • Able to handle larges projects like Linux kernel effectively
  • Ensure integrity

Tracking Changes

(most VCS)

Tracking Snapshots

(git)

Git is a file system


Git thinks of its data more like a set of snapshots of a mini filesystem.

Nearly every operation is local

  • Operations are very fast
  • Every local repository is a backup
  • No need of internet connection to work
    (only needed to synchronize occasionally)

Git has integrity

  • Everything is checksummed
  • References are SHA-1



24b9da6552252987aa493b52f8696cd6d3b00373

Git doesn't delete

  • Git generally only adds data
  • If you mess up, you can usually recover your stuff
  • Recovery can be tricky though

The three states

  1. Modified
  2. Staged
  3. Committed

Workflow


The git directory

  • Located at .git/
  • Contains entire history

The working directory

  • A single checkout from a Git repository

The Staging Area

  • Contained in a file
  • Tracks what will go into the next commit 
    AKA "the index"

File Status Lifecycle


GIT internals

commit structure

Git Internals

Chain of commits

Branches


Branches are "Pointers" to commits.


Diverging Branches


Branches can diverge.


Merging Branches


Branches can be merged.


Usually painless


Merge conflicts


• Different auto-merge strategies
(fast-forward, 3 way, etc...)
• If it fails, fix by hand
$ git merge iss53
Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Automatic merge failed; fix conflicts and then commit the result.

•  Then mark as resolved and trigger merge commit

$ git add index.html
$ git commit

Rebasing

  • Linear alternative to merging
  • Rewrites tree! Never rebase published code!

Common Workflow



Workflow 1


  • Only commit stable code to master
  • Commit unstable to develop
  • Deploy hotfixes to master

Workflow 2


  • Commit development code to master
  • Create tags for stable releases
  • Branch from stable tag for hotfixes

Topic Branches


  • AKA feature branches
  • For each feature, create a topic branch
  • Merge early, merge often
  • If desired, squash commits

git flow


Main branches

  • Two main branches with an infinite lifetime
    • (master) Production-ready state
    • (develop) Development changes for the next release

Feature branches

  • Used to develop new features for the upcoming or a distant future release

Feature branches

  • Merging without fast-forward avoids losing information about the historical existence of a feature branch

release branches

  • Support preparation of a new production release
  • Allow for minor bug fixes and preparing meta-data for a release (version number, build dates, etc.)
  • All features that are targeted for the release-to-be-built must be merged in to develop at this point in time

Hotfix branches

  • Meant to prepare for a new production release, albeit unplanned
  • Arise from the necessity to act immediately upon an undesired state of a live production version (critical bugs)

Installing Git


Installing Git


Windows
http://git-scm.com/downloads

Linux
Debian/Ubuntu: sudo apt-get install git

OS X

http://code.google.com/p/git-osx-installer
...or via MacPorts

INSTALLing git gui

Windows

http://www.syntevo.com/smartgit/
http://www.sourcetreeapp.com/

Linux

http://www.syntevo.com/smartgit/

Configuration


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


Editor

$ git config --global core.editor nano


Colors

$ git config --global color.ui true

configuration


ConfiGURATION

ALIAS

Add your favorite aliases to the .gitconfig file located in your home folder

[alias]
  co = checkout
  ci = commit
  st = status
  br = branch
  hist = log --pretty=format:'%h %ad | %s%d [%an]' --graph --date=short
  type = cat-file -t
  dump = cat-file -p

AUTO-Completion

To enable git commands auto-completion in the bash shell download git-completion.bash to

/opt/local/etc/bash_completion.d (MAC)

/etc/bash_completion.d/ (LINUX)

Creating a Repository


$ git init

CREATING A REPOSITORY


Cloning a Repository


$ git clone https://github.com/dbrgn/fahrplan

CLONING A REPOSITORY


Tracking files


SPECIFIC Files:
git add README.rst

GROUP OF FILES:
$ git add *.py

tracking files

TRACKING FILES


TRACKING FILES



staging files


git add *.py
git add README.rst

STAGING FILES


SPECIFIC FILES:
git add README.rst

GROUP OF FILES:
$ git add *.py

It's the same procedure used to add new files!

STAGING FILES


STAGING FILES


Creating a Commit


Specific changes:
$ git add *.py
$ git add README.rst
$ git commit -m 'First commit'

All changes:
$ git commit -am 'First commit'

creating a commit

creating a commit

CREATING A COMMIT

After the commit (if all the modification has been commmitted) the repository is again in a clean state

commit manual of style

  • Each commit should contain small atomic changes
    (A commit can consist of a single modified line)
    • Examples
      • Add a method
      • Fix a bug
      • Add the initial version of a new file
  • You should commit very often
  • The commit message should be very explanatory, so that the other users can understand why that modification have been made and how it has been implemented
    • The messages can be used later to understand the code with git blame!

commit manual of style

BAD PRACTISES
  • Avoid situation where thousand of modified lines on tons of different files are committed together
  • Avoid commit messages like
    • "Update bunch of files"
    • "I am adding this..", "I am doing this.." (use imperative form)

Removing files


From staging area

$ git rm --cached file.py


From index and file system
$ git rm file.py

REMOVING FILES


REMOVING FILES


REMOVING FILES


REMOVING FILES

Create a commit to remove the file from the git repository

Moving files


Git tracks content, not files. Although there is a move command...

$ git mv file1 file2

...this is the same as...

$ mv file1 file2

$ git rm file1

$ git add file2

Show Status


$ git status

SHOW STATUS


Show log


Entire (paged)
$ git log

Date filtering
$ git log --since=2.weeks
$ git log --since="2 years 1 day 3 minutes ago"

SHOW LOG


SHOW LOG


SHOW LOG


SHOW LOG


SHOW Diffs


Unstaged changes
$ git diff

Staged changes
$ git diff --cached

Relative to specific revision
$ git diff 1776f5
git diff HEAD^

SHOW DIFFS


SHOW DIFFS

SHOW DIFFS

SHOW DIFFS

Show Commits


Last commit
$ git show

Specific commit
$ git show 1776f5
$ git show HEAD^

Undoing Things


Change last commit
$ git commit --amend

Unstage staged file
$ git reset HEAD file.py

Unmodify modified file
$ git checkout -- file.py

UNDOING THINGS

CHANGE LAST COMMIT

UNDOING THINGS

Git doesn't delete commits

UNDOING THINGS

UNSTAGE STAGED FILE

UNDOING THINGS

UNMODIFY MODIFIED FILE

UNDOING THINGS

Reset the whole repository to a previous state

UNDOING THINGS

RESET THE WHOLE REPOSITORY TO A PREVIOUS STATE

UNDOING THINGS

RESET THE WHOLE REPOSITORY TO A PREVIOUS STATE
  • Choosing Hard Reset the whole repository will look like the selected commit
  • Careful!! Any uncommitted changes will be lost!
  • Use Soft or Mixed reset

.gitignore

  • Blank lines or lines starting with # are ignored
  • Standard glob patterns work
  • End pattern with slash (/) to specify a directory
  • Negate pattern with exclamation point (!)


$ cat .gitignore
*.pyc
*.swp
/build/ /doc/[abc]*.txt
.pypirc
*.egg-info

Remotes

  • Other clones of the same repository
  • Can be local (another checkout) or remote (coworker, central server)
  • There are default remotes for push and pull

$ git remote -v
origin git://github.com/schacon/ticgit.git (fetch)
origin git://github.com/schacon/ticgit.git (push)

Branch Management


Show All Branches
$ git branch
iss53
* master
testing

Show last Branch commits
$ git branch -v
  iss53 93b412c fix javascript issue
* master 7a98805 Merge branch 'iss53'
  testing 782fd34 add scott to the author list in the readmes

Branch Management


Merged branches
$ git branch --merged
  iss53
* master

Unmerged branches
$ git branch --no-merged
  testing


Branch Management


Create new branch
$ git branch iss53
$ git checkout -b iss53 master

Switch Branch
$ git checkout iss53

Delete Branch
$ git branch -d iss53

BRANCH MANAGEMENT

The file we see in the working directory are different depending on the current branch

Push to remote


Without default
$ git push <remote> <rbranch>

Setting A default
$ git push -u <remote> <rbranch>

Then...
$ git push

Pull from Remote


Fetch & Merge

$ git pull [<remote> <rbranch>]


Fetch & Rebase

$ git pull --rebase [<remote> <rbranch>]

-> Rebasing can be dangerous!

Create Tags


Lightweight tags
$ git tag v0.1.0

Annotated tags
$ git tag -a v0.1.0 -m 'Version 0.1.0'

GPG-Signed tags
$ git tag -s v0.1.0 -m 'Signed version 0.1.0'
$ git tag -v v0.1.0

Stashing


Move changes to a separate "stash".

$ git stash
$ git stash pop
$ git stash list
$ git stash apply
$ git stash drop
$ git stash clear

Advanced Git


Partial add
$ git add -p file.py

Bisecting
$ git bisect start
$ git bisect bad
$ git bisect good v1.0

Advanced Git


Rewrite commits

$ git filter-branch --env-filter
'if [ $GIT_AUTHOR_EMAIL = gezuru@gmail.com ]; then GIT_AUTHOR_EMAIL=danilo.bargen@webrepublic.ch; fi; export GIT_AUTHOR_EMAIL'

Resources


Now Git to work!


CreditS

This presentation was originally made by
Danilo Bargen

Revised by
Simone Gaiarin

The 3 slides on the Git definition are taken from the presentation "Introduction to Git" by Matthew McCullough



Getting git

By Simone Gaiarin

Getting git

A simple introduction to git

  • 1,342
Loading comments...

More from Simone Gaiarin