Introduction to Git
Download as ZIP, PDF2 likes3,077 views
If you've seen my "intro to Git" talk on Google Video, this is the slide deck from that, revised slightly.
![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]](https://image.slidesharecdn.com/gitv3-100528162357-phpapp02/85/Introduction-to-Git-321-320.jpg)
![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](https://image.slidesharecdn.com/gitv3-100528162357-phpapp02/85/Introduction-to-Git-322-320.jpg)
![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](https://image.slidesharecdn.com/gitv3-100528162357-phpapp02/85/Introduction-to-Git-323-320.jpg)
![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](https://image.slidesharecdn.com/gitv3-100528162357-phpapp02/85/Introduction-to-Git-324-320.jpg)
Ad
More Related Content
What's hot (20)
Viewers also liked (7)
Ad
Similar to Introduction to Git (20)
Ad
More from Randal Schwartz (7)
Recently uploaded (20)
Introduction to Git
- 1. Git: a brief introduction Randal Schwartz [email protected] 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
- 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
- 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!