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 full-size slide

  2. GIT IS WEIRD AND HARD?
    WHO THINKS

    View full-size slide

  3. GIT IS EASY?
    WHO THINKS

    View full-size slide

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

    View full-size slide

  5. GIT IS GOOD...

    View full-size slide

  6. AS A CONTENT TRACKER

    FOR TEXT FILES.
    GIT IS GREAT

    View full-size slide

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

    View full-size slide

  8. GIT IS NOT MAGIC.

    View full-size slide

  9. A DEPENDENCY MANAGER.
    GIT IS NOT

    View full-size slide

  10. ACCESS CONTROL.
    GIT DOES NOT HAVE

    View full-size slide

  11. WHOLE FILE SNAPSHOTS.
    GIT STORES

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  14. GIT CAN GET UGLY...

    View full-size slide

  15. YOUR FAULT.
    IT'S NOT REALLY

    View full-size slide

  16. THE INTERNALS HAVE STRONG OPINIONS,

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

    View full-size slide

  17. CONTAINS OPINIONS
    WARNING!

    View full-size slide

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

    View full-size slide

  19. TALK TO YOUR TEAMMATES.
    GOLDEN RULE #1

    View full-size slide

  20. CODIFY GOVERNANCE
    WITHOUT ACCESS CONTROLS, YOU MUST

    View full-size slide

  21. FORKS
    ROUGHLY
    ALLOW
    PERMISSIONS
    WITHOUT
    BRANCH
    LOCKING

    View full-size slide

  22. PULL
    REQUESTS

    View full-size slide

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

    View full-size slide

  24. SEPARATE YOUR IDEAS.
    GOLDEN RULE #2

    View full-size slide

  25. DOCUMENT AND USE A SINGLE
    BRANCHING STRATEGY

    View full-size slide

  26. 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 full-size slide

  27. STATE BRANCHING
    GITLAB FLOW

    View full-size slide

  28. BRANCH-PER-FEATURE
    GITHUB FLOW

    View full-size slide

  29. SCHEDULED
    RELEASE
    GITFLOW

    View full-size slide

  30. ONE BALL PER IDEA.

    View full-size slide

  31. COMMIT TO WHOLE IDEAS

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

    View full-size slide

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

    View full-size slide

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

    a coherent unit of work.

    View full-size slide

  34. BE CONSISTENT.
    GOLDEN RULE #3

    View full-size slide

  35. DOCUMENT AND USE A
    MAINTENANCE STRATEGY.

    View full-size slide

  36. 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 full-size slide

  37. MERGE TO UPDATE IS EASY,
    BUT MESSY

    View full-size slide

  38. UPDATE WITH REBASE
    (IF YOU CARE)

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  41. OUTSOURCE YOUR
    DEPENDENCY MANAGEMENT

    View full-size slide

  42. 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 full-size slide

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

    View full-size slide

  44. MONOLITH
    ONE MEGA REPO

    View full-size slide

  45. MICROSERVICES
    MANY ICKLE REPOS

    View full-size slide

  46. GROW WITH EACH VERSION
    BINARY FILES WILL

    View full-size slide

  47. FOR VERY LARGE FILES
    USE OFF-SITE STORAGE

    View full-size slide

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

    --SINGLE-BRANCH [FOLDER]

    View full-size slide

  49. 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 full-size slide

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

    View full-size slide

  51. RESOURCES
    WWW.GITFORTEAMS.COM

    View full-size slide

  52. 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 full-size slide

  53. 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 full-size slide

  54. 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 full-size slide