Git Basics: Climbing the Totem Pole
•Download as PPTX, PDF•
2 likes•1,951 views
A basic overview of the Git and GitHub workflow - intended for beginners, but could also be helpful for git users who are shaky on the fundamentals
Recommended
More Related Content
Viewers also liked
Viewers also liked (16)
Similar to Git Basics: Climbing the Totem Pole
Similar to Git Basics: Climbing the Totem Pole (20)
Recently uploaded
Recently uploaded (20)
Git Basics: Climbing the Totem Pole
- 1. Git Basics: Climbing the Totem Pole by Matthew Salerno Github: https://github.com/seldomatt Twitter:@seldomatt Linkedin: http://www.linkedin.com/pub/matthew-salerno/9/62b/584 © Matthew Salerno, 2012
- 2. Git vs. Github © Matthew Salerno, 2012
- 3. Git vs. Github GIT • Revision control and source code management system © Matthew Salerno, 2012
- 4. Git vs. Github GIT • Revision control and source code management system • Created by Linus Torvalds (Linux) in 2005 © Matthew Salerno, 2012
- 5. Git vs. Github GIT GITHUB • Revision control and source • Hosting service for software code management system projects that use Git • Created by Linus Torvalds (Linux) in 2005 © Matthew Salerno, 2012
- 6. Git vs. Github GIT GITHUB • Revision control and source • Hosting service for software code management system projects that use Git • Created by Linus Torvalds • Started in 2008, now 1m+ (Linux) in 2005 users © Matthew Salerno, 2012
- 7. Git vs. Github • GitHub – has a graphical user interface © Matthew Salerno, 2012
- 8. Git vs. Github • GitHub © Matthew Salerno, 2012
- 9. Git vs. Github • Git – run through the command line © Matthew Salerno, 2012
- 10. Git vs. Github • Git – run through the command line – Tracks changes to a file or directory by storing commits (versions) to a local repository © Matthew Salerno, 2012
- 11. Git vs. Github • Git – run through the command line – Tracks changes to a file or directory by storing commits (versions) to a local repository – Local changes can be pushed to remote repository (GitHub) © Matthew Salerno, 2012
- 12. Git vs. Github • Git – run through the command line – Tracks changes to a file or directory by storing commits (versions) to a local repository – Local changes can be pushed to remote repository (GitHub) – Fork/clone projects from remote repositories to local repos, and much more… © Matthew Salerno, 2012
- 13. Git vs. Github • Git © Matthew Salerno, 2012
- 14. Part of being a programmer is breaking down complexity into more manageable parts © Matthew Salerno, 2012
- 15. We’re going to try to swallow a manageable, bite-sized portion of Git. © Matthew Salerno, 2012
- 16. What We Will Cover • Init – creating a local repository © Matthew Salerno, 2012
- 17. What We Will Cover • Init – creating a local repository • Add – staging changes © Matthew Salerno, 2012
- 18. What We Will Cover • Init – creating a local repository • Add – staging changes • Commit – commit changes (saves a version) © Matthew Salerno, 2012
- 19. What We Will Cover • Init – creating a local repository • Add – staging changes • Commit – commit changes (saves a version) • Status/Log – see staged/unstaged changes, commit history © Matthew Salerno, 2012
- 20. What We Will Cover • Init – creating a local repository • Add – staging changes • Commit – commit changes (saves a version) • Status/Log – see staged/unstaged changes, commit history • Push – create a remote repo and push changes from local repo (GitHub) © Matthew Salerno, 2012
- 21. What We Will Cover • Init – creating a local repository • Add – staging changes • Commit – commit changes (saves a version) • Status/Log – see staged/unstaged changes, commit history • Push – create a remote repo and push changes from local repo (GitHub) • Fork/Clone – work on someone else’s project © Matthew Salerno, 2012
- 22. What We Won’t Cover • Installing Git © Matthew Salerno, 2012
- 23. What We Won’t Cover • Installing Git • Branching, merging, and a host of other operations that would be central to using git to manage professional projects © Matthew Salerno, 2012
- 24. GIT: BUILDING THE TOTEM POLE © Matthew Salerno, 2012
- 25. WORKING TREE © Matthew Salerno, 2012
- 26. WORKING TREE • Files and directories that the user alters in an editor or otherwise (example.rb, ‘rails_app’ directory) © Matthew Salerno, 2012
- 27. WORKING TREE • Files and directories that the user alters in an editor or otherwise (example.rb, ‘rails_app’ directory) • ACTIONS: – WRITE CODE – DELETE CODE – SAVE (LOCALLY) © Matthew Salerno, 2012
- 28. Local Repository © Matthew Salerno, 2012
- 29. Local Repository The local repository is where git stores versions, or commits, of your working tree © Matthew Salerno, 2012
- 30. Let’s create a local git repository • From the command line, navigate to our working tree directory © Matthew Salerno, 2012
- 31. Let’s create a local git repository • From the command line, navigate to our working tree directory • Run ‘git init’ command /working tree $ git init . © Matthew Salerno, 2012
- 32. Working Tree © Matthew Salerno, 2012
- 33. Local Repository Working Tree © Matthew Salerno, 2012
- 34. Local Repository What’s Missing? Working Tree © Matthew Salerno, 2012
- 35. Index/Staging Area © Matthew Salerno, 2012
- 36. Index/Staging Area Index is a collection of changes to the working tree waiting to be saved to the repository as a commit © Matthew Salerno, 2012
- 37. Index/Staging Area Index is a collection of changes to the working tree waiting to be saved to the repository as a commit (the On-Deck circle of working tree changes) © Matthew Salerno, 2012
- 38. Index/Staging Area When we make changes to the working tree, we add them to the index(staging area) with the ‘git add’ command © Matthew Salerno, 2012
- 39. Git Add • Make some changes to the working tree © Matthew Salerno, 2012
- 40. Git Add • Make some changes to the working tree • /working tree $ git add . © Matthew Salerno, 2012
- 41. Git Add Our index is now a snapshot of our working tree in it’s current state © Matthew Salerno, 2012
- 42. Git Add We can keep ‘git add’-ing changes to update the index © Matthew Salerno, 2012
- 43. Git Add • Added changes are ‘staged’. Changes to the working tree that have not been added to the index are ‘unstaged’ © Matthew Salerno, 2012
- 44. Git Add • Added changes are ‘staged’. Changes to the working tree that have not been added to the index are ‘unstaged’ • $ git status will show us what changes have been staged and which have not © Matthew Salerno, 2012
- 45. Eventually, we’ll come to a point where we want to save a version of our working tree in it’s current state. © Matthew Salerno, 2012
- 46. COMMIT © Matthew Salerno, 2012
- 47. COMMIT • A commit is a saved version (snapshot) of the working tree © Matthew Salerno, 2012
- 48. COMMIT • A commit is a saved version (snapshot) of the working tree • when git commit is executed, all ‘staged changes’, i.e. the current index, are saved to the local repo. © Matthew Salerno, 2012
- 49. COMMIT • A commit is a saved version (snapshot) of the working tree • when git commit is executed, all ‘staged changes’, i.e. the current index, are saved to the local repo. • the index is then cleared out, making room for future changes to be staged and saved to the local repo as future commits © Matthew Salerno, 2012
- 50. COMMIT • $ git status . to make sure all changes are staged © Matthew Salerno, 2012
- 51. COMMIT • $ git status . to make sure all changes are staged • $ git commit –m ‘commit message’ © Matthew Salerno, 2012
- 52. COMMIT If we leave off the –m tag, git will open VIM, PICO, or whatever editor it can find in our bash settings to enter a commit message © Matthew Salerno, 2012
- 53. COMMIT If we leave off the –m tag, git will open VIM, PICO, or whatever editor it can find in our bash settings to enter a commit message Don’t forget the –m tag! © Matthew Salerno, 2012
- 54. COMMIT • git commit records the snapshot(index) of all staged content to the local repository © Matthew Salerno, 2012
- 55. COMMIT • git commit records the snapshot(index) of all staged content to the local repository • Each commit is uniquely identified © Matthew Salerno, 2012
- 56. COMMIT • git commit records the snapshot(index) of all staged content to the local repository • Each commit is uniquely identified • The commit can now be compared, shared, or reverted to if necessary © Matthew Salerno, 2012
- 57. RECAP © Matthew Salerno, 2012
- 58. RECAP Working Tree • Write, Delete, Save • Local Drive © Matthew Salerno, 2012
- 59. RECAP Index • Snapshot of the working tree • $ git add stages by updating the index Working Tree • Write, Delete, Save • Local Drive © Matthew Salerno, 2012
- 60. RECAP Local Repository • Local repository stores commits (versions) of the working tree • $ git commit saves all staged changes (index) to local repo Index • Snapshot of the working tree • $ git add stages by updating the index Working Tree • Write, Delete, Save • Local Drive © Matthew Salerno, 2012
- 61. Now we want to share with the world… © Matthew Salerno, 2012
- 62. Remote Repo © Matthew Salerno, 2012
- 63. Remote Repo Step #1 – Create a remote repository © Matthew Salerno, 2012
- 64. Remote Repo Github will give you a URL for that repository, i.e. git@github.com:username/reponame.git © Matthew Salerno, 2012
- 65. Remote Repo Step #2 – synchronize between local and remote repo © Matthew Salerno, 2012
- 66. Remote Repo • $ git remote add © Matthew Salerno, 2012
- 67. Remote Repo • $ git remote add – Allows us to set up an alias for our remote repo © Matthew Salerno, 2012
- 68. Remote Repo • $ git remote add – Allows us to set up an alias for our remote repo – $ git remote add [alias] git@github.com:[username]/[reponame].git © Matthew Salerno, 2012
- 69. PUSH! Step #3 – push commits from local repo to remote repo © Matthew Salerno, 2012
- 70. PUSH! • $ git push [alias] [branch] © Matthew Salerno, 2012
- 71. PUSH! • $ git push [alias] [branch] – We’ll use master as our branch, but you could push from any number of branches © Matthew Salerno, 2012
- 72. PUSH! • $ git push [alias] [branch] – We’ll use master as our branch, but you could push from any number of branches – $ git push basic master © Matthew Salerno, 2012
- 73. PUSH! We’ve now successfully pushed our commit from the local repo to the remote repo. © Matthew Salerno, 2012
- 74. PUSH! We’ve now successfully pushed our commit from the local repo to the remote repo. © Matthew Salerno, 2012
- 75. What if we want to work on someone else’s code? © Matthew Salerno, 2012
- 76. FORK/CLONE © Matthew Salerno, 2012
- 77. FORK © Matthew Salerno, 2012
- 78. FORK In forking someone’s else’s project repo, you are creating a new remote repository with identical contents… © Matthew Salerno, 2012
- 79. FORK …but a forked repo only exists on github. To work on the project, we need to clone the repo to our local machine… © Matthew Salerno, 2012
- 80. CLONE © Matthew Salerno, 2012
- 81. CLONE $ git clone https://github.com/username/reponame.git © Matthew Salerno, 2012
- 82. CLONE Now we can interact with the cloned repo as we would any other (adding, commiting, pushing) © Matthew Salerno, 2012
- 83. CLONE We can also configure remote aliases pointing to the original forked repo to keep track of updates to the original project, pull from the original repo, merge with our own files, etc. © Matthew Salerno, 2012
- 84. THE TOTEM POLE IS COMPLETE… CONCLUSION/RESOURCES © Matthew Salerno, 2012
- 85. BASIC WORKFLOW © Matthew Salerno, 2012
- 86. BASIC WORKFLOW • Creating a local repo (init) © Matthew Salerno, 2012
- 87. BASIC WORKFLOW • Creating a local repo (init) • Snapshotting (add) © Matthew Salerno, 2012
- 88. BASIC WORKFLOW • Creating a local repo (init) • Snapshotting (add) • Commits (commit) © Matthew Salerno, 2012
- 89. BASIC WORKFLOW • Creating a local repo (init) • Snapshotting (add) • Commits (commit) • Remote repo (remote add, push) © Matthew Salerno, 2012
- 90. BASIC WORKFLOW • Creating a local repo (init) • Snapshotting (add) • Commits (commit) • Remote repo (remote add, push) • Interaction (fork, clone) © Matthew Salerno, 2012
- 91. THERE’S MUCH, MUCH MORE • Resources – GitHub • http://help.github.com – GitReference • http://gitref.org – Code School – Try Git • http://try.github.com © Matthew Salerno, 2012
- 92. GOOD LUCK! © Matthew Salerno, 2012
Editor's Notes
- Insert drawings of a happy coder and a not so happy coder
- Insert graphic of happy coder
- Insert drawings of a happy coder and a not so happy coder
- Insert drawings of a happy coder and a not so happy coder
- Insert drawings of a happy coder and a not so happy coder
- Insert drawings of a happy coder and a not so happy coder
- Insert graphic of unhappy coder
- Picture of hands cutting a big steak with ‘Git’ written on it into a small piece.
- An understanding of basic operations, a starting point for a continuous education in using git on personal and professional projects
- This system works well, but obviously if we want to track revisions, save our working tree at various points in time, it’s insufficient. So let’s create a local git repository where we can store all of the versions (commits) of our code.
- This system works well, but obviously if we want to track revisions, save our working tree at various points in time, it’s insufficient. So let’s create a local git repository where we can store all of the versions (commits) of our code.
- This system works well, but obviously if we want to track revisions, save our working tree at various points in time, it’s insufficient. So let’s create a local git repository where we can store all of the versions (commits) of our code.
- Now we have a local git repository to store our commits (versions).
- Now we have a local git repository to store our commits (versions).
- Now we have a local git repository to store our commits (versions).
- Now we have a local git repository to store our commits (versions).
- Insert working tree totem
- Insert working tree totem
- Insert working tree totem
- Add a graphic with the totem pole completed
- Add a graphic with the totem pole completed
- Add a graphic with the totem pole completed
- Add graphic with new piece on the totem pole
- Add graphic with new piece on the totem pole
- Add graphic with new piece on the totem pole
- Add graphic with new piece on the totem pole
- Add graphic with new piece on the totem pole
- Add graphic with new piece on the totem pole
- Add graphic with new piece on the totem pole
- Add graphic with new piece on the totem pole
- Add graphic with new piece on the totem pole
- Add graphic with new piece on the totem pole
- Add graphics building the totem pole from working tree, to staging area, to commit (with actions, i.e. change/save, git add, git status, git commit –m)
- Add graphics building the totem pole from working tree, to staging area, to commit (with actions, i.e. change/save, git add, git status, git commit –m)
- Add graphics building the totem pole from working tree, to staging area, to commit (with actions, i.e. change/save, git add, git status, git commit –m)
- Add graphics building the totem pole from working tree, to staging area, to commit (with actions, i.e. change/save, git add, git status, git commit –m)
- Graphic?
- Add screenhot
- Add screenhot
- Add screenhot
- Mention that can run $git remote, which will show aliases we’ve set up. $ git remote –v will show urls those aliases point to
- Mention that can run $git remote, which will show aliases we’ve set up. $ git remote –v will show urls those aliases point to
- Mention that can run $git remote, which will show aliases we’ve set up. $ git remote –v will show urls those aliases point to
- Mention that can run $git remote, which will show aliases we’ve set up. $ git remote –v will show urls those aliases point to
- Insert graphic of fork and clone
- Insert screenshot
- Insert screenshot
- Insert screenshot
- Insert screenshot
- Insert screenshot
- Insert screenshot
- Insert screenshot
- Add octocat logo