Talk to git
-
Upload
yen-ting-chen -
Category
Self Improvement
-
view
324 -
download
0
description
Transcript of Talk to git
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