Talk to Git

Jim Chen

VCS and Git

Why Version Control?

•History is important.

•Time travel is possible!o Roll back to old version

•Collaborationo Contributors can work at the same time.

Local Version Control System

•Only on your PC

Centralized Version Control System

•Server owns all versions.

•Clients only have one version.

Distributed Version Control System

•Every one has a full copy

•Recovery friendly

History

In 2005, relationship between Linux Kernel community and commercial company of BitKeeper broken down for reasons.

Goals of Git

•Speed

•Simple design

•Strong support for non-linear development (branches over the world)

•Fully distributed

•Able to handle large projects efficiently (Linux kernel is really huge)

Git Basics

Snapshots, Not Differences

Nearly Operations are local

•Full copy in local computer

•Make changes but can keep update with remote

•Network independent

Integrity

•Check-sum based tracking

•SHA-1 Hash function

•40-characters

Generally Only Adds Data

•Everything committed will be a snapshot in Git history

•Even another commit remove the file.

Three States

•Committed

•Modified

•Staged

Welcome Aboard

Get Repository

• Initialize in existing directory$ git init$ git add *.sh$ git commit -m "Initial project version"

•Clone from existing repository$ git clone <url>

File Status

untrackedunmodifie

dmodified staged

add the file

remove the file

git add <file>

git rm <file> commit

stage the file

edit the filegit add <file>

git commit

git reset HEAD <file>

git checkout <file>

Checking Status

$ git status

Tracking New File

$ touch README$ git status

Tracking New File

$ git add README$ git status

Staging modfied

Make some change in hello.sh$ git status

Staging modfied

$ git add hello.sh$ git status

Viewing Unstaged Changes

$ vim hello.sh$ git diff

Viewing Staged Changes

$ git diff --cached

Discard modified

$ git status$ git checkout hello.sh$ git status

Unstage staged

$ git reset HEAD hello.sh

Commit It

$ git commit

Guidelines to Commit

No whitespaces$ git diff --check

• Try to make each commit a logically separate change set.

• Getting in the habit of creating quality commit messages.o This would help others to review.

More commands

•Removing files$ git rm <file>

•Moving files$ git mv <file>

Viewing History in CLI

$ git log

Viewing History in GUI

$ gitk

Oops!Something missed.

But committed already...

Change Last Commit

$ git commit --amend

Working with Remote

Clone Repository

$ git clone <url> <folder>

Showing Remotes

$ git remote -v

Adding and Removing Remotes

$ git remote add <remote-name> <url>$ git remote rm <remote-name>

Fetching and Pulling from Remotes

$ git fetch <remote-name>$ git pull <remote-name>

= git fetch + git merge

Pushing changes to Remote

$ git push <remote-name> <branch-name>

Branching

Why branches?

•Stabilize stables

•Make topics no bother

Data Structure

•Blobo Storing file data

•Treeo Structure of project, just like directory

•Commito A pointer to a single tree, with some meta-

data

•Tago Mark a commit as special

Commit

Versions

A lightweight movable pointer to one of the commits.

Branch in Git is

HEAD is a special pointer to the current working branch you are.

I want to resolve a topic

$ git branch topic1$ git checkout topic1

C0 C1 C2

master

HEAD

topic1

HEAD

$ git checkout -b topic1

C0 C1 C2

master

HEAD

topic1

HEAD

Commit new change on topic1

C0 C1 C2

master

topic1

C3

topic1

Urgent!!Bug fix for master

Create hotfix branch from master for fix bug (C4)

$ git checkout master$ git checkout -b hotfixFix bug and commit change

C0 C1 C2

master

topic1

C3

C4

hotfix

Quiz:Where is the HEAD? HEAD

Merge branches

hotfix is good for release

Merge Mechanism

•Fast-forwardBranches are in the same history flow so Git can

only change the pointer to the new one.

•Three-way merge– Locate the common ancestor– Git automatically calculate how to merge– Create a merge commit recording new

snapshot

Fast-forward

$ git checkout master$ git merge hotfixUpdating ...Fast forward

C0 C1 C2

master

topic1

C3

C4

hotfix

master

Three-way merge

$ git checkout master$ git merge topic1Merge made by recursive

C0 C1 C2

topic1

C3

C4

master

C5

Snapshot to merge into

Snapshot to merge into

Common Ancestor C6

master

Gosh...Conflict happens

What will you see when merge conflict

Resolve and commit the change

Rebasing

Merge is good butI want a clearer history

Merge

$ git checkout master$ git merge topic1Merge made by recursive

C0 C1 C2

topic1

C3

C4

C5

C6

master

Basic Rebase

$ git checkout topic1$ git rebase master

C0 C1 C2

C4

topic1

C3 C5

master

topic1

C3' C5'

Rebasing pushed commits confuses reviewers.

Do not rebase commits have pushed to a public repository!

Example of rebasing a pushed commit

What's more?

Where is the commit lost?

Look into commit updated history

$ git reflog

SHA-1 id you can use

Cherry-pick commit d6297c2$ git cherry-pick d6297c2

Stashing

New request comes but I am working on something else.

$ git stash$ git stash list/pop/apply

Interactive Rebase

Change multiple commitsReordering

Interactive rebase

C0 C1 C2

master

C3 C4

$ git rebase -i HEAD~2

Successfully rebased and updated refs/heads/master.

master

C4 C3

git official sites: http://git-scm.com

commands: http://git-scm.com/book/commands

zh book: http://git-scm.com/book/zh

Git and Linux Kernel: http://en.wikipedia.org/wiki/Linux_kernel#Revision_control

Git Immersion: http://gitimmersion.com (Practices)

Revision Control: http://en.wikipedia.org/wiki/Revision_control

Distributed VCS: http://en.wikipedia.org/wiki/Distributed_revision_control

References