Talk to git
Upcoming SlideShare
Loading in...5
×
 

Talk to git

on

  • 400 views

A summarize and re-categorize of the git tutorial.

A summarize and re-categorize of the git tutorial.

Statistics

Views

Total Views
400
Views on SlideShare
400
Embed Views
0

Actions

Likes
0
Downloads
3
Comments
0

0 Embeds 0

No embeds

Accessibility

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • How to collaboration?

Talk to git Talk to git Presentation Transcript

  • Talk to Git Jim Chen
  • VCS and Git
  • Why Version Control? •History is important. •Time travel is possible! o Roll back to old version •Collaboration o 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 untracked unmodified modified staged add the file remove the file git add <file> git rm <file> commit stage the file edit the file git 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 •Blob o Storing file data •Tree o Structure of project, just like directory •Commit o A pointer to a single tree, with some meta-data •Tag o 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 hotfix Fix 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-forward Branches 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 hotfix Updating ... Fast forward C0 C1 C2 master topic1 C3 C4 hotfix master
  • Three-way merge $ git checkout master $ git merge topic1 Merge 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 but I want a clearer history
  • Merge $ git checkout master $ git merge topic1 Merge 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 commits Reordering
  • 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