4. Vocabulary
• Repository -- Holds the history of all changes
• Commit -- A point in time snapshot of your repo
• Reference -- Something that makes it so you don't have to
remember a 40 hexadecimal digit sha1 hash
• Branch -- A pointer to the head of a group of commits
• Remote -- A thing you push to and pull from
• Pull Request -- How you get your code reviewed (unless you're on
kernel)
• Github -- Magic
6. 1. Fork a project
2. Clone your fork
3. Branch
4. Edit some files
5. Commit
6. Repeat 4 and 5 until feature/bug is complete
7. REBASE to create a history that I won't mind reading through
8. Pull any changes that have happened on non-forked master in the interim and
rebase on top of those if you want a linear history otherwise do nothing for this step
9. Open pull request from your branch on your fork into the canonical repo's master
branch
10. Profit
7. How To Branch
• git checkout -b improvement/unicorns
• git branch bug/voldemort && git checkout bug/voldemort
8. How To Commit
• Edit Some Stuff
• git add -p and git add (DO NOT GIT ADD * or .)
• Review what is in staging with git diff --cached and
git status
• git commit
9. Commit Messages
• Start with bug number and short description <70
characters
• Longer description after one blank line
10. Index == Staging
• STAGE EVERYTHING
• Save time later by staging only some logical
changes now
12. Refs
• N^ goes up N parents (HEAD^, HEAD^100)
• ~ selects merge parents (HEAD~, HEAD~2)
• Mix and match (don't actually though)
• HEAD is hard coded and always points to the
current head of whatever branch you have
checked out
• Almost everything can be treated as a ref
15. • Blob (zlib compressed bytes representing a file)
• Tree (a tree where the leaf nodes are blobs)
• Commit (a pointer to: a tree, n parent commits)
• Tag (a pointer to a commit)
• (IGNORE THIS) something something packfiles
