Introduction to Git

  • 4,471 views
Uploaded on

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

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

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
4,471
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
91
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide





















































































































































































































































































































































































































Transcript

  • 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
  • 342. 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 ● And the #git IRC channel (on Freenode)
  • 343. 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 ● And the #git IRC channel (on Freenode) ● Now “git” to it!