All Things Git

Git, GitHub, Git Hooks & More

Alex DiLiberto

@alex_diliberto

alexdiliberto.com

Version Control?

Version control, revision control, source control??? Management of some collection of information

Note - not solely speaking in terms of software development. Any file could be version controlled.

EX: graphic designer who wants to keep a history of all changes to an image or page layout.

Allows you to revert to a previous state, see change history

EX: jQuery Plugin - Working on some awesome jQuery plugin, realize something you did wasn't working? - Before: Press CMD-Z 100 Times, or if go through a bunch of timestamped file names.

Origins of client/server version control date back as far as the mid 80’s (CVS) but things really didn’t start getting too sophisticated until the late 90’s and into the early 21st century (BitKeeper – 1998, SVN – 2000, Monotone – 2003)

Three major phases since the beginning of Version control.

1st Gen – File Locking system –Only one person could be working on a file at a time.
2nd Gen – Centralized - bit more permissive about simultaneous modifications. (serious downsides: single point of failure)
3rd Gen – Distributed - clients don’t just check out the latest file snapshots - they fully mirror the repository

Every checkout is a complete backup of the data

EX: now what happens when that server goes down (corrupted HDD)

-> Fast forward to 2005 and the birth of Git...

git

2005
Linus Torvalds
Open source
Distributed version control

“Open source is the only right way to do software.”

Linus

Created by Linus Torvalds (Finland)

Chief architect and brains behind the Linux kernel
With that probably drove what I’d call one of the the most important/impactful technological advancements of the latter 20th century

Open source – The software for which the source code is freely available.
Distributed – Every Git working directory is a full repository with complete project history

Quick Git history

For most of the lifetime of the Linux kernel dev and maintenance (1991–2002), file updates were simply passed around as patches and archived files. (changesets)
2002, the Linux kernel project began using a proprietary DVCS system called BitKeeper.
2005, BitKeeper’s free-of-charge status was revoked and this prompted Linus Torvalds to develop his own tool
Based on on his experience working and needing something to support such a large project like the kernel, he wanted something with: Speed, Simple design, Ability to have hundreds of parallel branches, fully distributed

Why should I care?

Community adoption
Decentralized
Performance
Data assurance
Free/open source

Why is it better? Why should you be interested?

#1. Community adoption:

If you’ve been keeping an eye on the web dev world – you’ve probably at least heard of Git

GitHub has really helped this emergence

-Hosted git server with solid UI
-It has really helped to introduce a Social aspect to coding
-Think of it kind of like wikipedia for code, it’s very interactive and collaborative

#2. Decentralized:

Ex: You're on a plane taking a trip to Hawaii. Developing software (geek), something happened and you need an older version of the file you're working on but its on your SVN repo back at the office.

-Backups
-Many different workflow possibilities with this setup (we’ll talk about later)

#3. Performance: (Small + Fast)

-Git's repo and working directory sizes are extremely small compared to SVN
-(Java Dev's) .SVN folder in each and every single directory.
-Git is generally orders of magnitude faster (Compared to most Centralized Version Control Systems)
-Nearly all operations are local which means ZERO network latency for almost everything you'll be doing.

For some context I’ll give Examples:

Commit Images (B) Add, commit and push 1000 1k images -1.53s vs. 24.70s - 16x faster than SVN
Log (50) Log of the last 50 commits (19k of output) - 0.01s vs 0.38s - 31x
Log (All) Log of all commits (26k commits - 9.4M of output) - 0.52s vs. 169.20s - 325x

#4. Data Assurance:

-Git insures the cryptographic integrity of every bit in your project. Meaning...It's not possible to get anything out of Git other than the exact bits you put in because every file and commit is hashed and retrieved by its hash when checked out.
-Content-addressable filesystem – data is stored by a hash of its content rather than its filename on disk.
-Pic is a diagram of the SHA-1 compression function (Secure Hashing Algorithm)
-SHA-1 hash is 160bits, meaning 20 bytes and its expressed in hexadecimal. Quick math (each hex char 4 bits), that’s 40 Hex characters per a single SHA-1 hash.

Fun Fact: The number of randomly hashed objects needed to ensure a 50% probability of a single collision is about 2^80 or 1 million billion billion. That’s 1,200 times the number of grains of sand on the earth. There’s a higher probability that every member of your programming team will be attacked and killed by wolves in unrelated incidents on the same night.

#5. Finally, its Free and Open Source

-And who doesn’t love that?

Time to shift our thinking

SVN

Git

Git has three main states that your files can reside in:

committed
modified
staged

Committed means that the data is safely stored in your local database.

Modified means that you have created or changed the file but have not committed it to your database yet.

Staged means that you have marked a modified file in its current version to go into your next commit snapshot.

Staging region can be a little strange to understand (especially coming from SVN). The staging area: simply an additional file that just stores information. Allows you to easily pick and choose what you want to commit from your working dir.

***QUICKLY TALK ABOUT THE LISTED COMMANDS*** Note: we’ll discus them in more detail in the upcoming slides

Remember back to the Hawaii Example. All of this until the remote repo is local.

Basic Commands

init, clone, add, commit, log, status

Branching

Show an example of a snapshot of commits

$ git commit -m 'initial commit of my project';

$ git commit -m 'fixed bug #1328...';

$ git commit -m 'add feature #32...';

Branch - simply a lightweight movable pointer to a single commit.

$ git branch testing;

Now say you want to create your own branch for some feature you’re testing...You do this with the git branch command (as shown)

(GIT CHECKOUT) Notice the git branch command only created a new branch — it didn’t switch to that branch

QUESTION: What do you think will happen if I do another commit on this repository while I’m checked out onto the testing branch?

QUESTION: Now Say I want to move back to the master branch? What happens (HEAD moves, local working directory is updated with new snapshot)

Branches Summary

Lightweight/flexible/fast
"Branch early, and branch often"
So much power and control with simple 2 commands.

REMEMBER: how quick and easy this is. A branch is ONLY a pointer. In SVN it would involve copying all of the projects files into a another directory.

Merge vs Rebase

What happened here?

Merge vs Rebase

This is looking at a new repository history. What happened here?

Merge: Two Types: Fast Forward, and 3-Way Merge. 3-Way Merging in Git creates a special commit that has two unique parents. (Merge commit)

Rebase: Takes all the changes that were committed on one branch and replay them on another one. Helps to produce a cleaner looking history.

Treat rebasing as a way to clean up and work with commits before you push them. NEVER rebase your commits that have already been pushed to a Remote branch. Git rebase is a re-write of history. You should never do this on branches that are "public" (i.e., branches that you share with others). If someone clones your branch and then you rebase that branch -- then they can no longer pull/merge changes from your branch -- they'll have to throw their old one away and re-pull.

Also...

git pull --rebase

Git on the Server

Simple Bare Repository
- Quick
Github
- User centric hosted solution
GitLab/Phabricator
- Self hosted
Gitolite
- Access control layer sits on top of git
- Single UNIX hosting user / Many “virtual” users
- Simple yet powerful
- Security with SSH based authentication

Lightweight

Transparent

Scalable

Bare Repo: If you're a minimalist or just need something quick and dirty. Then all you really need for your own Git server is a bare repository -Git repo without a working directory -To Do This: Create the repo directly on the server or just secure copy from your local machine. Either way achieves the same result. Gitolite: Very similar to the bare repo option, but with a lot more options and convenience. One of the most complicated aspects of setting up a Git server is user management. Gitolite handles this extremely well. Say you want some repositories to be read-only to certain users and read/write to others, access and permissions can be very bit difficult to manage. At its core, Gitolite is an access control layer on top of git -Single unix user and Many "virtual” users (alex, sai, nathan, rajeev, etc) -Control Read and Write access from the greater repository level all the way down to the branch / directory level -Simple yet powerful, written in about 3000 lines of perl and it has tons of solid documentation. -SSH based authentication (Pub/Priv keys). Server tracks this information in an authorized_keys file. TO ADD A NEW USER: Simple - To add a new user Johnny, An admin just obtains a copy of Johnny’s public key, commit the change, push it to the server and everything else is taken care of. Why Gitolite? -Lightweight -Transparent - The developer interacting with the gitolite server doesn't need to change around their workflow. -Scalable There are other solutions quite similar (Gitosis, Gitorious) -But Gitolite is in full active development and has strong community support behind it Finally GITHUB, which we discussed earlier. - User centric and public repositories for all users are completely free. - Rather than just pulling someone else’s code down you fork their project to create a copy of it under your user name

Workflows

Gitflow

gem install gitflow

Forking

.git/hooks

pre-commit

post-commit

pre-rebase

post-checkout

post-merge

pre-receive

post-receive

update

HOOKS: - A hook is a shell script that Git will run at a specific time EX: Before a commit, before you rebase, maybe on server after you push code to it, etc. QUESTION: WHY USEFUL? WHAT ARE SOME USES FOR THIS? Well for example, you could leverage a Git hook to run a complete test suite before you make a commit…and only commit if you have passing tests You could have a hook to deploy your code to a webserver whenever you make a change CLIENT: ***All the names are pretty self explanatory PRE-COMMIT: Very useful to run certain tests so that you can abort the commit if tests fail post-commit: Useful perhaps for any notification purposes PRE-REBASE: remember what we talked about earlier, could be very useful to not allowing a rebase on any commits that have already been pushed. post-checkout and post-merge: Not used a lot SERVER: pre-receive: can be used to check and interrupt the acceptance of the new commits. POST-RECEIVE: notifies that commits have been published on this repository. Examples include e-mailing a list of people, notifying a CI server, deploying to a mirror branch for Git-SVN UPDATE: is a version of pre-receive that is run once per each different branch. Could be very useful to trigger a wider set of testing server side, like functional or visual tests above and beyond just the unit tests of a pre-commit hook.

Things we didn't cover in detail

`$ git diff`

`$ git (revert|reset)`

Tagging
Git Config
- user.name / user.email
Branch traversal and detached HEAD state
Ancestors and Commit Ranges
- $ git show HEAD^
- $ git show feature~3
- $ git log origin/master..HEAD
Undoing Changes
- $ git revert HEAD~2
- $ git reset HEAD^
$ git stash
Remote branches
ReFlog

Tagging – Flag for a specific point in your git history. (Generally used to mark releases) 1. Lightweight – just a pointer to a commit (think branch) 2. Annotated – Actually stored as an object in the Git repo. They are checksummed and contain the tagger name, email, date and message. Git Config – self explanatory. Lets you configure your Git install. Lets you define everything from user info to preferences. -Set aliases. Set favorite text editor to show when writing commit messages. Traversal/Detached Head/Ancestors .. syntax example = range of commits reachable by the HEAD reference but not the origin/master reference Allows you to see what you’re about to push to a remote branch Diff 1. git diff –cached – Show differences between HEAD and staging region 2. git diff – Show differences between staging region and local working directory 3. git diff HEAD – Show differences between HEAD and your working directory Stash – Takes a dirty state of your working directory and saves it on a stack EX: working, need to switch for an urgent fix but don’t want to commit half-done work Remote Branch – Read only reference (bookmark) to the state of a branch on your public repository. They only move locally when you do any type of network communication with that branch. 3 ways to interact. 1. Git fetch – downloads a branch from a remote repo; doesn’t integrate changes into local repo. (lets you inspect) 2. Git pull – *Same as SVN Update*. Automated version of fetch (same as git fetch + git merge) 3. Git push – Publish changes to the remote repo *4th* Git remote – needed to setup a remote repository RefLog – Used as a safety measure. It’s a log that keeps track of any updates made to branch tips. Very useful if you accidentally blow away a commit you didn’t mean to.

Do's, Don'ts, & Best Practices

Commit often, Perfect later, Publish once

Branch early, branch often

Use your scratch pads

Don't panic

git reflog, git fsck, git stash

Do follow a workflow

Do write useful commit messages

Don’t Panic: If you mess up, there is generally 3 places "lost" work could be hiding. -git reflog - shows each commit that modified the git repo -git fsck - "file system check”. check for dangling commits (no longer reachable by reference name – branch/tag) -git stash – you may have stashed instead of committing and forgot about it. Do follow a workflow - a guideline for how to use git within your project team Useful commit message: Lots of different guidelines out there. The normal rule of thumb is to use first line to provide a short 50 char summary, followed by a new paragraph is a more detailed explanation. git log --oneline will help you understand why

Don't rewrite (public) history

All Your Rebase

git pull –rebase

git rebase –i

Do enforce standards

hooks, testing, proper commit messages, workflows, merging vs rebasing, and more

Do Backup

$ git bundle create /tmp/my-project.backup --all

References

http://en.wikipedia.org/wiki/Git_(software)

http://git-scm.com/book

http://www.vogella.com/articles/Git/article.html

http://vimeo.com/33631836

http://whygitisbetterthanx.com

http://nvie.com/posts/a-successful-git-branching-model/

http://css.dzone.com/articles/all-git-hooks-you-need

http://net.tutsplus.com/tutorials/tools-and-tips/quick-tip-automation-with-git-hooks/

http://lwn.net/Articles/328436/

http://www.gitguys.com/topics

http://danielkummer.github.io/git-flow-cheatsheet/

http://www.slideshare.net/saharabeara/advanced-git-tutorial

http://sethrobertson.github.io/GitBestPractices/

http://mislav.uniqpath.com/2013/02/merge-vs-rebase/

Thanks!

Alex DiLiberto

@alex_diliberto

alexdiliberto.com