Introduction toGit Workshop@rtoal 2013-02-11

Scope

We have only one hour. So this will be just an introduction. There's no point in overwhelming people. So...

● We'll see only about 20 basic commands, leaving all others to a future workshop.

● We're not going anywhere near submodules, subtree merging, or Git internals.

What is Git?

● A fully distributed VCS (everyone has a copy of the repo)

● Incredibly fast● A system that is awesome at branching● Able to handle huge, huge projects● So completely unlike CVS and SVN that you

should probably forget everything you already know about version control if you want to understand it

Clay Shirky tells you about Git

Watch from 06:15 to 11:00 for now. (Later watch the whole thing, it's really good!)

Good to know

Git stores snapshots, not diffs

"Everything is local"

Everything is checksummed (SHA-1)● tamper-proof

● no version numbers

Let's start

Learn by doing:

$ git config --global user.name "Jane Doe" $ git config --global user.email "jd@example.com" $ git config --global color.ui auto $ git config --list $ cat ~/.gitconfig $ git config --help $ git --help

Let's make a project

We have two choices here!

● We can start working locally and import our work into a new git repo on our box, or

● We can clone an existing repo (for instance, one that is already sitting at, say, github.com) to our box.

(We'll do it the first way for now....)

Create a project

$ mkdir hello && cd hello $ git init $ ls -la $ echo 'My first project' > README.md $ echo 'print("Hello, world")' > hello.py $ python hello.py $ git status $ git add . $ git status $ git commit -m "Initial commit" $ git status $ git log

Git requires that you explicitly track files so you don't accidentally commit things

The "Pay Attention" pic from Pro Git

Repo: metadata + compressed object database

Working directory: a checkout of a single version of the project

Staging area (a.k.a. the Index): says what will go into the next commit

How about some changes?

$ vi hello.py # make some edits $ git status # note it is modified and not staged $ git add . # stage changes $ vi hello.py # more fixes $ git status # heh, modified and unmodified $ git diff # diff between working files and staged $ git diff --cached # diff between staged and committed $ git add . # now all staged $ git status # all better, see? $ git commit # brings up an editor to enter message $ git log # commit log $ git log -p # commit log with diffs $ vi hello.py # make another change $ git commit -a # stage AND commit (cool shortcut!!) $ git log --oneline # log, one line per commit

Undoing

$ vi hello.py # make a dumb change $ git status # blech, we don't want it $ git checkout -- hello.py # blow away the change (CAREFUL!!) $ git status # see, we're clean again $ vi hello.py # this time, make a useful change $ git add . # stage it $ git status # yep, it's staged $ git reset HEAD hello.py # unstage $ git status # just modified, no longer staged $ git commit -a # okay fine, commit it $ git revert 5f74082 # "Undo" commit (use your own hash) $ git log # SEE HOW REVERT WORKS? :-)

TIP: Use a graphical tool for checkouts and resets

Review so far

mv, rm, ls-tree, and gitk

$ git mv hello.py hi.py $ ls # it renames in the working dir too $ git status # git knows its a rename $ vi hi.py # make some changes $ git commit -a # stage and commit $ git rm hi.py $ ls # removes in the working dir too $ git status # git knows it's a delete $ git commit -a # commit the delete $ git log --oneline # what we've done so far $ git ls-tree HEAD # see what's in your repo $ gitk # hey it's a cool gui tool!

Branch and merge

$ git branch # hey we're on master $ git branch -v # a branch SIMPLY points to a commit $ git branch newstuff # create a new branch $ git branch -v # it's created but master is active $ git checkout newstuff # switches to new branch $ git branch # yay, newstuff is current now $ vi fancy.js # create a new file on the branch $ git add . # Can't do commit -a on new files $ git commit -a $ git branch -v # see how the branches differ? $ git checkout master # back to master $ vi README.md # do a non-conflicting change $ git branch -v # see how we are doing $ git merge newstuff # merge newstuff into master

Conflicts

$ git branch -v # on master $ git checkout newstuff # switch $ vi fancy.js # make a change $ git commit -a $ vi fancy.js # a second change, just for fun $ git commit -a $ git checkout master # switch to master $ vi fancy.js # do a change you know will conflict $ git commit -a $ git merge newstuff # CONFLICT $ vi fancy.js # Repair the conflict $ git commit -a $ git log --pretty=raw $ git log --oneline --decorate --graph --all $ gitk

More Pictures!

Want to understand exactly what a branch is? And what the heck is meant by HEAD?

Well, I'm not going to do any better than The Visual Git Guide, so let's go take a quick look over there.

Also see Scott Chacon's Screencast on Branching and Merging. (youtube, 15 min)

The big deal about Git branching

Branching is so cheap and so easy in Git that it encourages you to branch and merge often.

Firing off a "topic branch" to work on a little something is easy. You can jump back to the mainline for a hotfix, take care of that, and then go back to your topic. So easy.

Let's see it....

Workflow example: topics & hotfixes(From Section 3.2 of Pro Git)

You've branched to work on "Issue 53"

You switch back to master, branch for a hotfix, and commit the fix

Merge hotfix into master, then go back and work on Issue 53 some more Merge Issue 53

into master

1 2

3

4

Another way to "merge"

You can also bring in work from other branches by cherry-picking and rebasing.● Cherry picking copies a commit from another

branch by replaying it on the current branch● Rebasing replays all the commits from

another branchYou get a cleaner, "linear" history with rebase, but never rebase commits that you have pushed to a public repository (See ProGit, section 3.6)

Remotes

Let's share this project on GitHub. First I'll create the project rtoal/hello there (you will call it something else of course), then...

$ git remote add origin git@github.com:rtoal/hello.git $ git remote $ git remote -v $ git push -u origin master

"-u" lets us track the remote. From then on we can just say "git push"

● origin is the remote name● master is the ref both locally and on

the remote (short for master:master)

Another user

Now open another window to simulate another user...

$ git clone git@github.com:rtoal/hello.git $ cd hello $ vi fancy.js # Make a change $ git add . # Can't use commit -a $ git commit $ git log -v $ git log --decorate --oneline # So much better! $ git push # CHECK GITHUB PAGE NOW $ git log --decorate --oneline # Observe changes after push

Merge conflict from a remote

Go back to the first window. Now...

$ vi fancy.js # Make a conflicting change $ git commit -a $ git push # REJECTED!! $ git status # "Ahead of origin/master by 1 commit" $ git pull # Whoa, a conflict $ git commit -a # Commit the, yes, it's a merge $ git log --decorate --oneline --graph -all $ git push $ git log --decorate --oneline --graph --all $ gitk

Wrapping up that example

Go back to the second window. Now... $ git status $ git pull $ git log --decorate --oneline --graph --all

Fetch or pull?

git pull does some magic: it fetches objects from the remote into your local repo then merges them. You'll see your working directory change.git fetch just does the fetch part.

See Mark Longair's discussion of why you should (probably) fetch and merge explicitly, instead of pulling.

Some good resources

● Official Docs● Tutorial● Manual● Book● A few git tips you didn't know about● Visual Guide● Another Introduction● Git Reference

Kthxbye

Hopefully, you now feel acquainted with Git, and are ready to use it with confidence.

Even though we only covered the basics.

NEXT TIME(S):● Stashing● Submodules● Subtree merging● Rewriting history● Git internals● Hosting your own shared Git repository● More case studies● GitHub fun -- Forking, GUI tools, etc.