View source for GIT - Patrick2

[[Category:Git]]

<slideshow style="nobleprog" headingmark="⌘" incmark="…" scaled="true" font="Trebuchet MS" >
;title: Git for Users Training Course
;author: Patrick Mazzotta
</slideshow>

==About Us ⌘==
[[File:500res-logo.png|300px]] in conjunction with [[File:LearningbrickLogo.jpg |150px]]
* Training & Consultancy Provider
* Founded in 2005
* Currently offering over 400 courses (remote & on-site)
* Continuously exapnding through franchishing opportunities
** http://training-franchise.com

==About Me ⌘==
[[File:Craedone.png|300px]]
* 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 ⌘==
[[File:GIT.png|250px]]

==What is Git?⌘==
* File system
* Version control
* Free and Open Source (GPLv2)
* Designed for Distribution
* Branching & Merging
* Staging
* A ''really'' great system

http://wheningit.tumblr.com/

==What is a Git?⌘==
British slang
* derived from the word ''get''
* a foolish or worthless person
* an unpleasant or contemptible person
[[File:Git-fool.png|300px]]

==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.“'' 

[[File:Git-why1.png|200px]]
|| 
* Git is currently maintained by Junio Hamano
[[File:Hamano.png|200px]]
|-
|}

==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⌘==
{| class="wikitable"
|
* '''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 http://msysgit.github.com
* '''Solaris'''
 Use pkg to install “developer/versioning/git”
|
[[File:Install.png]]
|}

==Terms to know in Git⌘==
{| class="wikitable"
|
* Branching
* Cherry Picking
* Cloning
* Committing
* Fetch
* Head
* Local repository
* Merging
* Origin
* Pushing & Pulling
* Remote repository
* Reset [hard]
* Staging
* Tagging
* Working copy
|
[[File:Terms.png]]
|}

==Focus and Design⌘==
Others   GIT
{| class="wikitable"
|-
! Others !! Git
|-
| 
* Diffs from original file
* Versioning
* Server-centric
[[File:Others.png|125px]]
| 
* State-based SHA-1 checksumming
* File system
* Almost all local (safety first!)
[[File:Git1.png|125px]]
|}

==Git Object Types⌘==
Blob 
* File / inode
* They’re all hashed
Tree
* Unix-like directory entries [[File:Tree.png]]
Commit
* A collection of SHA-1 hashes related to specific changes (trees) with context!
Tag
* A label
* Like a commit, but points to commits instead of trees

==Branching and Merging ⌘==

* It’s important 
* It’s easy 
* It’s personal! 
* Super easy: http://training-course-material.com/training/Git_-_Branching_and_Merging
* Visualization of a branching structure: http://training-course-material.com/images/d/d4/Git-gitk.png 
* Bad braches:

==Bad Branching⌘==
The “no branch” branch
[[File:Nobranch.png|100px]]

==Bad Branching⌘==
Useless branches
[[File:UselessBranch.png|250px]]

==Branching Utilization vs Abuse⌘==
# Don’t fear branches (not branching is badness)
# Don’t merge everything
# Keep your own stuff [your own]

==The Git Directory⌘==
* .git
* A hidden directory within working copy
* Retains Git config data
* Holds all your datas
[[File:Treasure.png|300px]]


==The Big Three Trees⌘==
[[File:Local.png|300px]]
# Working Directory
# Index
# 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”
[[File:Index.png|300px]]

==The Head⌘==
[[File:Heads.png|300px]]
* 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⌘==
[[File:Keyboard.png|300px]]

==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 [[File:Github.png|50px]]
* Bitbucket - Free private repos [[File:Bitbucket.png|50px]]
* GitLab - Targeting enterprise hosts (self managed) with open sourced Community Edition  [[File:Gitlab.png|50px]]
* Your ''servers'' - Just install and go (ain’t distributed architecture great?) [[File:Yoruservers.png|50px]]

==Normal Workflow Examples⌘==
{| class="wikitable"
|-
!'''Release-Centric'''!!'''Continuously Integrated'''
|-
|
# Checkout/update your release branch (RB) from remote
# Cut a feature branch (FB) from RB
# Push your FB to remote
# Commit your work to FB
# Frequently update RB & merge down into FB
# When FB is finished & tested merge up to RB
# Push merged RB back up to remote
# Tag RB with release info when signed-off (release candidate)
|
# Checkout/update master branch (M) from remote
# Cut an FB from M
# Commit work to FB
# Push your FB to remote
# Frequently update M & merge down into FB
# When FB is finished and tested, merge up to M
# Push M back up to remote
|}

==Log - the Commit History⌘==
* git log
* Pretty it up with CLI customizations
 oneline
 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
[[File:Commit1.png]]
* Woops
 git commit –amend
 Don’t amend after push
[[File:Commit2.png]]

==Browsing Git⌘==
{| class="wikitable"
|
* 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.
|
[[File:Browsing.png]]
|}

==Searching Git⌘==
 git bisect <subcommand> <options> 
* Bisecting
A indispensable for larger teams and highly active repos

# git bisect help
# git bisect start [--no-checkout] [<bad> [<good>...]] [--] [<paths>...]
# git bisect bad [<rev>]
# git bisect good [<rev>...]
# git bisect skip [(<rev>|<range>)...]
# git bisect reset [<commit>]
# git bisect visualize
# git bisect replay <logfile>
# git bisect log
# git bisect run <cmd>...

==Git - Extras ⌘==
* git-bisect
* git stash
* Interactive mode
*: git add -i
*: git rebase -i
* Porcelain and Plumbing
* GitHUB

==Git Diff⌘==
{| class="wikitable"
|
* git diff
:* git diff HEAD or git diff HEAD^
[[File:Diff1.png]]
|
Cheat/lazy
* git status
[[File:Status.gif]]
|}

==Branching⌘==
'''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!]

[[File:Branches.png|300px]]

==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(-)

==Rebasing⌘==
*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! [[File:Rebase.png|300px]]

==Stashing⌘==
*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. [[File:Stash.png|300px]]

*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

==Tagging⌘==
 git tag [-a | -s | -u <key-id>] [-f] [-m <msg> | -F <file>]<tagname> [<commit> | <object>] [[File:Tag.png|300px]]

'''Is'''
* 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 > project.zip
* 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
  [alias]
    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
 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 gc.auto 0

==Distributed Workflow Examples⌘==
Centralized Workflow
[[File:Centralized.png|300px]]

==Distributed Workflow Examples⌘==
Integration Manager
*Can be used with CI workflow
[[File:Workflow.png|300px]]

==Distributed Workflow Examples⌘==
Dictator and Lieutenants Workflow
[[File:Dictator.png|300px]]

==Setting Up A Central Repo⌘==
[[File:Dosprompt.gif]]

What does it take to manage your own Git repos?

==The Install⌘==
[[File:Trick question.png]]

==User Management⌘==
* You can run everything through SSH (i.e [[http://git-scm.com/book/en/v2/Git-on-the-Server-Setting-Up-the-Server]])
* Run a local solution like GitLab ([[https://about.gitlab.com/features/#community]])
* Use a private cloud solution (like Github or Bitbucket)
So let's walk through something on our machines.

==Bisecting⌘==
I've planted a bad seed in code.sh, 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 [[File:Magic.png|100px]]
  git bisect run bash code.sh

What just happened?

==Submodules⌘==
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 https://bitbucket.org/vim-plugins-mirror/vim-surround.git master --squash
  ...
  git subtree pull --prefix .vim/bundle/tpope-vim-surround https://bitbucket.org/vim-plugins-mirror/vim-surround.git 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 https://path.com/to/project.git
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⌘==
[[File:Hook.png|250px]]

==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?
* [https://www.reddit.com/r/git/comments/21rvw3/your_favourite_git_hooks/ Get some inspiration]
* [https://github.com/git-hooks/github-todos Stay on top of your TODOs]

==Installing Git Hooks⌘==
* placed in ''.git/hooks''
* use different languages
** bash/shell scripting<source>#!/bin/sh</source>
** Ruby<source lang="bash">#!/usr/bin/env /path/to/rails runner</source>
** Python<source lang="bash">#!/usr/bin/env python3</source>
** Node.JS<source lang="bash">#!/usr/bin/env node</source>
** etc etc!
* watch out for cross-platform environments & teams!