GIT - Patrick2

From Training Material
Jump to navigation Jump to search

Git for Users Training Course
Patrick Mazzotta

About Us ⌘

500res-logo.png in conjunction with LearningbrickLogo.jpg

  • Training & Consultancy Provider
  • Founded in 2005
  • Currently offering over 400 courses (remote & on-site)
  • Continuously exapnding through franchishing opportunities

About Me ⌘


  • Consulting in IT & BI for 20 years
  • CEO & Co-Founder of Craedone
    • Analytics
    • Business Intelligence
    • Corporate Strategy/Red Team services
  • Partnered with NobleProg since 2013

Git for Users Training Course ⌘


What is Git?⌘

  • File system
  • Version control
  • Free and Open Source (GPLv2)
  • Designed for Distribution
  • Branching & Merging
  • Staging
  • A really great system

What is a Git?⌘

British slang

  • derived from the word get
  • a foolish or worthless person
  • an unpleasant or contemptible person


Why Git?⌘

  • Linus Torvalds on picking the name "Git":

"I'm an egotistical bastard, and I name all my projects after myself. First Linux, now git.“


  • Git is currently maintained by Junio Hamano


But why Git?⌘

  • Speed
  • Support a distributed architecture
  • Support a non-linear development process
  • Support very large projects

“Take CVS as an example of what not to do; if in doubt, make the exact opposite decision” - annon

“The difference in the improvement of Git over SVN & CVS is as big as the difference between SVN over FTP.” - me

Short History of Git⌘

  • A reaction to licensing changes to BitKeeper, the versioning system [at the time] of Linux
  • 2002 - Linux Kernel develops in BitKeeper
  • 2005 Apr 6 - BitMover drops free license and Linus starts GIT project
  • 2005 Jun 16 - GIT is officially used to track Linux
  • 2007 Feb 14 - GIT 1.5.0 is released (more humane)
  • Those in the Linux community adopted Git quickly (some as early as summer 2005)

Installing Git⌘

  • GUI on Linux, OS X, Windows, Solaris
Just grab the binary and go!
  • Linux
Use your package manager (apt, yum, emerge, etc.) to install “git”
  • OS X
Homebrew - install “git”
MacPorts – install “git-core”
  • Windows
msysGit via
  • Solaris
Use pkg to install “developer/versioning/git”


Terms to know in Git⌘

  • Branching
  • Cherry Picking
  • Cloning
  • Committing
  • Fetch
  • Head
  • Local repository
  • Merging
  • Origin
  • Pushing & Pulling
  • Remote repository
  • Reset [hard]
  • Staging
  • Tagging
  • Working copy


Focus and Design⌘

Others GIT

Others Git
  • Diffs from original file
  • Versioning
  • Server-centric


  • State-based SHA-1 checksumming
  • File system
  • Almost all local (safety first!)


Git Object Types⌘


  • File / inode
  • They’re all hashed


  • Unix-like directory entries Tree.png


  • A collection of SHA-1 hashes related to specific changes (trees) with context!


  • A label
  • Like a commit, but points to commits instead of trees

Branching and Merging ⌘

Bad Branching⌘

The “no branch” branch Nobranch.png

Bad Branching⌘

Useless branches UselessBranch.png

Branching Utilization vs Abuse⌘

  1. Don’t fear branches (not branching is badness)
  2. Don’t merge everything
  3. Keep your own stuff [your own]

The Git Directory⌘

  • .git
  • A hidden directory within working copy
  • Retains Git config data
  • Holds all your datas


The Big Three Trees⌘


  1. Working Directory
  2. Index
  3. Head

Working Directory⌘

  • Any folder you choose
  • Almost like standard work
  • Use Git to move/remove files/folders
  • Don’t nest working folders (use submodules)
  • Allow you to bring in content managed by other repos (DRY!)

The Index⌘

  • The staging tree
  • This is where changes go when they are “added” to Git
  • Can be thought of as “on deck”


The Head⌘


  • A generic term
  • Highly contextual
  • Always refers to your local repository

Non-SCM Uses of Git⌘

  • File sharing (i.e. Dropbox clone, sparkleshare)
  • Distributed database (prophet, gimd)
  • Bug tracking (ditz)
  • Code Deployment (CI & automating sys-ops tasks)
  • Generic backup (Word, Excel, pictures, etc.)
  • More to come!

Roles using Git⌘

  • Git allows for flexibility
  • Developers are responsible
  • A cushy job for SysOps
  • Distributed architecture = distributed knowledge

Git in Practice⌘


Setting Up Your Profile⌘

On the server

  • Keep it accessable
  • LDAP/Exchange friendly
  • SSH is good

On your local machine

  • Commit hooks
  • Viewing Git (console integrations, etc.)
  • IDE integration
  • Recommended for CLI
  • git config color.ui true
  • git config format.pretty oneline
  • git add -i

Getting a Git Repository⌘

  • Github - Probably the most well known Github.png
  • Bitbucket - Free private repos Bitbucket.png
  • GitLab - Targeting enterprise hosts (self managed) with open sourced Community Edition Gitlab.png
  • Your servers - Just install and go (ain’t distributed architecture great?) Yoruservers.png

Normal Workflow Examples⌘

Release-Centric Continuously Integrated
  1. Checkout/update your release branch (RB) from remote
  2. Cut a feature branch (FB) from RB
  3. Push your FB to remote
  4. Commit your work to FB
  5. Frequently update RB & merge down into FB
  6. When FB is finished & tested merge up to RB
  7. Push merged RB back up to remote
  8. Tag RB with release info when signed-off (release candidate)
  1. Checkout/update master branch (M) from remote
  2. Cut an FB from M
  3. Commit work to FB
  4. Push your FB to remote
  5. Frequently update M & merge down into FB
  6. When FB is finished and tested, merge up to M
  7. Push M back up to remote

Log - the Commit History⌘

  • git log
  • Pretty it up with CLI customizations
git log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit
git blame XYZ


  • Woops
git commit –amend
Don’t amend after push


Browsing Git⌘

  • gitk
  • git gui
  • git log
  • git show
  • git show HEAD:afolder
  • git show HEAD:afile
  • git show commit (can be tag or branch)
  • git show HEAD^
  • git show master
  • git show <hash code.


Searching Git⌘

git bisect <subcommand> <options> 
  • Bisecting

A indispensable for larger teams and highly active repos

  1. git bisect help
  2. git bisect start [--no-checkout] [<bad> [<good>...]] [--] [<paths>...]
  3. git bisect bad [<rev>]
  4. git bisect good [<rev>...]
  5. git bisect skip [(<rev>|<range>)...]
  6. git bisect reset [<commit>]
  7. git bisect visualize
  8. git bisect replay <logfile>
  9. git bisect log
  10. git bisect run <cmd>...

Git - Extras ⌘

  • git-bisect
  • git stash
  • Interactive mode
    git add -i
    git rebase -i
  • Porcelain and Plumbing
  • GitHUB

Git Diff⌘

  • git diff
  • git diff HEAD or git diff HEAD^



  • git status



Create a branch (options!)

  • git branch <branch name>
  • && git checkout <branch name>
  • git checkout -b <branch name>

Delete a branch

  • git branch –d <branch name>
  • git branch –D <branch name>
  • forces the delete – be sure!]


Simple Merging⌘

$ git checkout -b iss53
Switched to a new branch "iss53”
$ vim index.html
$ git commit -a -m 'added a new footer [issue 53]‘
$ git checkout master
Switched to branch "master“
$ git checkout -b hotfix
Switched to a new branch "hotfix“
$ vim index.html
$ git commit -a -m 'fixed the broken email address‘
[hotfix]: created 3a0874c: "fixed the broken email address“
1 files changed, 0 insertions(+), 1 deletions(-)
$ git checkout master
$ git merge hotfix
Updating f42c576..3a0874c
Fast forward
README | 1 –
1 files changed, 0 insertions(+), 1 deletions(-)


  • Always rebase!
  • git config --global branch.autosetuprebase always
  • Force all new branches to auto-rebase
  • git config --global branch.*branch-name*.rebase true
  • Force all existing branches to auto-rebase
  • git pull will fetch new commits from remote and merge in
  • Is good right? NO!
  • merge conflicts between your unpushed commits and the pulled commits
  • --rebase will fetch new commits and rebase your commits on top of the newly fetched changes
  • Pro tip: push push push! Rebase.png


  • git stash [stashes current working copy]
  • git stash pop [return latest stash and delete the save]
  • Git stash list [list all stashes available]
  • Git stash [option] -- lots of options
  • Stashing takes all unstaged changes to the working copy and “stashes” them into a temp tree for you. Stash.png
  • Why?
  • You started down a rabbit hole and aren’t sure where it’s leading you
  • You’re in the middle of something that’s unresolved, but a high-priority bug requires immediate attention
  • Caution
  • Expensive
  • Messy


git tag [-a | -s | -u <key-id>] [-f] [-m <msg> | -F <file>]<tagname> [<commit> | <object>] Tag.png


  • A meaningful naming tool
  • A way to track deployments
  • Concise and recognizable

Is not

  • A copy of a commit
  • A backup
  • A way to name branches or commits
  • A cool way to get your name out

Exporting Git⌘

git archive

  • git archive --format=zip HEAD >
  • Creates archive of the specified format containing the tree structure for the named tree and writes it out to the standard output.

git fast-export

  • Dumps the given revisions in a form suitable to be piped into git fast-import. You can use it as a human-readable bundle replacement

Git Aliases⌘

From within the .gitconfig try

   lg = log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit

The Care and Feeding of Git⌘

git gc [--aggressive] [--auto] [--quiet] [--prune=<date> | --no-prune]

Runs a number of housekeeping tasks within the current repository, such as compressing file revisions (to reduce disk space and increase performance) and removing unreachable objects which may have been created from prior invocations of git add.

Users are encouraged to run this task on a regular basis within each repository to maintain good disk space utilization and good operating performance.

Some git commands may automatically run git gc; see the --auto flag below for details. If you know what you’re doing and all you want is to disable this behavior permanently without further considerations, just do:

$ git config --global 0

Distributed Workflow Examples⌘

Centralized Workflow Centralized.png

Distributed Workflow Examples⌘

Integration Manager

  • Can be used with CI workflow


Distributed Workflow Examples⌘

Dictator and Lieutenants Workflow Dictator.png

Setting Up A Central Repo⌘


What does it take to manage your own Git repos?

The Install⌘

Trick question.png

User Management⌘

  • You can run everything through SSH (i.e [[1]])
  • Run a local solution like GitLab ([[2]])
  • Use a private cloud solution (like Github or Bitbucket)

So let's walk through something on our machines.


I've planted a bad seed in, let's see how bisect helps us do this. Let's enter the branch and do a pull to make sure we're up to date. Now let's enter bisect mode:

 git bisect start

mark the current version as bad:

 git bisect bad

and mark the first instance of the file as good:

 git bisect good de73b45

Now let's run the bisect with some magic Magic.png

 git bisect run bash

What just happened?


The Good:

  • Excellent compartmentalization of code from different projects
  • allows for specific state references to your submodule
  • you can have multiple submodules in a single repo

The bad:

  • there's a lot of [justified] resistance from using submodules (you may not get a lot of support from the Git community)
  • use cases are restricted in scope (vs. remotes or subtrees)

The Ugly:

  • the implementation is fragile (it's easily managed with automation tools, but tends to be headaches for teams new to Git)
  • records of the submodule's version in use can get overwritten eaisly since it's not maintained in code (you have to run
 git submodule update

command, and if you don't your commit can revert someone else's submodule changes. this also means when you pull someone's changes, you still have to run that command manually

Submodules (con't)⌘

Are submodules worth the trouble? What other options are there?

  • use remotes with structured build processes

You don't get to manage the remotes as separate projects with independent histories, but it's conceptually a simple thing to understand and run with.

  • use subtrees

A lot of people say subtrees are what submodules should have been, but since they aren't, they don't have the clean and user-friendly commands. For example, to create and later update a subtree:

 git subtree add --prefix .vim/bundle/tpope-vim-surround master --squash
 git subtree pull --prefix .vim/bundle/tpope-vim-surround master --squash

[the squash flags are optional to strip history from the other repo]

Subtrees (con't)⌘

So how do you make subtrees more user friendly?

  • Aliases!!!
  • add your subtree as a remote
 git remote add -f subremote

usually a combination of remote aliases and command aliases can do the trick pretty well

So what's the catch?

  • all the files in the subproject are contained in the parent directory, so the clean "separation of concerns" you get from submodules isn't really present any more
  • developers may forget they are in subtrees and make local changes that then have to get split back out and sent back to the source of the subproject as a separate thing (again, failure to separate concerns)

Git Hooks⌘


Git Hooks - Good for what?⌘

  • triggered through Git events/actions
  • can be client-side (commits, merges, etc.) or server-side (i.e receiving pushes)
  • awesome power for workflow and CI automation!

What can you do with Git hooks?

Installing Git Hooks⌘

  • placed in .git/hooks
  • use different languages
    • bash/shell scripting
    • Ruby
      #!/usr/bin/env /path/to/rails runner
    • Python
      #!/usr/bin/env python3
    • Node.JS
      #!/usr/bin/env node
    • etc etc!
  • watch out for cross-platform environments & teams!