9/16 L&L, “git”by francois

A UNIX programmer was working in the cubicle farms. As she saw Master Git traveling down the path, she ran to meet him. - “It is an honor to meet you, Master Git!” she said. “I have been studying the UNIX way of designing programs that each do one thing well. Surely I can learn much from you.” - “Surely,” replied Master Git. - “How should I change to a different branch?” asked the programmer. - “Use git checkout.” - “And how should I create a branch?” - “Use git checkout.” - “And how should I update the contents of a single file in my working directory, without involving branches at all?” - “Use git checkout.”

After this third answer, the programmer was enlightened.

Anatomy of a git repo

Content Addressable Filesystem

1st level tree: snapshot file hierarchy

2nd level tree: snapshots ordered by time

References (pointers)

Content Addressable FS

Source

FilenameSHA1

ZIP(1) Contents

objects dir

(1) Some files are saved as a pointer to a base file, and a file delta to save space

Snapshot File Hierarchy

Note: Trees are saved as files in the Content Addressable FS

Snapshots ordered by time

References

Why is this important?

Some things become easier once you understand them: • Branches & Tags are just pointers, moving them

doesn’t affect the commit tree • You cannot destroy a commit, only misplace it • All versions of the file are stored in the filesystem,

regardless of commits & branches

Stage & Working Dir

Think of the stage as a floating commitThe only thing you can lose is what is in your WD

What does commit do?

What does checkout do?

What does reset do?

Inspecting the commit tree

A: $ git log --graph --oneline --decorate

A: $ git log --no-merges --oneline

Q: What’s in my tree?

Q: What commits don’t come from merges?

Q: What commits are on the release branch but not master? A: $ git log master..release-3.5 —online

or $git log release-3.5 --not master --oneline

Q: How do master & branch differ?A: $ git log --left-right master...release-3.5 --oneline

Time Travel$ git checkout @{10 minutes ago}

$ git show master @{one.month.ago}

$ git diff @{yesterday}

$ git whatchanged --since="2 weeks ago"

The RefLog

Bisect

$ git bisect start

$ git checkout <known-bad-commit>

$ git bisect bad

$ git bisect good <known-good-commit>

… git selects the next commit to test …… test the commit …

$ git bisect <good or bad>

Share some tips & tricks https://pebbletechnology.atlassian.net/wiki/pages/

viewpage.action?pageId=44925274