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

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

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!

Nathan Kleyn

September 26, 2013

More Decks by Nathan Kleyn

Other Decks in Programming


  1. 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
  2. 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)
  3. The Repository You can tell when something is a Git

    repo by checking for the presence of the hidden “.git” folder.
  4. The Three States There are three states in Git: ◦

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

    public, you first “stage” these changes, then you “commit” them.
  6. 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.
  7. The Three States If you make lots of changes to

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

    want to add to your staging area.
  9. A Commit A commit is stored as the difference between

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

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

    the contents of the commit being made and the SHA of the parent commit.
  12. 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.
  13. A Commit This is Git’s cryptographically strong promise to you

    that nobody has tampered with any of your code.
  14. 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>.
  15. Git is just a big type of tree. More specifically,

    it is a Directed Acyclic Graph. Directed Acyclic Graph
  16. 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
  17. The DAG contains one node per directory, and one node

    per file. Directories are another tree. The files binary blobs. Directed Acyclic Graph
  18. 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.
  19. Git is all local, so when you commit you are

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

    This allows you to “push” your changes to another person or server.
  21. Sharing Your Commits As Git is distributed, you can share

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

    Running git remote -v will list your remotes.
  23. 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 [email protected]:username/repo.git.
  24. 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!)
  25. Getting Changes Running git fetch is how you ask your

    remotes for the changes they have that you don’t.
  26. 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.
  27. Getting Changes These changes are stored locally as read-only branches

    prefixed with the name of the remote, eg. origin/master.
  28. 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.
  29. Getting Changes Once the changes are fetched, you need to

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

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

    xyz-foo-bar run git pull origin xyz-foo-bar to update.
  32. 4. Stage Your Work git add <file> or git add

    . (this recursively adds all files in the current directory)
  33. Merging vs Rebasing Merging works by collecting up all of

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

    new commits from the remote and slots them into the right place in time.
  35. 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.
  36. Merging vs Rebasing When pulling, use git pull --rebase to

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

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

    a commit), you’ll have to force push. Use git push -f origin <branch>.

    (with a rusty screwdriver) (and a chainsaw)
  40. Force Pushing It’s absolutely fine to rewrite the history of

    and force push a branch only you are working on.
  41. 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.
  42. 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.
  43. Whenever you type a SHA, just type the first few

    letters and that’s enough! eg. 6b36910b0e33d0f49bcc9a9fa66dbc5ec3f2d0e1 → 6b369 Short SHAs
  44. 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
  45. 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
  46. 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
  47. 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
  48. 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)
  49. I’ve made a commit and I realised I spelled something

    wrong. git reset --soft HEAD^ # hack hack hack git commit Git Reset (Soft)
  50. 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)
  51. 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)
  52. git rebase -i <SHA> This is the best part of

    Git. It will blow your mind if used properly. Git Rebase (Interactive)
  53. master is your local branch. origin/master is your copy of

    the remote master branch on the origin remote. master vs origin/master
  54. 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
  55. Detached HEAD State Detached HEAD is when you’re on a

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

    out a commit, or by checking out a remote branch (eg. origin/master).
  57. 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
  58. 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
  59. 6. Remote: A URL representing a person or server to

    which you can push and pull code to and from. Terminology
  60. 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