Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

More Decks by Emma Jane Hogbin Westby

Other Decks in Technology

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