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
   

   View Slide

2. GIT IS WEIRD AND HARD?
   WHO THINKS
   

   View Slide

3. GIT IS EASY?
   WHO THINKS
   

   View Slide

4. ONLY GITS RAISE THEIR HAND
   WHEN ASKED?
   WHO THINKS
   

   View Slide

5. 
   

   View Slide

6. GIT IS GOOD...
   

   View Slide

7. AS A CONTENT TRACKER

   FOR TEXT FILES.
   GIT IS GREAT
   

   View Slide

8. COMPARED TO CENTRALISED
   VERSION CONTROL SYSTEMS.
   GIT IS VERY FAST
   

   View Slide

9. GIT IS NOT MAGIC.
   

   View Slide

10. A DEPENDENCY MANAGER.
    GIT IS NOT
    

    View Slide

11. ACCESS CONTROL.
    GIT DOES NOT HAVE
    

    View Slide

12. WHOLE FILE SNAPSHOTS.
    GIT STORES
    

    View Slide

13. GIT BECOMES SLOWER AS YOUR
    HISTORY GETS VERY, VERY LARGE.
    

    View Slide

14. 10,000+ COMMITS
    FOR VERY LARGE VALUES OF VERY LARGE
    

    View Slide

15. GIT CAN GET UGLY...
    

    View Slide

16. YOUR FAULT.
    IT'S NOT REALLY
    

    View Slide

17. THE INTERNALS HAVE STRONG OPINIONS,

    BUT THE INTERFACE DOES NOT.
    GIT IS WEIRD AND HARD BECAUSE
    

    View Slide

18. CONTAINS OPINIONS
    WARNING!
    

    View Slide

19. TODAY
    GIT'S GOLDEN RULES
    ▸ Talk to your teammates.
    ▸ Separate your ideas.
    ▸ Be consistent.
    ▸ Include only what you need.
    

    View Slide

20. TALK TO YOUR TEAMMATES.
    GOLDEN RULE #1
    

    View Slide

21. CODIFY GOVERNANCE
    WITHOUT ACCESS CONTROLS, YOU MUST
    

    View Slide

22. BASIC SETUP
    

    View Slide

23. FORKS
    ROUGHLY
    ALLOW
    PERMISSIONS
    WITHOUT
    BRANCH
    LOCKING
    

    View Slide

24. PULL
    REQUESTS
    

    View Slide

25. GOLDEN RULE
    TALK TO YOUR TEAMMATES.
    ▸ Map access, then map commands.
    ▸ Use branch locking or forks to control access.
    

    View Slide

26. SEPARATE YOUR IDEAS.
    GOLDEN RULE #2
    

    View Slide

27. DOCUMENT AND USE A SINGLE
    BRANCHING STRATEGY
    

    View Slide

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)
    

    View Slide

29. STATE BRANCHING
    GITLAB FLOW
    

    View Slide

30. BRANCH-PER-FEATURE
    GITHUB FLOW
    

    View Slide

31. SCHEDULED
    RELEASE
    GITFLOW
    

    View Slide

32. ONE BALL PER IDEA.
    

    View Slide

33. COMMIT TO WHOLE IDEAS

    PRIOR TO MERGE
    $ GIT REBASE --INTERACTIVE HEAD~N
    

    View Slide

34. CONVERT CONVERSATIONS TO
    CONCLUSIONS AT MERGE
    $ GIT MERGE --SQUASH PR_BRANCH
    

    View Slide

35. GOLDEN RULE
    SEPARATE YOUR IDEAS.
    ▸ Every commit and each branch should hold

    a coherent unit of work.
    

    View Slide

36. BE CONSISTENT.
    GOLDEN RULE #3
    

    View Slide

37. DOCUMENT AND USE A
    MAINTENANCE STRATEGY.
    

    View Slide

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
    

    View Slide

39. View Slide

40. MERGE TO UPDATE IS EASY,
    BUT MESSY
    

    View Slide

41. UPDATE WITH REBASE
    (IF YOU CARE)
    

    View Slide

42. GOLDEN RULE
    BE CONSISTENT.
    ▸ Keep your history legible by having the team use a single
    strategy to update branches.
    

    View Slide

43. INCLUDE ONLY WHAT YOU NEED.
    GOLDEN RULE #4
    

    View Slide

44. OUTSOURCE YOUR
    DEPENDENCY MANAGEMENT
    

    View Slide

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.
    

    View Slide

46. STORE AS MUCH AS YOU
    NEED, BUT NOT MORE.
    

    View Slide

47. MONOLITH
    ONE MEGA REPO
    

    View Slide

48. MICROSERVICES
    MANY ICKLE REPOS
    

    View Slide

49. GROW WITH EACH VERSION
    BINARY FILES WILL
    

    View Slide

50. FOR VERY LARGE FILES
    USE OFF-SITE STORAGE
    

    View Slide

51. USE SHALLOW CLONES FOR
    FASTER DEPLOYMENTS
    $ GIT CLONE --DEPTH [DEPTH] [REMOTE-URL]
    $ GIT CLONE [URL] --BRANCH [BRANCH_NAME]

    --SINGLE-BRANCH [FOLDER]
    

    View Slide

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.
    

    View Slide

53. TODAY
    GIT'S GOLDEN RULES
    ▸ Talk to your teammates.
    ▸ Separate your ideas.
    ▸ Be consistent.
    ▸ Include only what you need.
    

    View Slide

54. RESOURCES
    WWW.GITFORTEAMS.COM
    

    View Slide

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/
    

    View Slide

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
    

    View Slide

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/
    

    View Slide