Git workshop for dum^Wstudents

A Git workshop I ran at University of Turku

Transcript

1. git workshop for dum^W students
2. <me>
3. Jyrki Pulliainen @nailor
4. Used git since 2006 (mainly work with Python, JS and git)
5. (we're hiring, btw) Currently work at Taiste
6. </me>
7. Version Control
8. (and have backups of it) Keep a history of your work
9. Centralized vs Distributed
10. Centralized version control • The "traditional" model • One server, multiple clients
11. Centralized Version Control Server
12. Pros of a centralized VCS • Single, undisputed, "master" copy • Makes some administration easier
13. Cons of CVCS • Offline access to single revision • Usually commits, merges etc not possible offline • Expensive operations (merge, branch, commit) • Single point of failure in the system
14. Distributed version control • New kid on the block... • ... except it's old (monotone, bitkeeper etc) • Full history on everyone • No need for a central server... • ...but you can have a one • DVCS: git, mercurial, monotone, bitkeeper, bazaar (and the list goes on...)
15. Distributed version control Server
16. Distributed version control Test server Prod. env
17. Pros of DVCS • Enables working offline • Workflow is free • Cheap operations • Full history available at everyone • History can be edited! • No single point of failure!
18. Cons of DVCS • "Network" can get messy • Initial clones (containing full history) can be big • Independent work creates conflicts and merges
19. the information manager from hell GIT
20. • Originally developed by Linus Torvalds for Linux kernel development • Now maintained by Junio C Hamano • Replaced bitkeeper in kernel development • Development started in 2005 • Now in version 1.7.7 Brief history
21. Key philosophy 1. Not-CVS 2. Distributed like BitKeeper 3. Does not corrupt 4. High performance
22. Git is developed using Git
23. Prepare for graphs! Git data model
24. blob
25. blob tree + filename + mode subdir + parents
26. blob tree + filename + mode subdir + parents commit + parents + message
27. blob tree + filename + mode subdir + parents commit + parents + message branch HEAD ref:
28. a History branch HEAD
29. a History branch HEAD b
30. Fire up computers, open terminals! Let's check the essentials
31. ie. what happens when you commit Three trees of git
32. What's in the version control now 1. HEAD
33. What's going to be commited next "Staging Area" 2. INDEX
34. What you're working on right now 3. WORKING DIRECTORY
35. HEAD INDEX WORKING DIR git add git commit git reset git checkout
36. Roles of the trees • HEAD: Last commit, next parent • Index: Proposed next commit • Working dir: Sandbox
37. Branching & Merging A B C mybranch D master master E mybranch mybranch
38. Branching & Merging • Branches are just labels on commits • Merge is just a commit with two or more parents • Remote branch is just a speacially named branch: remote/<remotename>/<branchname>
39. Back to the console!
40. (you might need to do this eventually) Working with others
41. • clone: Clone a remote repository • Supported protocols: SSH, git, http, https, ... • fetch: Fetch remote references • pull: fetch + merge • push: push to remote server Working w/ others
42. Capitalized, short (50 chars or less) summary More detailed explanatory text, if necessary. Wrap it to about 72 characters or so. In some contexts, the first line is treated as the subject of an email and the rest of the text as the body. The blank line separating the summary from the body is critical (unless you omit the body entirely); tools like rebase can get confused if you run the two together. Write your commit message in the present tense: "Fix bug" and not "Fixed bug." This convention matches up with commit messages generated by commands like git merge and git revert. Further paragraphs come after blank lines. - Bullet points are okay, too - Typically a hyphen or asterisk is used for the bullet, preceded by a single space, with blank lines in between, but conventions vary here - Use a hanging indent A good commit message
43. (a nifty way to avoid shooting your or someone else's foot) Use feature branches!
44. And back to the console!
45. Bonus Round
46. • The Best Ever(tm) feature in version control systems • Keeps history clean and working • Makes you look like a superb rockstar dev • Can be undoed (locally)! History editing
47. History editing: caveats • Branches might get "out of sync" • May require a forced push... • ...but never ever ever force push to a branch someone else is also using! • Never. • Ever.
48. History-editing-fu • git commit --amend • git rebase • git rebase --interactive • Not for the faint hearted: git filter-branch
49. Rebasing A B master C remotes/origin/master master master B B'
50. Let's check it out!
51. Managing a havoc
52. The Grand Saviour of Many Projects git reflog
53. • Can recover from nearly everything • Can not save from accidental: ◦ git checkout -- somefile.txt ◦ git reset --hard ◦ git gc • Learn to use and it'll serve you well! git reflog
54. That's all folks!