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!

Transcript

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.
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.