Intro to git (one hour version)

Git: a brief
introduction
Randal L. Schwartz, merlyn@stonehenge.com
Version 5.0.2 on 28 Jul 2012

This document is copyright 2011, 2012 by Randal L. Schwartz, Stonehenge Consulting Services, Inc.
This work is licensed under Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License
http://creativecommons.org/licenses/by-nc-sa/3.0/

Saturday, August 4, 12

Overview

• Key concepts of git
• Using git by yourself
• Using git with others


Key concepts
• Manages trees, not ﬁles
• Stores entire history for a commit
• Serverless (mostly)
• Source-code manager
• No meta-data
• Handles binaries badly
• Optimized for branch/merge
• If not branching or merging, bad ﬁt


The moving parts
• Stored in “.git”:
• Object repository
• files (“blob”), directories, commits
• Operational files (config, etc.)
• Working directory
• Low-level CLI (“plumbing”)
• High-level CLI (“porcelain”)
• Various GUIs
• Various web UIs


Commits
• Unit of work
• Usually has a parent
• Two or more on a merge
• Zero on a “root” commit
• Metadata (committer, message, timestamps)
• Tree of ﬁles at time of commit


Trees
• SHA1 of each file in a directory
• SHA1 of each directory
• ... recursively
• These are kept efficiently in the object store
• Identical files map to same SHA1, stored once
• And so do identical trees!
• No penalty to “move” a subdirectory or file


Making commits
• Changes made to work dir
• Added to index with “git add”
• Committed with “git commit”
• Commit updates HEAD
• Prior value of HEAD is the parent
• HEAD almost always points at a branch name
• Thus, branch name is also moved forward
• Series of commits loosely also called “branch”
• Commit also gets a SHA1


The SHA1 is king
• SHA1 of commit defines:
• Metadata of commit
• Tree of files
• Parentage
• Parentage defines previous commits
• Thus, SHA1 uniquely defines complete history
• Useful when working with others


Naming commits
• SHA1 (can often be abbreviated)
• HEAD, branch-name, tag
• Optionally followed by @{historical}
• “historical” can be:
• yesterday, 2011-11-22, etc (date ref)
• 1, 2, 3, etc (prior version of this ref)
• “upstream” (upstream version of local)
• Optionally followed by ~n for “n’th ancestor”


Branches
• Initial branch is “master” (name not special)
• Fork the current branch:
git checkout -b topic1
• topic1 is set to same SHA1 as previous branch
• HEAD now points at topic1
• New commits now apply to topic1
• Switch back with “git checkout master”


Multiple branches
• Start a second topic based on original master:
git checkout -b topic2 master
• Work, work, commit, commit
• Switch back and forth at will:
git checkout topic1
• Topics record independent deltas to master
• A B C (master) D E F (topic1)
• A B C (master) G H I (topic2)


Combining the work
• Merge the work back in to master:
git checkout master
git merge topic1
git branch -d topic1
• This was a fast-forward merge:
A B C D E F (new “master”)
A B C G H I (topic2)


Really merging
• Now to bring topic2 back into the mix:
git checkout master # already there
git merge topic2
• Three-way merge between master, topic2,
relative to common ancestor (“C”)
• Might cause conﬂicts
• New commit will have both F and I as parents
• History is no longer linear
• DEF and GHI will appear as parallel lines


Linear history
• We can “rebase” commits:
A B C D E F (master)
A B C G H I (topic2)
git checkout topic2; git rebase master
• Git replays new commits on top of ancestor:
A B C D E F (master) G’ H’ I’ (topic2)
• Might cause conﬂicts at each replay
• Need to clean up when done:
git checkout master; git merge topic2
git branch -d topic2


Rebase vs merge
• Both can have conﬂicts
• Merge makes a bushy tree
• Hard to peel out “linear” history
• Rebase makes a linear tree
• But gets rid of commits
• Rebase is nicer, but you must take care
• Shared commits should not be rebased


Using git yourself
• Create the repo at your top-level dir:
git init
git add -A . # or git add *
git commit # invokes a text editor
• You now have a single “.git” dir
• The current working dir snapshotted as root


Work a bit
• Edit some ﬁles
• Check the status: git status
• Add all the changes and commit them:
git add -A .
git commit
• Shortcut if you haven’t added new ﬁles:
git commit -a
• You’re making commits on the master branch


What’s changed?
• git diff
• Diff between index and working tree
• These are things you should “git add”
• “git commit -a” will also make this list empty
• git diff HEAD
• Difference between HEAD and working tree
• “git commit -a” will make this empty
• git diff --cached
• between HEAD and index
• “git commit” (without -a) makes this empty


Useful commands
• git archive: export a tree as a tar/zip
• git bisect: ﬁnd the offensive commit
• git cherry-pick: selective merging
• git mv: rename a ﬁle/dir
• git rm: ditto for delete
• git revert: add commit to undo previous commit
• git blame: who wrote this?


Read the history
• git log
• print the changes
• git log -p
• print the changes, including a diff between
revisions
• git log --stat
• Summarize the changes with a diffstat
• git log -- file1 file2 dir3
• Show changes only for listed files or subdirs


Using git with others
• Commits can be transmitted by many protocols
• On disk
• HTTP[S]
• git protocol over TCP
• git protocol over SSH
• git over SSH is preferred


Getting commits
• Most likely: git clone over SSH:
git clone user@host:/some/path/to/repo.git
• Makes local repo.git dir
• Checks out remote repo’s “HEAD” as master
• Adds remote repo as “origin”
• Nothing special about that name


Working with upstream
• Work on local master:
edit edit; git commit -a
• Refresh from upstream
• By merge: git pull origin master
• By rebase: git pull --rebase origin master
• Push to upstream:
git push origin master
• Check what’s different before pull:
git fetch origin; git diff master origin/master


For further info
• See “Git (software)” in Wikipedia
• And the git homepage http://git-scm.com/
• Git wiki at https://git.wiki.kernel.org/
• Wonderful Pro Git book: http://progit.org/book/
• Get on the mailing list
• Helpful people there
• You can submit bugs, patches, ideas
• And the #git IRC channel (on Freenode)
• Now “git” to it!


Intro to git (one hour version)

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Intro to git (one hour version)

Similar to Intro to git (one hour version) (19)

More from Randal Schwartz

More from Randal Schwartz (7)

Recently uploaded

Recently uploaded (20)

Intro to git (one hour version)