Git Basics: Climbing the Totem Pole

2,103 views

Published on

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

Published in: Technology
1 Comment
1 Like
Statistics
Notes
No Downloads
Views
Total views
2,103
On SlideShare
0
From Embeds
0
Number of Embeds
244
Actions
Shares
0
Downloads
7
Comments
1
Likes
1
Embeds 0
No embeds

No notes for slide
  • 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
  • Git Basics: Climbing the Totem Pole

    1. 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. 2. Git vs. Github © Matthew Salerno, 2012
    3. 3. Git vs. GithubGIT• Revision control and source code management system © Matthew Salerno, 2012
    4. 4. Git vs. GithubGIT• Revision control and source code management system• Created by Linus Torvalds (Linux) in 2005 © Matthew Salerno, 2012
    5. 5. Git vs. GithubGIT 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. 6. Git vs. GithubGIT 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. 7. Git vs. Github• GitHub – has a graphical user interface © Matthew Salerno, 2012
    8. 8. Git vs. Github• GitHub © Matthew Salerno, 2012
    9. 9. Git vs. Github• Git – run through the command line © Matthew Salerno, 2012
    10. 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. 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. 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. 13. Git vs. Github• Git © Matthew Salerno, 2012
    14. 14. Part of being a programmer isbreaking down complexity into more manageable parts © Matthew Salerno, 2012
    15. 15. We’re going to try to swallow amanageable, bite-sized portion of Git. © Matthew Salerno, 2012
    16. 16. What We Will Cover• Init – creating a local repository © Matthew Salerno, 2012
    17. 17. What We Will Cover• Init – creating a local repository• Add – staging changes © Matthew Salerno, 2012
    18. 18. What We Will Cover• Init – creating a local repository• Add – staging changes• Commit – commit changes (saves a version) © Matthew Salerno, 2012
    19. 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. 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. 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. 22. What We Won’t Cover• Installing Git © Matthew Salerno, 2012
    23. 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. 24. GIT: BUILDING THETOTEM POLE © Matthew Salerno, 2012
    25. 25. WORKING TREE © Matthew Salerno, 2012
    26. 26. WORKING TREE• Files and directories that the user alters in an editor or otherwise (example.rb, ‘rails_app’ directory) © Matthew Salerno, 2012
    27. 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. 28. Local Repository © Matthew Salerno, 2012
    29. 29. Local RepositoryThe local repository is where git stores versions, or commits, of your working tree © Matthew Salerno, 2012
    30. 30. Let’s create a local git repository• From the command line, navigate to our working tree directory © Matthew Salerno, 2012
    31. 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. 32. Working Tree© Matthew Salerno, 2012
    33. 33. Local Repository Working Tree© Matthew Salerno, 2012
    34. 34. Local RepositoryWhat’s Missing?  Working Tree © Matthew Salerno, 2012
    35. 35. Index/Staging Area © Matthew Salerno, 2012
    36. 36. Index/Staging AreaIndex is a collection of changes to the workingtree waiting to be saved to the repository as a commit © Matthew Salerno, 2012
    37. 37. Index/Staging AreaIndex is a collection of changes to the workingtree waiting to be saved to the repository as a commit (the On-Deck circle of working tree changes) © Matthew Salerno, 2012
    38. 38. Index/Staging AreaWhen we make changes to the working tree, weadd them to the index(staging area) with the ‘git add’ command © Matthew Salerno, 2012
    39. 39. Git Add• Make some changes to the working tree © Matthew Salerno, 2012
    40. 40. Git Add• Make some changes to the working tree• /working tree $ git add . © Matthew Salerno, 2012
    41. 41. Git AddOur index is now a snapshot of our working tree in it’s current state © Matthew Salerno, 2012
    42. 42. Git AddWe can keep ‘git add’-ing changes to update the index © Matthew Salerno, 2012
    43. 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. 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. 45. Eventually, we’ll come to a point where wewant to save a version of our working tree in it’s current state. © Matthew Salerno, 2012
    46. 46. COMMIT© Matthew Salerno, 2012
    47. 47. COMMIT• A commit is a saved version (snapshot) of the working tree © Matthew Salerno, 2012
    48. 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. 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. 50. COMMIT• $ git status . to make sure all changes are staged © Matthew Salerno, 2012
    51. 51. COMMIT• $ git status . to make sure all changes are staged• $ git commit –m ‘commit message’ © Matthew Salerno, 2012
    52. 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. 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. 54. COMMIT• git commit records the snapshot(index) of all staged content to the local repository © Matthew Salerno, 2012
    55. 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. 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. 57. RECAP© Matthew Salerno, 2012
    58. 58. RECAP Working Tree • Write, Delete, Save • Local Drive© Matthew Salerno, 2012
    59. 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. 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. 61. Now we want to share with theworld… © Matthew Salerno, 2012
    62. 62. Remote Repo © Matthew Salerno, 2012
    63. 63. Remote RepoStep #1 – Create a remote repository © Matthew Salerno, 2012
    64. 64. Remote RepoGithub will give you a URL for that repository, i.e. git@github.com:username/reponame.git © Matthew Salerno, 2012
    65. 65. Remote RepoStep #2 – synchronize between local and remote repo © Matthew Salerno, 2012
    66. 66. Remote Repo• $ git remote add © Matthew Salerno, 2012
    67. 67. Remote Repo• $ git remote add – Allows us to set up an alias for our remote repo © Matthew Salerno, 2012
    68. 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. 69. PUSH!Step #3 – push commits from local repo to remote repo © Matthew Salerno, 2012
    70. 70. PUSH!• $ git push [alias] [branch] © Matthew Salerno, 2012
    71. 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. 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. 73. PUSH!We’ve now successfully pushed our commit fromthe local repo to the remote repo. © Matthew Salerno, 2012
    74. 74. PUSH!We’ve now successfully pushed our commit fromthe local repo to the remote repo. © Matthew Salerno, 2012
    75. 75. What if we want to work on someone else’s code? © Matthew Salerno, 2012
    76. 76. FORK/CLONE © Matthew Salerno, 2012
    77. 77. FORK© Matthew Salerno, 2012
    78. 78. FORKIn forking someone’s else’s project repo, you are creating a new remote repository with identical contents… © Matthew Salerno, 2012
    79. 79. FORK …but a forked repo only exists on github. Towork on the project, we need to clone the repo to our local machine… © Matthew Salerno, 2012
    80. 80. CLONE© Matthew Salerno, 2012
    81. 81. CLONE$ git clonehttps://github.com/username/reponame.git © Matthew Salerno, 2012
    82. 82. CLONENow we can interact with the cloned repo as we would any other (adding, commiting, pushing) © Matthew Salerno, 2012
    83. 83. CLONEWe can also configure remote aliases pointing tothe 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. 84. THE TOTEM POLE IS COMPLETE…CONCLUSION/RESOURCES © Matthew Salerno, 2012
    85. 85. BASIC WORKFLOW © Matthew Salerno, 2012
    86. 86. BASIC WORKFLOW• Creating a local repo (init) © Matthew Salerno, 2012
    87. 87. BASIC WORKFLOW• Creating a local repo (init)• Snapshotting (add) © Matthew Salerno, 2012
    88. 88. BASIC WORKFLOW• Creating a local repo (init)• Snapshotting (add)• Commits (commit) © Matthew Salerno, 2012
    89. 89. BASIC WORKFLOW• Creating a local repo (init)• Snapshotting (add)• Commits (commit)• Remote repo (remote add, push) © Matthew Salerno, 2012
    90. 90. BASIC WORKFLOW• Creating a local repo (init)• Snapshotting (add)• Commits (commit)• Remote repo (remote add, push)• Interaction (fork, clone) © Matthew Salerno, 2012
    91. 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. 92. GOOD LUCK! © Matthew Salerno, 2012

    ×