Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Git: Everything You Need To Know (And A Few More Things)

224884ff0b79e700e516e24fbcae6423?s=47 Nathan Kleyn
September 26, 2013

Git: Everything You Need To Know (And A Few More Things)

Learn about the basics of Git, from the internals to commands you'll need every day. Some pro tips and tricks are also covered so you can have some "mad skillz" people will be jealous of!

224884ff0b79e700e516e24fbcae6423?s=128

Nathan Kleyn

September 26, 2013
Tweet

Transcript

  1. None
  2. (And How Does It Work?) What Is It?

  3. Git Is Different

  4. 1. Uses tree snapshots instead of per file history. 2.

    Stores everything locally. 3. Is distributed. 4. Is really, really fast for a VCS. 5. Makes branching easy. 6. Is cryptographically secure. Git Is Different
  5. Basics

  6. The Repository When you run git init or are inside

    a directory created with git clone, you are inside a “repository” (or “repo” for short)
  7. The Repository You can tell when something is a Git

    repo by checking for the presence of the hidden “.git” folder.
  8. The Repository Everything you do in a repository is tracked

    by Git.
  9. None
  10. The Three States There are three states in Git: ◦

    Unstaged ◦ Staged ◦ Commited
  11. The Three States When you want to make your changes

    public, you first “stage” these changes, then you “commit” them.
  12. The Three States Imagine a car factory: ◦ Unstaged: Each

    individual part for a car is still being worked on. ◦ Staged: The parts are moved to a single place, ready to make a car. ◦ Committed: The built car, ready to roll out of the factory.
  13. The Three States If you make lots of changes to

    files, these start off unstaged.
  14. The Three States You can select only the bits you

    want to add to your staging area.
  15. The Three States The contents of your staging area become

    the contents of your commit.
  16. A Commit A commit is stored as the difference between

    the previous version and the version now, so it’s very small.
  17. A Commit Each commit has an associated SHA, called the

    “ref” or “commit SHA”. It looks like 6b36910b0e33d0f49bcc9a9fa66dbc5ec3f 2d0e1.
  18. A Commit Git generates the SHA of a commit using

    the contents of the commit being made and the SHA of the parent commit.
  19. A Commit The SHA for one commit depends on its

    parent, and it depends on its parent, and so on all the way back to the root. If any change is made, the SHA will change.
  20. A Commit This is Git’s cryptographically strong promise to you

    that nobody has tampered with any of your code.
  21. Branches Git makes branching really easy.

  22. Branches By convention, the main branch of a repository is

    called master.
  23. Branches Most branches will branch off master.

  24. Branches You normally create one branch per feature.

  25. Branches You can create branches just to experiment with things.

    You can throw them away afterwards by switching to another branch and running git branch -D <name>.
  26. Branching git branch <name> creates a branch based on the

    current commit you are on.
  27. Branching git checkout <name> switches to a branch.

  28. Branching git checkout -b <name> combines these two commands into

    one for you.
  29. Branching Run git branch at any time to list all

    of your local branches.
  30. Git is just a big type of tree. More specifically,

    it is a Directed Acyclic Graph. Directed Acyclic Graph
  31. That’s maths speak for “a fancy type of graph where

    the links between the nodes never form a loop”. Just call it a “DAG”, for short. Directed Acyclic Graph
  32. Directed Acyclic Graph

  33. Git stores everything in a big DAG. Directed Acyclic Graph

  34. The DAG contains one node per directory, and one node

    per file. Directories are another tree. The files binary blobs. Directed Acyclic Graph
  35. Directed Acyclic Graph Each commit contains three things: ◦ The

    metadata, like the description and the author name. ◦ The SHA of the parent commit. ◦ The tree of its’ contents.
  36. (http://git-scm.com/book/en/Git-Internals-Git-Objects)

  37. Git is all local, so when you commit you are

    the only person who has your changes. Sharing Your Commits
  38. Sharing Your Commits To share these, we have git push.

    This allows you to “push” your changes to another person or server.
  39. Sharing Your Commits You can choose what changes to push.

  40. Sharing Your Commits As Git is distributed, you can share

    your code with lots of people or servers.
  41. Sharing Your Commits Git stores these people or servers “remotes”.

    Running git remote -v will list your remotes.
  42. Sharing Your Commits The Git convention is to call your

    main remote origin.
  43. Sharing Your Commits Each remote is just a URL to

    which Git will send the changes. If you use GitHub as your origin remote, the URL will look like git@github.com:username/repo.git.
  44. Sharing Your Commits When you run git push origin xyz-

    foo-bar, you are telling Git to send all the commits you made to the xzy-foo-bar branch to the origin remote. Git allows you to send any and all changes across all your branches to the remote using git push --all or git push (but please don’t do ever this because it encourages mistakes!)
  45. Getting Changes Running git fetch is how you ask your

    remotes for the changes they have that you don’t.
  46. Getting Changes It defaults to asking your origin remote; you

    can ask a specific remote by running git fetch <remote>. This command fetches the changes across all branches.
  47. Getting Changes These changes are stored locally as read-only branches

    prefixed with the name of the remote, eg. origin/master.
  48. Getting Changes The origin/master branch is the copy of master

    as last fetched from the origin remote. The master branch is your local branch.
  49. Getting Changes Once the changes are fetched, you need to

    merge the remote changes into your local branch.
  50. Getting Changes On the branch xyz-foo-bar, I can run the

    following to update: git fetch git merge origin/xyz-foo-bar
  51. Getting Changes Instead, use git pull <remote> <branch>, eg. on

    xyz-foo-bar run git pull origin xyz-foo-bar to update.
  52. Getting Changes The git pull command is just shorthand for

    git fetch + git merge.
  53. Basic Workflow

  54. 1. Clone The Repo git clone git@github.com: username/repo.git

  55. git checkout -b xyz-foo-bar 2. Create Your Branch

  56. 3. Hack Away

  57. 4. Stage Your Work git add <file> or git add

    . (this recursively adds all files in the current directory)
  58. 5. Commit Your Work git commit

  59. 6. Push Your Work git push origin xyz-foo-bar

  60. 7. Pull Down Changes git pull origin xyz-foo-bar

  61. Merging vs Rebasing

  62. Merging vs Rebasing Merging works by collecting up all of

    the changes from the remote branch and adding them in a single commit.
  63. Merging vs Rebasing Rebasing is an alternative which takes the

    new commits from the remote and slots them into the right place in time.
  64. Merging vs Rebasing Merging is easier, but it leads to

    a very bloated history and tonnes of merge commits everywhere. Rebasing can be harder, but gives you a perfect, clean history.
  65. Merging vs Rebasing Rebasing rewrites history.

  66. Merging vs Rebasing When pulling, use git pull --rebase to

    make it use rebase instead of merge.
  67. Merging vs Rebasing If using git fetch, just use git

    rebase origin/<branch> instead to rebase against the remote changes.
  68. Force Pushing Whenever you rewrite history (eg. rebase or amend

    a commit), you’ll have to force push. Use git push -f origin <branch>.
  69. NEVER EVER FORCE PUSH master. I WILL KILL YOU PERSONALLY

    (with a rusty screwdriver) (and a chainsaw)
  70. Actual Picture of Me After Somebody Force Pushed To master

  71. Force Pushing It’s absolutely fine to rewrite the history of

    and force push a branch only you are working on.
  72. Force Pushing If you are working on a branch with

    other people, tell them whenever you force push a branch so they can rebase against it.
  73. Force Pushing If you are working on a branch with

    many people, probably don’t force push it - save yourself the trauma and just use git merge and/or git pull instead.
  74. Tricks & Tips

  75. Whenever you type a SHA, just type the first few

    letters and that’s enough! eg. 6b36910b0e33d0f49bcc9a9fa66dbc5ec3f2d0e1 → 6b369 Short SHAs
  76. git reflog Will save your arse when the world has

    caught fire (or after you’ve tried the commands in the rest of this presentation!) Git Reflog
  77. The reflog keeps a record of every single thing you

    do. That means moving branches, commiting, merging, rebasing. Everything. Use it when you’ve made a mistake. Git Reflog
  78. git cherry-pick <SHA> Allows you to copy a specific commit

    to the branch you’re on. Useful for when you need some common code in two branches, but they don’t depend on each other. Cherry Picking
  79. git commit --amend This allows you to edit the last

    commit message, which is useful if you just made a typo. Only do this if you haven’t pushed it yet. Amend a Commit Message
  80. git reset --soft <SHA> Allows you to add or change

    things in a commit you just made. Useful when you realise you’ve accidently missed something. Only do this if you haven’t pushed it yet. Git Reset (Soft)
  81. I’ve made a commit and I realised I spelled something

    wrong. git reset --soft HEAD^ # hack hack hack git commit Git Reset (Soft)
  82. git reset --hard <SHA> Allows you to move the current

    branch to a specific commit and throw whatever else may have been in there away. Git Reset (Hard)
  83. I move to a branch that hasn’t been updated in

    ages and I just want to make it the same as master git fetch git reset --hard origin/master Git Reset (Hard)
  84. git rebase -i <SHA> This is the best part of

    Git. It will blow your mind if used properly. Git Rebase (Interactive)
  85. Demo Time Git Rebase (Interactive)

  86. FAQs

  87. master is your local branch. origin/master is your copy of

    the remote master branch on the origin remote. master vs origin/master
  88. Because Git is distributed, your master has nothing to do

    with origin’s master - even though they have the same name! master vs origin/master
  89. Detached HEAD State HEAD is Git’s magic word for “the

    latest commit on a branch”.
  90. Detached HEAD State Detached HEAD is when you’re on a

    commit that isn’t the end of a local branch.
  91. Detached HEAD State You can end up there by checking

    out a commit, or by checking out a remote branch (eg. origin/master).
  92. Just a quick recap. :-) Terminology

  93. 1. Ref: A SHA or branch name. 2. Commit: A

    group of changes. 3. Branch: A group of commits. 4. Tag: A label on a particular place in a branch. Terminology
  94. 5. Staging Area: The area where your changes are put

    when you run git add, allowing you to select what changes you want to be taken when you run git commit. Terminology
  95. 6. Remote: A URL representing a person or server to

    which you can push and pull code to and from. Terminology
  96. 7. Fetch: Getting the changes that have occurred from a

    remote. 8. Pull: Getting the changes that have occurred from a remote, and merging them. 9. Push: Sending your local changes to a remote. Terminology
  97. Fin.