If you've seen my "intro to Git" talk on Google Video, this is the slide deck from that, revised slightly.

1. Git: a brief introduction
Randal Schwartz
merlyn@stonehenge.com
http://www.stonehenge.com/merlyn/
Version 3.01 on 12-Jan-2010

2. Disclaimer

3. Disclaimer
● I've been tracking git since it was created

4. Disclaimer
● I've been tracking git since it was created
● I've used git on small projects

5. Disclaimer
● I've been tracking git since it was created
● I've used git on small projects
● I've used other systems on small and large
projects

6. Disclaimer
● I've been tracking git since it was created
● I've used git on small projects
● I've used other systems on small and large
projects
● I've read a lot of people talk about git on
the mailing list

7. Disclaimer
● I've been tracking git since it was created
● I've used git on small projects
● I've used other systems on small and large
projects
● I've read a lot of people talk about git on
the mailing list
● I've even provided some patches to git, and
suggestions for user interface changes

8. Disclaimer
● I've been tracking git since it was created
● I've used git on small projects
● I've used other systems on small and large
projects
● I've read a lot of people talk about git on
the mailing list
● I've even provided some patches to git, and
suggestions for user interface changes
● I have worked on small and medium teams
with git

9. Disclaimer
● I've been tracking git since it was created
● I've used git on small projects
● I've used other systems on small and large
projects
● I've read a lot of people talk about git on
the mailing list
● I've even provided some patches to git, and
suggestions for user interface changes
● I have worked on small and medium teams
with git
● But not large ones

10. What is git?

11. What is git?
● Git manages changes to a tree of files over
time

12. What is git?
● Git manages changes to a tree of files over
time
● Git is optimized for:

13. What is git?
● Git manages changes to a tree of files over
time
● Git is optimized for:
− Distributed development

14. What is git?
● Git manages changes to a tree of files over
time
● Git is optimized for:
− Distributed development
− Large file sets

15. What is git?
● Git manages changes to a tree of files over
time
● Git is optimized for:
− Distributed development
− Large file sets
− Complex merges

16. What is git?
● Git manages changes to a tree of files over
time
● Git is optimized for:
− Distributed development
− Large file sets
− Complex merges
− Making trial branches

17. What is git?
● Git manages changes to a tree of files over
time
● Git is optimized for:
− Distributed development
− Large file sets
− Complex merges
− Making trial branches
− Being very fast

18. What is git?
● Git manages changes to a tree of files over
time
● Git is optimized for:
− Distributed development
− Large file sets
− Complex merges
− Making trial branches
− Being very fast
− Being robust

19. What is git?
● Git manages changes to a tree of files over
time
● Git is optimized for:
− Distributed development
− Large file sets
− Complex merges
− Making trial branches
− Being very fast
− Being robust
● Git is not optimized for:

20. What is git?
● Git manages changes to a tree of files over
time
● Git is optimized for:
− Distributed development
− Large file sets
− Complex merges
− Making trial branches
− Being very fast
− Being robust
● Git is not optimized for:
− Tracking file permissions and ownership

21. What is git?
● Git manages changes to a tree of files over
time
● Git is optimized for:
− Distributed development
− Large file sets
− Complex merges
− Making trial branches
− Being very fast
− Being robust
● Git is not optimized for:
− Tracking file permissions and ownership
− Tracking individual files with separate history

22. What is git?
● Git manages changes to a tree of files over
time
● Git is optimized for:
− Distributed development
− Large file sets
− Complex merges
− Making trial branches
− Being very fast
− Being robust
● Git is not optimized for:
− Tracking file permissions and ownership
− Tracking individual files with separate history
− Making things painful

23. Why git?

24. Why git?
● Essential to Linux kernel development

25. Why git?
● Essential to Linux kernel development
● Created as a replacement when BitKeeper
suddenly became “unavailable”

26. Why git?
● Essential to Linux kernel development
● Created as a replacement when BitKeeper
suddenly became “unavailable”
● Everybody has a “commit bit”

27. Why git?
● Essential to Linux kernel development
● Created as a replacement when BitKeeper
suddenly became “unavailable”
● Everybody has a “commit bit”
● Anyone can:

28. Why git?
● Essential to Linux kernel development
● Created as a replacement when BitKeeper
suddenly became “unavailable”
● Everybody has a “commit bit”
● Anyone can:
− Clone the tree

29. Why git?
● Essential to Linux kernel development
● Created as a replacement when BitKeeper
suddenly became “unavailable”
● Everybody has a “commit bit”
● Anyone can:
− Clone the tree
− Make and test local changes

30. Why git?
● Essential to Linux kernel development
● Created as a replacement when BitKeeper
suddenly became “unavailable”
● Everybody has a “commit bit”
● Anyone can:
− Clone the tree
− Make and test local changes
− Submit the changes as patches via mail

31. Why git?
● Essential to Linux kernel development
● Created as a replacement when BitKeeper
suddenly became “unavailable”
● Everybody has a “commit bit”
● Anyone can:
− Clone the tree
− Make and test local changes
− Submit the changes as patches via mail
− OR submit them as a published repository

32. Why git?
● Essential to Linux kernel development
● Created as a replacement when BitKeeper
suddenly became “unavailable”
● Everybody has a “commit bit”
● Anyone can:
− Clone the tree
− Make and test local changes
− Submit the changes as patches via mail
− OR submit them as a published repository
− Track the upstream to revise if needed

33. Why git?
● Essential to Linux kernel development
● Created as a replacement when BitKeeper
suddenly became “unavailable”
● Everybody has a “commit bit”
● Anyone can:
− Clone the tree
− Make and test local changes
− Submit the changes as patches via mail
− OR submit them as a published repository
− Track the upstream to revise if needed
● Kernel.org is just a convenient public
watering hole

34. How does git do it?

35. How does git do it?
● Universal public identifiers

36. How does git do it?
● Universal public identifiers
− None of the SVK “my @245 is your @992”

37. How does git do it?
● Universal public identifiers
− None of the SVK “my @245 is your @992”
● Multi-protocol transport

38. How does git do it?
● Universal public identifiers
− None of the SVK “my @245 is your @992”
● Multi-protocol transport
− HTTP

39. How does git do it?
● Universal public identifiers
− None of the SVK “my @245 is your @992”
● Multi-protocol transport
− HTTP
− SSH

40. How does git do it?
● Universal public identifiers
− None of the SVK “my @245 is your @992”
● Multi-protocol transport
− HTTP
− SSH
− GIT

41. How does git do it?
● Universal public identifiers
− None of the SVK “my @245 is your @992”
● Multi-protocol transport
− HTTP
− SSH
− GIT
● Efficient object storage

42. How does git do it?
● Universal public identifiers
− None of the SVK “my @245 is your @992”
● Multi-protocol transport
− HTTP
− SSH
− GIT
● Efficient object storage
● Everyone has entire repo (disk is cheap)

43. How does git do it?
● Universal public identifiers
− None of the SVK “my @245 is your @992”
● Multi-protocol transport
− HTTP
− SSH
− GIT
● Efficient object storage
● Everyone has entire repo (disk is cheap)
● Easy branching and merging

44. How does git do it?
● Universal public identifiers
− None of the SVK “my @245 is your @992”
● Multi-protocol transport
− HTTP
− SSH
− GIT
● Efficient object storage
● Everyone has entire repo (disk is cheap)
● Easy branching and merging
− Common ancestors are computable

45. How does git do it?
● Universal public identifiers
− None of the SVK “my @245 is your @992”
● Multi-protocol transport
− HTTP
− SSH
− GIT
● Efficient object storage
● Everyone has entire repo (disk is cheap)
● Easy branching and merging
− Common ancestors are computable
● Patches (and repo updates) can be
transported or mailed

46. How does git do it?
● Universal public identifiers
− None of the SVK “my @245 is your @992”
● Multi-protocol transport
− HTTP
− SSH
− GIT
● Efficient object storage
● Everyone has entire repo (disk is cheap)
● Easy branching and merging
− Common ancestors are computable
● Patches (and repo updates) can be
transported or mailed
● Binary “patches” are supported

47. The SHA1 is King

48. The SHA1 is King
● Every “object” has a SHA1 to uniquely
identify it

49. The SHA1 is King
● Every “object” has a SHA1 to uniquely
identify it
● “objects” consist of:

50. The SHA1 is King
● Every “object” has a SHA1 to uniquely
identify it
● “objects” consist of:
− Blobs (the contents of a file)

51. The SHA1 is King
● Every “object” has a SHA1 to uniquely
identify it
● “objects” consist of:
− Blobs (the contents of a file)
− Trees (directories of blobs or other trees)

52. The SHA1 is King
● Every “object” has a SHA1 to uniquely
identify it
● “objects” consist of:
− Blobs (the contents of a file)
− Trees (directories of blobs or other trees)
− Commits:

53. The SHA1 is King
● Every “object” has a SHA1 to uniquely
identify it
● “objects” consist of:
− Blobs (the contents of a file)
− Trees (directories of blobs or other trees)
− Commits:
● A tree

54. The SHA1 is King
● Every “object” has a SHA1 to uniquely
identify it
● “objects” consist of:
− Blobs (the contents of a file)
− Trees (directories of blobs or other trees)
− Commits:
● A tree
● Plus zero or more parent commits

55. The SHA1 is King
● Every “object” has a SHA1 to uniquely
identify it
● “objects” consist of:
− Blobs (the contents of a file)
− Trees (directories of blobs or other trees)
− Commits:
● A tree
● Plus zero or more parent commits
● Plus a message about why

56. The SHA1 is King
● Every “object” has a SHA1 to uniquely
identify it
● “objects” consist of:
− Blobs (the contents of a file)
− Trees (directories of blobs or other trees)
− Commits:
● A tree
● Plus zero or more parent commits
● Plus a message about why
− Tags:

57. The SHA1 is King
● Every “object” has a SHA1 to uniquely
identify it
● “objects” consist of:
− Blobs (the contents of a file)
− Trees (directories of blobs or other trees)
− Commits:
● A tree
● Plus zero or more parent commits
● Plus a message about why
− Tags:
● An object (usually a commit)

58. The SHA1 is King
● Every “object” has a SHA1 to uniquely
identify it
● “objects” consist of:
− Blobs (the contents of a file)
− Trees (directories of blobs or other trees)
− Commits:
● A tree
● Plus zero or more parent commits
● Plus a message about why
− Tags:
● An object (usually a commit)
● Plus a subject

59. The SHA1 is King
● Every “object” has a SHA1 to uniquely
identify it
● “objects” consist of:
− Blobs (the contents of a file)
− Trees (directories of blobs or other trees)
− Commits:
● A tree
● Plus zero or more parent commits
● Plus a message about why
− Tags:
● An object (usually a commit)
● Plus a subject
● Plus an optional payload to sign it off

60. The SHA1 is King
● Every “object” has a SHA1 to uniquely
identify it
● “objects” consist of:
− Blobs (the contents of a file)
− Trees (directories of blobs or other trees)
− Commits:
● A tree
● Plus zero or more parent commits
● Plus a message about why
− Tags:
● An object (usually a commit)
● Plus a subject
● Plus an optional payload to sign it off
● Plus an optional gpg signature

61. Objects live in the repo

62. Objects live in the repo
● Git efficiently creates new objects

63. Objects live in the repo
● Git efficiently creates new objects
● Objects are generally added, not destroyed

64. Objects live in the repo
● Git efficiently creates new objects
● Objects are generally added, not destroyed
● Unreferenced objects (deleted branch,
added but not committed, etc) can be
garbage collected

65. Objects live in the repo
● Git efficiently creates new objects
● Objects are generally added, not destroyed
● Unreferenced objects (deleted branch,
added but not committed, etc) can be
garbage collected
● Objects start “loose”, but can be “packed”
for filesystem efficiency

66. Objects live in the repo
● Git efficiently creates new objects
● Objects are generally added, not destroyed
● Unreferenced objects (deleted branch,
added but not committed, etc) can be
garbage collected
● Objects start “loose”, but can be “packed”
for filesystem efficiency
● “Packs” often represent objects as deltas for
space efficiency

67. Objects live in the repo
● Git efficiently creates new objects
● Objects are generally added, not destroyed
● Unreferenced objects (deleted branch,
added but not committed, etc) can be
garbage collected
● Objects start “loose”, but can be “packed”
for filesystem efficiency
● “Packs” often represent objects as deltas for
space efficiency
● “Packs” are also created for transfer
between repositories

68. Commits rule the repo

69. Commits rule the repo
● One or more commits form the head of
object chains

70. Commits rule the repo
● One or more commits form the head of
object chains
● Typically one head called “master”

71. Commits rule the repo
● One or more commits form the head of
object chains
● Typically one head called “master”
● Others can be made at will (“branches”)

72. Commits rule the repo
● One or more commits form the head of
object chains
● Typically one head called “master”
● Others can be made at will (“branches”)
● All reachable repo objects are accessed
from these head commits

73. Commits rule the repo
● One or more commits form the head of
object chains
● Typically one head called “master”
● Others can be made at will (“branches”)
● All reachable repo objects are accessed
from these head commits
− Chase down the tree object to get to directories
and files as they existed at this commit time

74. Commits rule the repo
● One or more commits form the head of
object chains
● Typically one head called “master”
● Others can be made at will (“branches”)
● All reachable repo objects are accessed
from these head commits
− Chase down the tree object to get to directories
and files as they existed at this commit time
− Chase down the parent objects to get to earlier
commits and their respective trees

75. Commits rule the repo
● One or more commits form the head of
object chains
● Typically one head called “master”
● Others can be made at will (“branches”)
● All reachable repo objects are accessed
from these head commits
− Chase down the tree object to get to directories
and files as they existed at this commit time
− Chase down the parent objects to get to earlier
commits and their respective trees
● Usually one commit in the repo that has no
parent commit

76. Mapping objects to a file tree

77. Mapping objects to a file tree
● A “working tree” has a “.git” dir at the top
level

78. Mapping objects to a file tree
● A “working tree” has a “.git” dir at the top
level
● Unlike CVS, SVN: no pollution of deeper
directories (“grep -r” friendly)

79. Mapping objects to a file tree
● A “working tree” has a “.git” dir at the top
level
● Unlike CVS, SVN: no pollution of deeper
directories (“grep -r” friendly)
● The .git dir contains:

80. Mapping objects to a file tree
● A “working tree” has a “.git” dir at the top
level
● Unlike CVS, SVN: no pollution of deeper
directories (“grep -r” friendly)
● The .git dir contains:
− config – Configuration file (.ini style)

81. Mapping objects to a file tree
● A “working tree” has a “.git” dir at the top
level
● Unlike CVS, SVN: no pollution of deeper
directories (“grep -r” friendly)
● The .git dir contains:
− config – Configuration file (.ini style)
− objects/* – The object repository

82. Mapping objects to a file tree
● A “working tree” has a “.git” dir at the top
level
● Unlike CVS, SVN: no pollution of deeper
directories (“grep -r” friendly)
● The .git dir contains:
− config – Configuration file (.ini style)
− objects/* – The object repository
− refs/heads/* – branches (like “master”)

83. Mapping objects to a file tree
● A “working tree” has a “.git” dir at the top
level
● Unlike CVS, SVN: no pollution of deeper
directories (“grep -r” friendly)
● The .git dir contains:
− config – Configuration file (.ini style)
− objects/* – The object repository
− refs/heads/* – branches (like “master”)
− refs/tags/* - tags

84. Mapping objects to a file tree
● A “working tree” has a “.git” dir at the top
level
● Unlike CVS, SVN: no pollution of deeper
directories (“grep -r” friendly)
● The .git dir contains:
− config – Configuration file (.ini style)
− objects/* – The object repository
− refs/heads/* – branches (like “master”)
− refs/tags/* - tags
− logs/* - logs

85. Mapping objects to a file tree
● A “working tree” has a “.git” dir at the top
level
● Unlike CVS, SVN: no pollution of deeper
directories (“grep -r” friendly)
● The .git dir contains:
− config – Configuration file (.ini style)
− objects/* – The object repository
− refs/heads/* – branches (like “master”)
− refs/tags/* - tags
− logs/* - logs
− refs/remotes/* - tracking others

86. Mapping objects to a file tree
● A “working tree” has a “.git” dir at the top
level
● Unlike CVS, SVN: no pollution of deeper
directories (“grep -r” friendly)
● The .git dir contains:
− config – Configuration file (.ini style)
− objects/* – The object repository
− refs/heads/* – branches (like “master”)
− refs/tags/* - tags
− logs/* - logs
− refs/remotes/* - tracking others
− index – the “index cache” (described shortly)

87. Mapping objects to a file tree
● A “working tree” has a “.git” dir at the top
level
● Unlike CVS, SVN: no pollution of deeper
directories (“grep -r” friendly)
● The .git dir contains:
− config – Configuration file (.ini style)
− objects/* – The object repository
− refs/heads/* – branches (like “master”)
− refs/tags/* - tags
− logs/* - logs
− refs/remotes/* - tracking others
− index – the “index cache” (described shortly)
− HEAD – points to one of the branches (the
“current branch”, where commits go)

88. The index (or “cache”)

89. The index (or “cache”)
● A directory of blob objects

90. The index (or “cache”)
● A directory of blob objects
● Represents the “next commit”

91. The index (or “cache”)
● A directory of blob objects
● Represents the “next commit”
● “Add files” to put them in the index,
including current content

92. The index (or “cache”)
● A directory of blob objects
● Represents the “next commit”
● “Add files” to put them in the index,
including current content
● “Commit” takes the current index and
makes it a real commit object.

93. The index (or “cache”)
● A directory of blob objects
● Represents the “next commit”
● “Add files” to put them in the index,
including current content
● “Commit” takes the current index and
makes it a real commit object.
● Diff between HEAD and index:

94. The index (or “cache”)
● A directory of blob objects
● Represents the “next commit”
● “Add files” to put them in the index,
including current content
● “Commit” takes the current index and
makes it a real commit object.
● Diff between HEAD and index:
− changed things not yet committed

95. The index (or “cache”)
● A directory of blob objects
● Represents the “next commit”
● “Add files” to put them in the index,
including current content
● “Commit” takes the current index and
makes it a real commit object.
● Diff between HEAD and index:
− changed things not yet committed
● Diff between index and working dir:

96. The index (or “cache”)
● A directory of blob objects
● Represents the “next commit”
● “Add files” to put them in the index,
including current content
● “Commit” takes the current index and
makes it a real commit object.
● Diff between HEAD and index:
− changed things not yet committed
● Diff between index and working dir:
− changed things not yet added

97. The index (or “cache”)
● A directory of blob objects
● Represents the “next commit”
● “Add files” to put them in the index,
including current content
● “Commit” takes the current index and
makes it a real commit object.
● Diff between HEAD and index:
− changed things not yet committed
● Diff between index and working dir:
− changed things not yet added
− untracked things

98. The index (or “cache”)
● A directory of blob objects
● Represents the “next commit”
● “Add files” to put them in the index,
including current content
● “Commit” takes the current index and
makes it a real commit object.
● Diff between HEAD and index:
− changed things not yet committed
● Diff between index and working dir:
− changed things not yet added
− untracked things
● Index gets interesting during a merge

99. The great renaming
controversy

100. The great renaming
controversy
● Git doesn’t record explicit renaming

101. The great renaming
controversy
● Git doesn’t record explicit renaming
● Nor expect you to declare it

102. The great renaming
controversy
● Git doesn’t record explicit renaming
● Nor expect you to declare it
● Exact renaming can be determined by SHA1
comparisons

103. The great renaming
controversy
● Git doesn’t record explicit renaming
● Nor expect you to declare it
● Exact renaming can be determined by SHA1
comparisons
● Copy-paste-edits can be detected by ad-
hoc “similarity” rules for logs

104. The great renaming
controversy
● Git doesn’t record explicit renaming
● Nor expect you to declare it
● Exact renaming can be determined by SHA1
comparisons
● Copy-paste-edits can be detected by ad-
hoc “similarity” rules for logs
● In general the computer can find these far
easier than you can

105. The great renaming
controversy
● Git doesn’t record explicit renaming
● Nor expect you to declare it
● Exact renaming can be determined by SHA1
comparisons
● Copy-paste-edits can be detected by ad-
hoc “similarity” rules for logs
● In general the computer can find these far
easier than you can
● If you make it explicit, it will be wrong
sometimes

106. The great renaming
controversy
● Git doesn’t record explicit renaming
● Nor expect you to declare it
● Exact renaming can be determined by SHA1
comparisons
● Copy-paste-edits can be detected by ad-
hoc “similarity” rules for logs
● In general the computer can find these far
easier than you can
● If you make it explicit, it will be wrong
sometimes
● Being wrong breaks merges

107. The great renaming
controversy
● Git doesn’t record explicit renaming
● Nor expect you to declare it
● Exact renaming can be determined by SHA1
comparisons
● Copy-paste-edits can be detected by ad-
hoc “similarity” rules for logs
● In general the computer can find these far
easier than you can
● If you make it explicit, it will be wrong
sometimes
● Being wrong breaks merges
● Even being right will break some merges!

108. Git speaks and listens

109. Git speaks and listens
● Many protocols to transfer git data between
repositories

110. Git speaks and listens
● Many protocols to transfer git data between
repositories
− rsync, http, https, git, ssh, local files

111. Git speaks and listens
● Many protocols to transfer git data between
repositories
− rsync, http, https, git, ssh, local files
● In the core, git also has:

112. Git speaks and listens
● Many protocols to transfer git data between
repositories
− rsync, http, https, git, ssh, local files
● In the core, git also has:
− import/export with CVS

113. Git speaks and listens
● Many protocols to transfer git data between
repositories
− rsync, http, https, git, ssh, local files
● In the core, git also has:
− import/export with CVS
− import/export with SVN

114. Git speaks and listens
● Many protocols to transfer git data between
repositories
− rsync, http, https, git, ssh, local files
● In the core, git also has:
− import/export with CVS
− import/export with SVN
− import from Arch

115. Git speaks and listens
● Many protocols to transfer git data between
repositories
− rsync, http, https, git, ssh, local files
● In the core, git also has:
− import/export with CVS
− import/export with SVN
− import from Arch
● I use CVS/SVN import to have entire history
of a project at 30K feet

116. Git speaks and listens
● Many protocols to transfer git data between
repositories
− rsync, http, https, git, ssh, local files
● In the core, git also has:
− import/export with CVS
− import/export with SVN
− import from Arch
● I use CVS/SVN import to have entire history
of a project at 30K feet
● Third party solutions handle others

117. Git speaks and listens
● Many protocols to transfer git data between
repositories
− rsync, http, https, git, ssh, local files
● In the core, git also has:
− import/export with CVS
− import/export with SVN
− import from Arch
● I use CVS/SVN import to have entire history
of a project at 30K feet
● Third party solutions handle others
● Git core also includes cvs-server

118. Git speaks and listens
● Many protocols to transfer git data between
repositories
− rsync, http, https, git, ssh, local files
● In the core, git also has:
− import/export with CVS
− import/export with SVN
− import from Arch
● I use CVS/SVN import to have entire history
of a project at 30K feet
● Third party solutions handle others
● Git core also includes cvs-server
− A git repository can act like a CVS repository for
legacy clients or humans

119. Getting git

120. Getting git
● Get the latest “git-*.tar.gz” from http://
www.kernel.org/pub/software/scm/git/

121. Getting git
● Get the latest “git-*.tar.gz” from http://
www.kernel.org/pub/software/scm/git/
● RPMs and Debian packages also exist

122. Getting git
● Get the latest “git-*.tar.gz” from http://
www.kernel.org/pub/software/scm/git/
● RPMs and Debian packages also exist
● Once you’ve bootstrapped git, git-clone the
git-developer archive

123. Getting git
● Get the latest “git-*.tar.gz” from http://
www.kernel.org/pub/software/scm/git/
● RPMs and Debian packages also exist
● Once you’ve bootstrapped git, git-clone the
git-developer archive
− git-clone git://git.kernel.org/pub/scm/git/
git.git

124. Getting git
● Get the latest “git-*.tar.gz” from http://
www.kernel.org/pub/software/scm/git/
● RPMs and Debian packages also exist
● Once you’ve bootstrapped git, git-clone the
git-developer archive
− git-clone git://git.kernel.org/pub/scm/git/
git.git
● Rebuild once a week or so

125. Getting git
● Get the latest “git-*.tar.gz” from http://
www.kernel.org/pub/software/scm/git/
● RPMs and Debian packages also exist
● Once you’ve bootstrapped git, git-clone the
git-developer archive
− git-clone git://git.kernel.org/pub/scm/git/
git.git
● Rebuild once a week or so
● Maintenance releases are very stable

126. Getting git
● Get the latest “git-*.tar.gz” from http://
www.kernel.org/pub/software/scm/git/
● RPMs and Debian packages also exist
● Once you’ve bootstrapped git, git-clone the
git-developer archive
− git-clone git://git.kernel.org/pub/scm/git/
git.git
● Rebuild once a week or so
● Maintenance releases are very stable
● I install mine “prefix=/opt/git”, and add
/opt/git/bin to my PATH

127. Git commands

128. Git commands
● All git commands start with “git”

129. Git commands
● All git commands start with “git”
● “git MUMBLE-FOO bar” has also been
written as “git-MUMBLE-FOO bar”

130. Git commands
● All git commands start with “git”
● “git MUMBLE-FOO bar” has also been
written as “git-MUMBLE-FOO bar”
● This allows a single entry “git” to be added
to the /usr/local/bin path

131. Git commands
● All git commands start with “git”
● “git MUMBLE-FOO bar” has also been
written as “git-MUMBLE-FOO bar”
● This allows a single entry “git” to be added
to the /usr/local/bin path
● This works for internal calls as well

132. Git commands
● All git commands start with “git”
● “git MUMBLE-FOO bar” has also been
written as “git-MUMBLE-FOO bar”
● This allows a single entry “git” to be added
to the /usr/local/bin path
● This works for internal calls as well
● The manpages are still under “git-MUMBLE-
FOO”, so you have to know the convention
either way

133. Git commands
● All git commands start with “git”
● “git MUMBLE-FOO bar” has also been
written as “git-MUMBLE-FOO bar”
● This allows a single entry “git” to be added
to the /usr/local/bin path
● This works for internal calls as well
● The manpages are still under “git-MUMBLE-
FOO”, so you have to know the convention
either way
− Unless you use “git help MUMBLE-FOO”

134. Git commands
● All git commands start with “git”
● “git MUMBLE-FOO bar” has also been
written as “git-MUMBLE-FOO bar”
● This allows a single entry “git” to be added
to the /usr/local/bin path
● This works for internal calls as well
● The manpages are still under “git-MUMBLE-
FOO”, so you have to know the convention
either way
− Unless you use “git help MUMBLE-FOO”
− Or “git MUMBLE-FOO --help”

135. “The Internet is just a series
of tubes”

136. “The Internet is just a series
of tubes”
● Low-level git operations are called
“plumbing”

137. “The Internet is just a series
of tubes”
● Low-level git operations are called
“plumbing”
● Higher level actions are called “porcelain”

138. “The Internet is just a series
of tubes”
● Low-level git operations are called
“plumbing”
● Higher level actions are called “porcelain”
● The git distro includes git plumbing and git
porcelain (git-gui)

139. “The Internet is just a series
of tubes”
● Low-level git operations are called
“plumbing”
● Higher level actions are called “porcelain”
● The git distro includes git plumbing and git
porcelain (git-gui)
● We’ll stick with the git porcelain in the rest
of this talk, unless otherwise noted

140. “The Internet is just a series
of tubes”
● Low-level git operations are called
“plumbing”
● Higher level actions are called “porcelain”
● The git distro includes git plumbing and git
porcelain (git-gui)
● We’ll stick with the git porcelain in the rest
of this talk, unless otherwise noted
● Other porcelain exists:

141. “The Internet is just a series
of tubes”
● Low-level git operations are called
“plumbing”
● Higher level actions are called “porcelain”
● The git distro includes git plumbing and git
porcelain (git-gui)
● We’ll stick with the git porcelain in the rest
of this talk, unless otherwise noted
● Other porcelain exists:
− StGit (“stacked git”)

142. “The Internet is just a series
of tubes”
● Low-level git operations are called
“plumbing”
● Higher level actions are called “porcelain”
● The git distro includes git plumbing and git
porcelain (git-gui)
● We’ll stick with the git porcelain in the rest
of this talk, unless otherwise noted
● Other porcelain exists:
− StGit (“stacked git”)
− guilt

143. “The Internet is just a series
of tubes”
● Low-level git operations are called
“plumbing”
● Higher level actions are called “porcelain”
● The git distro includes git plumbing and git
porcelain (git-gui)
● We’ll stick with the git porcelain in the rest
of this talk, unless otherwise noted
● Other porcelain exists:
− StGit (“stacked git”)
− guilt
− tig (curses-based viewer)

144. “The Internet is just a series
of tubes”
● Low-level git operations are called
“plumbing”
● Higher level actions are called “porcelain”
● The git distro includes git plumbing and git
porcelain (git-gui)
● We’ll stick with the git porcelain in the rest
of this talk, unless otherwise noted
● Other porcelain exists:
− StGit (“stacked git”)
− guilt
− tig (curses-based viewer)
− qgit

145. Creating a repo

146. Creating a repo
● git-init

147. Creating a repo
● git-init
− Creates a .git in the current dir

148. Creating a repo
● git-init
− Creates a .git in the current dir
− Optional: edit .gitignore

149. Creating a repo
● git-init
− Creates a .git in the current dir
− Optional: edit .gitignore
− “git-add .” to add all files (except .git!)

150. Creating a repo
● git-init
− Creates a .git in the current dir
− Optional: edit .gitignore
− “git-add .” to add all files (except .git!)
− Then “git commit” for the initial commit

151. Creating a repo
● git-init
− Creates a .git in the current dir
− Optional: edit .gitignore
− “git-add .” to add all files (except .git!)
− Then “git commit” for the initial commit
− Creates a branch named “master”

152. Creating a repo
● git-init
− Creates a .git in the current dir
− Optional: edit .gitignore
− “git-add .” to add all files (except .git!)
− Then “git commit” for the initial commit
− Creates a branch named “master”
− HEAD points at “master”

153. Creating a repo
● git-init
− Creates a .git in the current dir
− Optional: edit .gitignore
− “git-add .” to add all files (except .git!)
− Then “git commit” for the initial commit
− Creates a branch named “master”
− HEAD points at “master”
● git-clone REMOTESPEC

154. Creating a repo
● git-init
− Creates a .git in the current dir
− Optional: edit .gitignore
− “git-add .” to add all files (except .git!)
− Then “git commit” for the initial commit
− Creates a branch named “master”
− HEAD points at “master”
● git-clone REMOTESPEC
− Creates a git repo from an existing repo

155. Creating a repo
● git-init
− Creates a .git in the current dir
− Optional: edit .gitignore
− “git-add .” to add all files (except .git!)
− Then “git commit” for the initial commit
− Creates a branch named “master”
− HEAD points at “master”
● git-clone REMOTESPEC
− Creates a git repo from an existing repo
− Generally creates a subdirectory

156. Creating a repo
● git-init
− Creates a .git in the current dir
− Optional: edit .gitignore
− “git-add .” to add all files (except .git!)
− Then “git commit” for the initial commit
− Creates a branch named “master”
− HEAD points at “master”
● git-clone REMOTESPEC
− Creates a git repo from an existing repo
− Generally creates a subdirectory
− Your workfiles and .git are in there

157. Creating a repo
● git-init
− Creates a .git in the current dir
− Optional: edit .gitignore
− “git-add .” to add all files (except .git!)
− Then “git commit” for the initial commit
− Creates a branch named “master”
− HEAD points at “master”
● git-clone REMOTESPEC
− Creates a git repo from an existing repo
− Generally creates a subdirectory
− Your workfiles and .git are in there
− All remote branches are “tracked”

158. Creating a repo
● git-init
− Creates a .git in the current dir
− Optional: edit .gitignore
− “git-add .” to add all files (except .git!)
− Then “git commit” for the initial commit
− Creates a branch named “master”
− HEAD points at “master”
● git-clone REMOTESPEC
− Creates a git repo from an existing repo
− Generally creates a subdirectory
− Your workfiles and .git are in there
− All remote branches are “tracked”
− Remote “HEAD” branch checked out as your
initial “master” branch as well

159. Think globally, work locally

160. Think globally, work locally
● Your work product is more commits

161. Think globally, work locally
● Your work product is more commits
● These are always on a “branch”

162. Think globally, work locally
● Your work product is more commits
● These are always on a “branch”
● A branch is just a named commit

163. Think globally, work locally
● Your work product is more commits
● These are always on a “branch”
● A branch is just a named commit
● When you commit, the former branch head
becomes the parent

164. Think globally, work locally
● Your work product is more commits
● These are always on a “branch”
● A branch is just a named commit
● When you commit, the former branch head
becomes the parent
● The branch head moves to be the new
commit

165. Think globally, work locally
● Your work product is more commits
● These are always on a “branch”
● A branch is just a named commit
● When you commit, the former branch head
becomes the parent
● The branch head moves to be the new
commit
● Thus, you’re creating a directed acyclic
graph, rooted in branch heads

166. Think globally, work locally
● Your work product is more commits
● These are always on a “branch”
● A branch is just a named commit
● When you commit, the former branch head
becomes the parent
● The branch head moves to be the new
commit
● Thus, you’re creating a directed acyclic
graph, rooted in branch heads
● A merge is just a commit with multiple
parents

167. Typical work flow

168. Typical work flow
● Edit edit edit

169. Typical work flow
● Edit edit edit
● git add files/you/have changed/now

170. Typical work flow
● Edit edit edit
● git add files/you/have changed/now
− This adds the files to the index

171. Typical work flow
● Edit edit edit
● git add files/you/have changed/now
− This adds the files to the index
− “git add .” for adding all interesting files

172. Typical work flow
● Edit edit edit
● git add files/you/have changed/now
− This adds the files to the index
− “git add .” for adding all interesting files
● git status

173. Typical work flow
● Edit edit edit
● git add files/you/have changed/now
− This adds the files to the index
− “git add .” for adding all interesting files
● git status
− Tells you differences between HEAD, index, and
working directory

174. Typical work flow
● Edit edit edit
● git add files/you/have changed/now
− This adds the files to the index
− “git add .” for adding all interesting files
● git status
− Tells you differences between HEAD, index, and
working directory
● When you’re ready to commit: git commit

175. Typical work flow
● Edit edit edit
● git add files/you/have changed/now
− This adds the files to the index
− “git add .” for adding all interesting files
● git status
− Tells you differences between HEAD, index, and
working directory
● When you’re ready to commit: git commit
− Popped into a text editor (or “-m msg”)

176. Typical work flow
● Edit edit edit
● git add files/you/have changed/now
− This adds the files to the index
− “git add .” for adding all interesting files
● git status
− Tells you differences between HEAD, index, and
working directory
● When you’re ready to commit: git commit
− Popped into a text editor (or “-m msg”)
− First text line used for “short logs”

177. Typical work flow
● Edit edit edit
● git add files/you/have changed/now
− This adds the files to the index
− “git add .” for adding all interesting files
● git status
− Tells you differences between HEAD, index, and
working directory
● When you’re ready to commit: git commit
− Popped into a text editor (or “-m msg”)
− First text line used for “short logs”
● Current branch is moved forward

178. Typical work flow
● Edit edit edit
● git add files/you/have changed/now
− This adds the files to the index
− “git add .” for adding all interesting files
● git status
− Tells you differences between HEAD, index, and
working directory
● When you’re ready to commit: git commit
− Popped into a text editor (or “-m msg”)
− First text line used for “short logs”
● Current branch is moved forward
● And you’re back to more editing

179. But which branch?

180. But which branch?
● Git encourages branching

181. But which branch?
● Git encourages branching
− A branch is just 41 text bytes!

182. But which branch?
● Git encourages branching
− A branch is just 41 text bytes!
● Typical work flow:

183. But which branch?
● Git encourages branching
− A branch is just 41 text bytes!
● Typical work flow:
− Think of something to do

184. But which branch?
● Git encourages branching
− A branch is just 41 text bytes!
● Typical work flow:
− Think of something to do
− git checkout -b topic-name master

185. But which branch?
● Git encourages branching
− A branch is just 41 text bytes!
● Typical work flow:
− Think of something to do
− git checkout -b topic-name master
− work work work, commit to topic-name

186. But which branch?
● Git encourages branching
− A branch is just 41 text bytes!
● Typical work flow:
− Think of something to do
− git checkout -b topic-name master
− work work work, commit to topic-name
● When your thing is done:

187. But which branch?
● Git encourages branching
− A branch is just 41 text bytes!
● Typical work flow:
− Think of something to do
− git checkout -b topic-name master
− work work work, commit to topic-name
● When your thing is done:
− git checkout master

188. But which branch?
● Git encourages branching
− A branch is just 41 text bytes!
● Typical work flow:
− Think of something to do
− git checkout -b topic-name master
− work work work, commit to topic-name
● When your thing is done:
− git checkout master
− git merge topic-name

189. But which branch?
● Git encourages branching
− A branch is just 41 text bytes!
● Typical work flow:
− Think of something to do
− git checkout -b topic-name master
− work work work, commit to topic-name
● When your thing is done:
− git checkout master
− git merge topic-name
− git branch -d topic-name

190. But which branch?
● Git encourages branching
− A branch is just 41 text bytes!
● Typical work flow:
− Think of something to do
− git checkout -b topic-name master
− work work work, commit to topic-name
● When your thing is done:
− git checkout master
− git merge topic-name
− git branch -d topic-name
● Permitted only when it’s a subset of HEAD

191. But which branch?
● Git encourages branching
− A branch is just 41 text bytes!
● Typical work flow:
− Think of something to do
− git checkout -b topic-name master
− work work work, commit to topic-name
● When your thing is done:
− git checkout master
− git merge topic-name
− git branch -d topic-name
● Permitted only when it’s a subset of HEAD
● Each individual commit is shown

192. But which branch?
● Git encourages branching
− A branch is just 41 text bytes!
● Typical work flow:
− Think of something to do
− git checkout -b topic-name master
− work work work, commit to topic-name
● When your thing is done:
− git checkout master
− git merge topic-name
− git branch -d topic-name
● Permitted only when it’s a subset of HEAD
● Each individual commit is shown
● For all work as a single commit:

193. But which branch?
● Git encourages branching
− A branch is just 41 text bytes!
● Typical work flow:
− Think of something to do
− git checkout -b topic-name master
− work work work, commit to topic-name
● When your thing is done:
− git checkout master
− git merge topic-name
− git branch -d topic-name
● Permitted only when it’s a subset of HEAD
● Each individual commit is shown
● For all work as a single commit:
− git merge --squash --no-commit t; git commit

194. Working in parallel

195. Working in parallel
● You can have multiple topics active:

196. Working in parallel
● You can have multiple topics active:
− git checkout -b topic1 master

197. Working in parallel
● You can have multiple topics active:
− git checkout -b topic1 master
− work work work; commit; work work; commit

198. Working in parallel
● You can have multiple topics active:
− git checkout -b topic1 master
− work work work; commit; work work; commit
− git checkout -b topic2 master

199. Working in parallel
● You can have multiple topics active:
− git checkout -b topic1 master
− work work work; commit; work work; commit
− git checkout -b topic2 master
− work work work; commit

200. Working in parallel
● You can have multiple topics active:
− git checkout -b topic1 master
− work work work; commit; work work; commit
− git checkout -b topic2 master
− work work work; commit
− git checkout topic1; work work; commit

201. Working in parallel
● You can have multiple topics active:
− git checkout -b topic1 master
− work work work; commit; work work; commit
− git checkout -b topic2 master
− work work work; commit
− git checkout topic1; work work; commit
● Decide how to bring them together

202. Working in parallel
● You can have multiple topics active:
− git checkout -b topic1 master
− work work work; commit; work work; commit
− git checkout -b topic2 master
− work work work; commit
− git checkout topic1; work work; commit
● Decide how to bring them together
● Merge: parallel histories

203. Working in parallel
● You can have multiple topics active:
− git checkout -b topic1 master
− work work work; commit; work work; commit
− git checkout -b topic2 master
− work work work; commit
− git checkout topic1; work work; commit
● Decide how to bring them together
● Merge: parallel histories
● Rebase: serial histories

204. Working in parallel
● You can have multiple topics active:
− git checkout -b topic1 master
− work work work; commit; work work; commit
− git checkout -b topic2 master
− work work work; commit
− git checkout topic1; work work; commit
● Decide how to bring them together
● Merge: parallel histories
● Rebase: serial histories
● Each has pros and cons

205. The merge

206. The merge
● git checkout master

207. The merge
● git checkout master
● git merge topic1; git branch -d topic1

208. The merge
● git checkout master
● git merge topic1; git branch -d topic1
− This should be trivial (“fast forward”) merge

209. The merge
● git checkout master
● git merge topic1; git branch -d topic1
− This should be trivial (“fast forward”) merge
● git merge topic2

210. The merge
● git checkout master
● git merge topic1; git branch -d topic1
− This should be trivial (“fast forward”) merge
● git merge topic2
● Conflicts may arise:

211. The merge
● git checkout master
● git merge topic1; git branch -d topic1
− This should be trivial (“fast forward”) merge
● git merge topic2
● Conflicts may arise:
− overlapping changes in text edits

212. The merge
● git checkout master
● git merge topic1; git branch -d topic1
− This should be trivial (“fast forward”) merge
● git merge topic2
● Conflicts may arise:
− overlapping changes in text edits
− files renamed two different ways

213. The merge
● git checkout master
● git merge topic1; git branch -d topic1
− This should be trivial (“fast forward”) merge
● git merge topic2
● Conflicts may arise:
− overlapping changes in text edits
− files renamed two different ways
● You need to resolve, and continue:

214. The merge
● git checkout master
● git merge topic1; git branch -d topic1
− This should be trivial (“fast forward”) merge
● git merge topic2
● Conflicts may arise:
− overlapping changes in text edits
− files renamed two different ways
● You need to resolve, and continue:
− git add any/thing/you fixed/now

215. The merge
● git checkout master
● git merge topic1; git branch -d topic1
− This should be trivial (“fast forward”) merge
● git merge topic2
● Conflicts may arise:
− overlapping changes in text edits
− files renamed two different ways
● You need to resolve, and continue:
− git add any/thing/you fixed/now
● or git add .

216. The merge
● git checkout master
● git merge topic1; git branch -d topic1
− This should be trivial (“fast forward”) merge
● git merge topic2
● Conflicts may arise:
− overlapping changes in text edits
− files renamed two different ways
● You need to resolve, and continue:
− git add any/thing/you fixed/now
● or git add .
− git commit (describe the merge here)

217. The merge
● git checkout master
● git merge topic1; git branch -d topic1
− This should be trivial (“fast forward”) merge
● git merge topic2
● Conflicts may arise:
− overlapping changes in text edits
− files renamed two different ways
● You need to resolve, and continue:
− git add any/thing/you fixed/now
● or git add .
− git commit (describe the merge here)
● You can also abort:

218. The merge
● git checkout master
● git merge topic1; git branch -d topic1
− This should be trivial (“fast forward”) merge
● git merge topic2
● Conflicts may arise:
− overlapping changes in text edits
− files renamed two different ways
● You need to resolve, and continue:
− git add any/thing/you fixed/now
● or git add .
− git commit (describe the merge here)
● You can also abort:
− git reset --hard HEAD

219. The rebase

220. The rebase
● Rewrites commits as if they started in a
different place

221. The rebase
● Rewrites commits as if they started in a
different place
● Breaks SHA1s: commits are lost!

222. The rebase
● Rewrites commits as if they started in a
different place
● Breaks SHA1s: commits are lost!
− Don’t rebase if you’ve published commits!

223. The rebase
● Rewrites commits as if they started in a
different place
● Breaks SHA1s: commits are lost!
− Don’t rebase if you’ve published commits!
● git rebase master topic2

224. The rebase
● Rewrites commits as if they started in a
different place
● Breaks SHA1s: commits are lost!
− Don’t rebase if you’ve published commits!
● git rebase master topic2
− All changes in topic2 but not in master are
rewritten as changes to the new master

225. The rebase
● Rewrites commits as if they started in a
different place
● Breaks SHA1s: commits are lost!
− Don’t rebase if you’ve published commits!
● git rebase master topic2
− All changes in topic2 but not in master are
rewritten as changes to the new master
● May result in merge conflicts:

226. The rebase
● Rewrites commits as if they started in a
different place
● Breaks SHA1s: commits are lost!
− Don’t rebase if you’ve published commits!
● git rebase master topic2
− All changes in topic2 but not in master are
rewritten as changes to the new master
● May result in merge conflicts:
− git rebase --continue or --abort or --skip

227. The rebase
● Rewrites commits as if they started in a
different place
● Breaks SHA1s: commits are lost!
− Don’t rebase if you’ve published commits!
● git rebase master topic2
− All changes in topic2 but not in master are
rewritten as changes to the new master
● May result in merge conflicts:
− git rebase --continue or --abort or --skip
● git rebase -i (interactive) is helpful

228. The rebase
● Rewrites commits as if they started in a
different place
● Breaks SHA1s: commits are lost!
− Don’t rebase if you’ve published commits!
● git rebase master topic2
− All changes in topic2 but not in master are
rewritten as changes to the new master
● May result in merge conflicts:
− git rebase --continue or --abort or --skip
● git rebase -i (interactive) is helpful
● When rebased, merge is a fast forward:

229. The rebase
● Rewrites commits as if they started in a
different place
● Breaks SHA1s: commits are lost!
− Don’t rebase if you’ve published commits!
● git rebase master topic2
− All changes in topic2 but not in master are
rewritten as changes to the new master
● May result in merge conflicts:
− git rebase --continue or --abort or --skip
● git rebase -i (interactive) is helpful
● When rebased, merge is a fast forward:
− git checkout master; git merge topic2

230. Read the history

231. Read the history
● git log

232. Read the history
● git log
− print the changes

233. Read the history
● git log
− print the changes
● git log -p

234. Read the history
● git log
− print the changes
● git log -p
− print the changes, including a diff between
revisions

235. Read the history
● git log
− print the changes
● git log -p
− print the changes, including a diff between
revisions
● git log --stat

236. Read the history
● git log
− print the changes
● git log -p
− print the changes, including a diff between
revisions
● git log --stat
− Summarize the changes with a diffstat

237. Read the history
● git log
− print the changes
● git log -p
− print the changes, including a diff between
revisions
● git log --stat
− Summarize the changes with a diffstat
● git log file1 file2 dir3

238. Read the history
● git log
− print the changes
● git log -p
− print the changes, including a diff between
revisions
● git log --stat
− Summarize the changes with a diffstat
● git log file1 file2 dir3
− Show changes only for listed files or subdirs

239. What’s the difference?

240. What’s the difference?
● git diff

241. What’s the difference?
● git diff
− Diff between index and working tree

242. What’s the difference?
● git diff
− Diff between index and working tree
− These are things you should “git add”

243. What’s the difference?
● git diff
− Diff between index and working tree
− These are things you should “git add”
− “git commit -a” will also make this list empty

244. What’s the difference?
● git diff
− Diff between index and working tree
− These are things you should “git add”
− “git commit -a” will also make this list empty
● git diff HEAD

245. What’s the difference?
● git diff
− Diff between index and working tree
− These are things you should “git add”
− “git commit -a” will also make this list empty
● git diff HEAD
− Difference between HEAD and working tree

246. What’s the difference?
● git diff
− Diff between index and working tree
− These are things you should “git add”
− “git commit -a” will also make this list empty
● git diff HEAD
− Difference between HEAD and working tree
− “git commit -a” will make this empty

247. What’s the difference?
● git diff
− Diff between index and working tree
− These are things you should “git add”
− “git commit -a” will also make this list empty
● git diff HEAD
− Difference between HEAD and working tree
− “git commit -a” will make this empty
● git diff --cached

248. What’s the difference?
● git diff
− Diff between index and working tree
− These are things you should “git add”
− “git commit -a” will also make this list empty
● git diff HEAD
− Difference between HEAD and working tree
− “git commit -a” will make this empty
● git diff --cached
− between HEAD and index

249. What’s the difference?
● git diff
− Diff between index and working tree
− These are things you should “git add”
− “git commit -a” will also make this list empty
● git diff HEAD
− Difference between HEAD and working tree
− “git commit -a” will make this empty
● git diff --cached
− between HEAD and index
− “git commit” (without -a) makes this empty

250. What’s the difference?
● git diff
− Diff between index and working tree
− These are things you should “git add”
− “git commit -a” will also make this list empty
● git diff HEAD
− Difference between HEAD and working tree
− “git commit -a” will make this empty
● git diff --cached
− between HEAD and index
− “git commit” (without -a) makes this empty
● git diff OTHERBRANCH

251. What’s the difference?
● git diff
− Diff between index and working tree
− These are things you should “git add”
− “git commit -a” will also make this list empty
● git diff HEAD
− Difference between HEAD and working tree
− “git commit -a” will make this empty
● git diff --cached
− between HEAD and index
− “git commit” (without -a) makes this empty
● git diff OTHERBRANCH
− Other branch and working tree

252. What’s the difference?
● git diff
− Diff between index and working tree
− These are things you should “git add”
− “git commit -a” will also make this list empty
● git diff HEAD
− Difference between HEAD and working tree
− “git commit -a” will make this empty
● git diff --cached
− between HEAD and index
− “git commit” (without -a) makes this empty
● git diff OTHERBRANCH
− Other branch and working tree
● git diff BRANCH1 BRANCH2

253. What’s the difference?
● git diff
− Diff between index and working tree
− These are things you should “git add”
− “git commit -a” will also make this list empty
● git diff HEAD
− Difference between HEAD and working tree
− “git commit -a” will make this empty
● git diff --cached
− between HEAD and index
− “git commit” (without -a) makes this empty
● git diff OTHERBRANCH
− Other branch and working tree
● git diff BRANCH1 BRANCH2
− Difference between two branch heads

254. Barking up the tree

255. Barking up the tree
● Most commands take “tree-ish” args

256. Barking up the tree
● Most commands take “tree-ish” args
● SHA1 picks something absolutely

257. Barking up the tree
● Most commands take “tree-ish” args
● SHA1 picks something absolutely
− Can be abbreviated if not ambiguous

258. Barking up the tree
● Most commands take “tree-ish” args
● SHA1 picks something absolutely
− Can be abbreviated if not ambiguous
● HEAD, some-branch-name, some-tag-
name, some-origin-name

259. Barking up the tree
● Most commands take “tree-ish” args
● SHA1 picks something absolutely
− Can be abbreviated if not ambiguous
● HEAD, some-branch-name, some-tag-
name, some-origin-name
● Any of those followed by:

260. Barking up the tree
● Most commands take “tree-ish” args
● SHA1 picks something absolutely
− Can be abbreviated if not ambiguous
● HEAD, some-branch-name, some-tag-
name, some-origin-name
● Any of those followed by:
− ^n - “the n-th parent of an item” (default 1)

261. Barking up the tree
● Most commands take “tree-ish” args
● SHA1 picks something absolutely
− Can be abbreviated if not ambiguous
● HEAD, some-branch-name, some-tag-
name, some-origin-name
● Any of those followed by:
− ^n - “the n-th parent of an item” (default 1)
− ~n - n ^1’s (so ~3 is ^1^1^1)

262. Barking up the tree
● Most commands take “tree-ish” args
● SHA1 picks something absolutely
− Can be abbreviated if not ambiguous
● HEAD, some-branch-name, some-tag-
name, some-origin-name
● Any of those followed by:
− ^n - “the n-th parent of an item” (default 1)
− ~n - n ^1’s (so ~3 is ^1^1^1)
− :path - pick the object from the tree

263. Barking up the tree
● Most commands take “tree-ish” args
● SHA1 picks something absolutely
− Can be abbreviated if not ambiguous
● HEAD, some-branch-name, some-tag-
name, some-origin-name
● Any of those followed by:
− ^n - “the n-th parent of an item” (default 1)
− ~n - n ^1’s (so ~3 is ^1^1^1)
− :path - pick the object from the tree
● Examples:

264. Barking up the tree
● Most commands take “tree-ish” args
● SHA1 picks something absolutely
− Can be abbreviated if not ambiguous
● HEAD, some-branch-name, some-tag-
name, some-origin-name
● Any of those followed by:
− ^n - “the n-th parent of an item” (default 1)
− ~n - n ^1’s (so ~3 is ^1^1^1)
− :path - pick the object from the tree
● Examples:
− git diff HEAD^ HEAD

265. Barking up the tree
● Most commands take “tree-ish” args
● SHA1 picks something absolutely
− Can be abbreviated if not ambiguous
● HEAD, some-branch-name, some-tag-
name, some-origin-name
● Any of those followed by:
− ^n - “the n-th parent of an item” (default 1)
− ~n - n ^1’s (so ~3 is ^1^1^1)
− :path - pick the object from the tree
● Examples:
− git diff HEAD^ HEAD
● most recent change on current branch

266. Barking up the tree
● Most commands take “tree-ish” args
● SHA1 picks something absolutely
− Can be abbreviated if not ambiguous
● HEAD, some-branch-name, some-tag-
name, some-origin-name
● Any of those followed by:
− ^n - “the n-th parent of an item” (default 1)
− ~n - n ^1’s (so ~3 is ^1^1^1)
− :path - pick the object from the tree
● Examples:
− git diff HEAD^ HEAD
● most recent change on current branch
− git diff HEAD~3 HEAD

267. Barking up the tree
● Most commands take “tree-ish” args
● SHA1 picks something absolutely
− Can be abbreviated if not ambiguous
● HEAD, some-branch-name, some-tag-
name, some-origin-name
● Any of those followed by:
− ^n - “the n-th parent of an item” (default 1)
− ~n - n ^1’s (so ~3 is ^1^1^1)
− :path - pick the object from the tree
● Examples:
− git diff HEAD^ HEAD
● most recent change on current branch
− git diff HEAD~3 HEAD
● What damage did last three edits do?

268. Seeing the changes side by
side

269. Seeing the changes side by
side
● gitk mytopic origin

270. Seeing the changes side by
side
● gitk mytopic origin
− Tk widget display of history

271. Seeing the changes side by
side
● gitk mytopic origin
− Tk widget display of history
− Shows changes back to common ancestor

272. Seeing the changes side by
side
● gitk mytopic origin
− Tk widget display of history
− Shows changes back to common ancestor
● gitk --all

273. Seeing the changes side by
side
● gitk mytopic origin
− Tk widget display of history
− Shows changes back to common ancestor
● gitk --all
− show everything

274. Seeing the changes side by
side
● gitk mytopic origin
− Tk widget display of history
− Shows changes back to common ancestor
● gitk --all
− show everything
● gitk from..to

275. Seeing the changes side by
side
● gitk mytopic origin
− Tk widget display of history
− Shows changes back to common ancestor
● gitk --all
− show everything
● gitk from..to
− Just the changes in “to” that aren’t in “from”

276. Seeing the changes side by
side
● gitk mytopic origin
− Tk widget display of history
− Shows changes back to common ancestor
● gitk --all
− show everything
● gitk from..to
− Just the changes in “to” that aren’t in “from”
● git show-branch mytopic...origin

277. Seeing the changes side by
side
● gitk mytopic origin
− Tk widget display of history
− Shows changes back to common ancestor
● gitk --all
− show everything
● gitk from..to
− Just the changes in “to” that aren’t in “from”
● git show-branch mytopic...origin
− Same thing for the Tk-challenged

278. Seeing the changes side by
side
● gitk mytopic origin
− Tk widget display of history
− Shows changes back to common ancestor
● gitk --all
− show everything
● gitk from..to
− Just the changes in “to” that aren’t in “from”
● git show-branch mytopic...origin
− Same thing for the Tk-challenged
● See also “qgit”

279. Playing well with others

280. Playing well with others
● git clone creates “tracking” or “remote”
branches

281. Playing well with others
● git clone creates “tracking” or “remote”
branches
● Typically named “origin/master” etc

282. Playing well with others
● git clone creates “tracking” or “remote”
branches
● Typically named “origin/master” etc
● To share your work, first get up to date:

283. Playing well with others
● git clone creates “tracking” or “remote”
branches
● Typically named “origin/master” etc
● To share your work, first get up to date:
− git fetch (defaults to branches of origin)

284. Playing well with others
● git clone creates “tracking” or “remote”
branches
● Typically named “origin/master” etc
● To share your work, first get up to date:
− git fetch (defaults to branches of origin)
● Now rebase your changes on upstream:

285. Playing well with others
● git clone creates “tracking” or “remote”
branches
● Typically named “origin/master” etc
● To share your work, first get up to date:
− git fetch (defaults to branches of origin)
● Now rebase your changes on upstream:
− git checkout master # or whatever branch

286. Playing well with others
● git clone creates “tracking” or “remote”
branches
● Typically named “origin/master” etc
● To share your work, first get up to date:
− git fetch (defaults to branches of origin)
● Now rebase your changes on upstream:
− git checkout master # or whatever branch
− git rebase origin/master

287. Playing well with others
● git clone creates “tracking” or “remote”
branches
● Typically named “origin/master” etc
● To share your work, first get up to date:
− git fetch (defaults to branches of origin)
● Now rebase your changes on upstream:
− git checkout master # or whatever branch
− git rebase origin/master
● Or fetch/rebase in one step

288. Playing well with others
● git clone creates “tracking” or “remote”
branches
● Typically named “origin/master” etc
● To share your work, first get up to date:
− git fetch (defaults to branches of origin)
● Now rebase your changes on upstream:
− git checkout master # or whatever branch
− git rebase origin/master
● Or fetch/rebase in one step
− git pull --rebase

289. Playing well with others
● git clone creates “tracking” or “remote”
branches
● Typically named “origin/master” etc
● To share your work, first get up to date:
− git fetch (defaults to branches of origin)
● Now rebase your changes on upstream:
− git checkout master # or whatever branch
− git rebase origin/master
● Or fetch/rebase in one step
− git pull --rebase
● To push upstream:

290. Playing well with others
● git clone creates “tracking” or “remote”
branches
● Typically named “origin/master” etc
● To share your work, first get up to date:
− git fetch (defaults to branches of origin)
● Now rebase your changes on upstream:
− git checkout master # or whatever branch
− git rebase origin/master
● Or fetch/rebase in one step
− git pull --rebase
● To push upstream:
− git push

291. Resetting

292. Resetting
● git reset --soft

293. Resetting
● git reset --soft
− Makes all files “updated but not checked in”

294. Resetting
● git reset --soft
− Makes all files “updated but not checked in”
● git reset --hard # DANGER

295. Resetting
● git reset --soft
− Makes all files “updated but not checked in”
● git reset --hard # DANGER
− Forces working dir to look like last commit

296. Resetting
● git reset --soft
− Makes all files “updated but not checked in”
● git reset --hard # DANGER
− Forces working dir to look like last commit
● git reset --hard HEAD~3

297. Resetting
● git reset --soft
− Makes all files “updated but not checked in”
● git reset --hard # DANGER
− Forces working dir to look like last commit
● git reset --hard HEAD~3
− Tosses most recent 3 commits, and updates the
work dir to match that

298. Resetting
● git reset --soft
− Makes all files “updated but not checked in”
● git reset --hard # DANGER
− Forces working dir to look like last commit
● git reset --hard HEAD~3
− Tosses most recent 3 commits, and updates the
work dir to match that
− Don’t do this if you’ve published: use git revert
instead

299. Resetting
● git reset --soft
− Makes all files “updated but not checked in”
● git reset --hard # DANGER
− Forces working dir to look like last commit
● git reset --hard HEAD~3
− Tosses most recent 3 commits, and updates the
work dir to match that
− Don’t do this if you’ve published: use git revert
instead
● git checkout HEAD some/lost/file

300. Resetting
● git reset --soft
− Makes all files “updated but not checked in”
● git reset --hard # DANGER
− Forces working dir to look like last commit
● git reset --hard HEAD~3
− Tosses most recent 3 commits, and updates the
work dir to match that
− Don’t do this if you’ve published: use git revert
instead
● git checkout HEAD some/lost/file
− Recover the version of some/lost/file from the
last commit

301. Pay no attention to the man
behind the curtain

302. Pay no attention to the man
behind the curtain
● Every directory can contain a .gitignore

303. Pay no attention to the man
behind the curtain
● Every directory can contain a .gitignore
− lines starting with “!” mean “not”

304. Pay no attention to the man
behind the curtain
● Every directory can contain a .gitignore
− lines starting with “!” mean “not”
− lines without “/” are checked against basename

305. Pay no attention to the man
behind the curtain
● Every directory can contain a .gitignore
− lines starting with “!” mean “not”
− lines without “/” are checked against basename
− otherwise, shell glob via fnmatch(3)

306. Pay no attention to the man
behind the curtain
● Every directory can contain a .gitignore
− lines starting with “!” mean “not”
− lines without “/” are checked against basename
− otherwise, shell glob via fnmatch(3)
− Leading / means “the current directory”

307. Pay no attention to the man
behind the curtain
● Every directory can contain a .gitignore
− lines starting with “!” mean “not”
− lines without “/” are checked against basename
− otherwise, shell glob via fnmatch(3)
− Leading / means “the current directory”
● Checked into the repository and tracked

308. Pay no attention to the man
behind the curtain
● Every directory can contain a .gitignore
− lines starting with “!” mean “not”
− lines without “/” are checked against basename
− otherwise, shell glob via fnmatch(3)
− Leading / means “the current directory”
● Checked into the repository and tracked
● Every repository can contain a .git/info/
exclude

309. Pay no attention to the man
behind the curtain
● Every directory can contain a .gitignore
− lines starting with “!” mean “not”
− lines without “/” are checked against basename
− otherwise, shell glob via fnmatch(3)
− Leading / means “the current directory”
● Checked into the repository and tracked
● Every repository can contain a .git/info/
exclude
● Both of these work together

310. Pay no attention to the man
behind the curtain
● Every directory can contain a .gitignore
− lines starting with “!” mean “not”
− lines without “/” are checked against basename
− otherwise, shell glob via fnmatch(3)
− Leading / means “the current directory”
● Checked into the repository and tracked
● Every repository can contain a .git/info/
exclude
● Both of these work together
● But .git/info/exclude won’t be cloned

311. Configuration

312. Configuration
● Many commands have configurations

313. Configuration
● Many commands have configurations
● git config name value

314. Configuration
● Many commands have configurations
● git config name value
− set name to value

315. Configuration
● Many commands have configurations
● git config name value
− set name to value
− name can contain periods for sub-items

316. Configuration
● Many commands have configurations
● git config name value
− set name to value
− name can contain periods for sub-items
− can edit manually if you’d prefer

317. Configuration
● Many commands have configurations
● git config name value
− set name to value
− name can contain periods for sub-items
− can edit manually if you’d prefer
● git config name

318. Configuration
● Many commands have configurations
● git config name value
− set name to value
− name can contain periods for sub-items
− can edit manually if you’d prefer
● git config name
− get current value

319. Configuration
● Many commands have configurations
● git config name value
− set name to value
− name can contain periods for sub-items
− can edit manually if you’d prefer
● git config name
− get current value
● git config -l

320. Configuration
● Many commands have configurations
● git config name value
− set name to value
− name can contain periods for sub-items
− can edit manually if you’d prefer
● git config name
− get current value
● git config -l
− get all values

321. Configuration
● Many commands have configurations
● git config name value
− set name to value
− name can contain periods for sub-items
− can edit manually if you’d prefer
● git config name
− get current value
● git config -l
− get all values
● git config --global name [value]

322. Configuration
● Many commands have configurations
● git config name value
− set name to value
− name can contain periods for sub-items
− can edit manually if you’d prefer
● git config name
− get current value
● git config -l
− get all values
● git config --global name [value]
− Same, but with ~/.gitconfig

323. Configuration
● Many commands have configurations
● git config name value
− set name to value
− name can contain periods for sub-items
− can edit manually if you’d prefer
● git config name
− get current value
● git config -l
− get all values
● git config --global name [value]
− Same, but with ~/.gitconfig
− This applies to all git repos from a user

324. Configuration
● Many commands have configurations
● git config name value
− set name to value
− name can contain periods for sub-items
− can edit manually if you’d prefer
● git config name
− get current value
● git config -l
− get all values
● git config --global name [value]
− Same, but with ~/.gitconfig
− This applies to all git repos from a user
● At a minimum, set user.email and
user.name for commits

325. Other useful porcelain

326. Other useful porcelain
● git archive: export a tree as a tar/zip

327. Other useful porcelain
● git archive: export a tree as a tar/zip
● git bisect: find the offensive commit

328. Other useful porcelain
● git archive: export a tree as a tar/zip
● git bisect: find the offensive commit
● git cherry-pick: selective merging

329. Other useful porcelain
● git archive: export a tree as a tar/zip
● git bisect: find the offensive commit
● git cherry-pick: selective merging
● git mv: rename a file/dir with the right
index manipulations

330. Other useful porcelain
● git archive: export a tree as a tar/zip
● git bisect: find the offensive commit
● git cherry-pick: selective merging
● git mv: rename a file/dir with the right
index manipulations
● git rm: ditto for delete

331. Other useful porcelain
● git archive: export a tree as a tar/zip
● git bisect: find the offensive commit
● git cherry-pick: selective merging
● git mv: rename a file/dir with the right
index manipulations
● git rm: ditto for delete
● git push: write to an upstream

332. Other useful porcelain
● git archive: export a tree as a tar/zip
● git bisect: find the offensive commit
● git cherry-pick: selective merging
● git mv: rename a file/dir with the right
index manipulations
● git rm: ditto for delete
● git push: write to an upstream
● git revert: add a commit that undoes a
previous commit

333. Other useful porcelain
● git archive: export a tree as a tar/zip
● git bisect: find the offensive commit
● git cherry-pick: selective merging
● git mv: rename a file/dir with the right
index manipulations
● git rm: ditto for delete
● git push: write to an upstream
● git revert: add a commit that undoes a
previous commit
● git blame: who wrote this?

334. For further info

335. For further info
● See “Git (software)” in Wikipedia

336. For further info
● See “Git (software)” in Wikipedia
● And the git homepage http://git.or.cz

337. For further info
● See “Git (software)” in Wikipedia
● And the git homepage http://git.or.cz
● Git wiki at http://git.or.cz/gitwiki

338. For further info
● See “Git (software)” in Wikipedia
● And the git homepage http://git.or.cz
● Git wiki at http://git.or.cz/gitwiki
● Get on the mailing list

339. For further info
● See “Git (software)” in Wikipedia
● And the git homepage http://git.or.cz
● Git wiki at http://git.or.cz/gitwiki
● Get on the mailing list
− Helpful people there

340. For further info
● See “Git (software)” in Wikipedia
● And the git homepage http://git.or.cz
● Git wiki at http://git.or.cz/gitwiki
● Get on the mailing list
− Helpful people there
− You can submit bugs, patches, ideas

341. For further info
● See “Git (software)” in Wikipedia
● And the git homepage http://git.or.cz
● Git wiki at http://git.or.cz/gitwiki
● Get on the mailing list
− Helpful people there
− You can submit bugs, patches, ideas
− Find out who else is using git