Git's Golden Rules (for Teams)

Let's face it, everyone can punch some commands into Git and make things go splat. That's the easy part. Understanding *why* and *when* to apply various commands is the hard part of learning to be an effective Git team player. This session will briefly cover the four most important factors that will determine your project's success in working with Git:

- Access control -- who and how people can update a shared repository
- Common branching patterns -- what they are, and how to choose one
- Maintenance strategies -- how to keep your local repository up-to-date
- Repository architecture -- files to include, and omit

Transcript

1. GIT'S GOLDEN RULES
 (FOR TEAMS) EMMA JANE HOGBIN WESTBY @EMMAJANEHW WWW.GITFORTEAMS.COM
2. GIT IS WEIRD AND HARD? WHO THINKS
3. GIT IS EASY? WHO THINKS
4. ONLY GITS RAISE THEIR HAND WHEN ASKED? WHO THINKS
5. </CALIBRATION>
6. GIT IS GOOD...
7. AS A CONTENT TRACKER
 FOR TEXT FILES. GIT IS GREAT
8. COMPARED TO CENTRALISED VERSION CONTROL SYSTEMS. GIT IS VERY FAST
9. GIT IS NOT MAGIC.
10. A DEPENDENCY MANAGER. GIT IS NOT
11. ACCESS CONTROL. GIT DOES NOT HAVE
12. WHOLE FILE SNAPSHOTS. GIT STORES
13. GIT BECOMES SLOWER AS YOUR HISTORY GETS VERY, VERY LARGE.
14. 10,000+ COMMITS FOR VERY LARGE VALUES OF VERY LARGE
15. GIT CAN GET UGLY...
16. YOUR FAULT. IT'S NOT REALLY
17. THE INTERNALS HAVE STRONG OPINIONS,
 BUT THE INTERFACE DOES NOT. GIT IS WEIRD AND HARD BECAUSE
18. CONTAINS OPINIONS WARNING!
19. TODAY GIT'S GOLDEN RULES ▸ Talk to your teammates. ▸ Separate your ideas. ▸ Be consistent. ▸ Include only what you need.
20. TALK TO YOUR TEAMMATES. GOLDEN RULE #1
21. CODIFY GOVERNANCE WITHOUT ACCESS CONTROLS, YOU MUST
22. BASIC SETUP
23. FORKS ROUGHLY ALLOW PERMISSIONS WITHOUT BRANCH LOCKING
24. PULL REQUESTS
25. GOLDEN RULE TALK TO YOUR TEAMMATES. ▸ Map access, then map commands. ▸ Use branch locking or forks to control access.
26. SEPARATE YOUR IDEAS. GOLDEN RULE #2
27. DOCUMENT AND USE A SINGLE BRANCHING STRATEGY
28. USE A CONVENTION (OR INVENT YOUR OWN … ENDING IN “FLOW”) POPULAR BRANCHING CONVENTIONS ▸ State / Environment Branching (GitLab Flow) ▸ Branch-Per-Feature (GitHub Flow) ▸ Scheduled Release (GitFlow)
29. STATE BRANCHING GITLAB FLOW
30. BRANCH-PER-FEATURE GITHUB FLOW
31. SCHEDULED RELEASE GITFLOW
32. ONE BALL PER IDEA.
33. COMMIT TO WHOLE IDEAS
 PRIOR TO MERGE $ GIT REBASE --INTERACTIVE HEAD~N
34. CONVERT CONVERSATIONS TO CONCLUSIONS AT MERGE $ GIT MERGE --SQUASH PR_BRANCH
35. GOLDEN RULE SEPARATE YOUR IDEAS. ▸ Every commit and each branch should hold
 a coherent unit of work.
36. BE CONSISTENT. GOLDEN RULE #3
37. DOCUMENT AND USE A MAINTENANCE STRATEGY.
38. pull fetch + merge pull --rebase=preserve fetch + rebase merge --no-ff forces a merge commit object
 (“true merge”) merge --ff-only fast forward (graph looks like rebase) merge --squash compress commits to one; then merge rebase forward-port local commits cherry-pick merge individual commits WHY THE FUSS? BECAUSE TIMTOWTDI
40. MERGE TO UPDATE IS EASY, BUT MESSY
41. UPDATE WITH REBASE (IF YOU CARE)
42. GOLDEN RULE BE CONSISTENT. ▸ Keep your history legible by having the team use a single strategy to update branches.
43. INCLUDE ONLY WHAT YOU NEED. GOLDEN RULE #4
44. OUTSOURCE YOUR DEPENDENCY MANAGEMENT
45. IF YOU MUST INCLUDE EXTERNAL WORK ▸ Keep your "core" clean and track upstream work with named branches. ▸ Nest repositories without tracking by using subtrees (clone inside a clone). ▸ Git can track external repositories with submodules.
 There be dragons.
46. STORE AS MUCH AS YOU NEED, BUT NOT MORE.
47. MONOLITH ONE MEGA REPO
48. MICROSERVICES MANY ICKLE REPOS
49. GROW WITH EACH VERSION BINARY FILES WILL
50. FOR VERY LARGE FILES USE OFF-SITE STORAGE
51. USE SHALLOW CLONES FOR FASTER DEPLOYMENTS $ GIT CLONE --DEPTH [DEPTH] [REMOTE-URL] $ GIT CLONE [URL] --BRANCH [BRANCH_NAME]
 --SINGLE-BRANCH [FOLDER]
52. GOLDEN RULE INCLUDE ONLY WHAT YOU NEED. ▸ Outsource your dependency management. ▸ Break your repository into smaller service repositories when it's time. ▸ Binary files grow when versioned. ▸ Use shallow clones for faster deployments.
53. TODAY GIT'S GOLDEN RULES ▸ Talk to your teammates. ▸ Separate your ideas. ▸ Be consistent. ▸ Include only what you need.
54. RESOURCES WWW.GITFORTEAMS.COM
55. RESOURCES BIG REPOSITORIES ▸ How to Handle Big Repositories with Git
 https://www.atlassian.com/git/articles/how-to-handle-big- repositories-with-git/ ▸ How do you handle your microservices
 https://news.ycombinator.com/item?id=9705098 ▸ Organizing Microservices in a Single Repository
 http://blog.plataformatec.com.br/2015/01/organizing- microservices-in-a-single-git-repository/
56. RESOURCES DEPENDENCY MANAGEMENT ▸ How do you handle external dependencies?
 http://programmers.stackexchange.com/questions/110093/how- would-one-handle-external-dependencies-in-an-open-source-project ▸ Paket for .NET and Mono
 http://fsprojects.github.io/Paket/ ▸ Composer for PHP
 https://getcomposer.org/doc/00-intro.md ▸ Mastering Submodules
 https://medium.com/@porteneuve/mastering-git- submodules-34c65e940407
57. RESOURCES TRACKING (LARGE) BINARY FILES ▸ Do not version binaries in the repository; reference them from another location. ▸ git-annex - https://git-annex.branchable.com/ ▸ git-bigfiles - http://caca.zoy.org/wiki/git-bigfiles ▸ GLFS - https://git-lfs.github.com ** start here ▸ http://blogs.atlassian.com/2014/05/handle-big- repositories-git/