Git's Golden Rules (for Teams)

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

Tweet

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
  39. None
  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/