Git's Golden Rules (for Teams)

Slide 1

Slide 1 text

GIT'S GOLDEN RULES  (FOR TEAMS) EMMA JANE HOGBIN WESTBY @EMMAJANEHW WWW.GITFORTEAMS.COM

Slide 2

Slide 2 text

GIT IS WEIRD AND HARD? WHO THINKS

Slide 3

Slide 3 text

GIT IS EASY? WHO THINKS

Slide 4

Slide 4 text

ONLY GITS RAISE THEIR HAND WHEN ASKED? WHO THINKS

Slide 5

Slide 5 text

Slide 6

Slide 6 text

GIT IS GOOD...

Slide 7

Slide 7 text

AS A CONTENT TRACKER  FOR TEXT FILES. GIT IS GREAT

Slide 8

Slide 8 text

COMPARED TO CENTRALISED VERSION CONTROL SYSTEMS. GIT IS VERY FAST

Slide 9

Slide 9 text

GIT IS NOT MAGIC.

Slide 10

Slide 10 text

A DEPENDENCY MANAGER. GIT IS NOT

Slide 11

Slide 11 text

ACCESS CONTROL. GIT DOES NOT HAVE

Slide 12

Slide 12 text

WHOLE FILE SNAPSHOTS. GIT STORES

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

GIT CAN GET UGLY...

Slide 16

Slide 16 text

YOUR FAULT. IT'S NOT REALLY

Slide 17

Slide 17 text

THE INTERNALS HAVE STRONG OPINIONS,  BUT THE INTERFACE DOES NOT. GIT IS WEIRD AND HARD BECAUSE

Slide 18

Slide 18 text

CONTAINS OPINIONS WARNING!

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

TALK TO YOUR TEAMMATES. GOLDEN RULE #1

Slide 21

Slide 21 text

CODIFY GOVERNANCE WITHOUT ACCESS CONTROLS, YOU MUST

Slide 22

Slide 22 text

BASIC SETUP

Slide 23

Slide 23 text

FORKS ROUGHLY ALLOW PERMISSIONS WITHOUT BRANCH LOCKING

Slide 24

Slide 24 text

PULL REQUESTS

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

SEPARATE YOUR IDEAS. GOLDEN RULE #2

Slide 27

Slide 27 text

DOCUMENT AND USE A SINGLE BRANCHING STRATEGY

Slide 28

Slide 28 text

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)

Slide 29

Slide 29 text

STATE BRANCHING GITLAB FLOW

Slide 30

Slide 30 text

BRANCH-PER-FEATURE GITHUB FLOW

Slide 31

Slide 31 text

SCHEDULED RELEASE GITFLOW

Slide 32

Slide 32 text

ONE BALL PER IDEA.

Slide 33

Slide 33 text

COMMIT TO WHOLE IDEAS  PRIOR TO MERGE $ GIT REBASE --INTERACTIVE HEAD~N

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

GOLDEN RULE SEPARATE YOUR IDEAS. ▸ Every commit and each branch should hold  a coherent unit of work.

Slide 36

Slide 36 text

BE CONSISTENT. GOLDEN RULE #3

Slide 37

Slide 37 text

DOCUMENT AND USE A MAINTENANCE STRATEGY.

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

No content

Slide 40

Slide 40 text

MERGE TO UPDATE IS EASY, BUT MESSY

Slide 41

Slide 41 text

UPDATE WITH REBASE (IF YOU CARE)

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

INCLUDE ONLY WHAT YOU NEED. GOLDEN RULE #4

Slide 44

Slide 44 text

OUTSOURCE YOUR DEPENDENCY MANAGEMENT

Slide 45

Slide 45 text

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.

Slide 46

Slide 46 text

STORE AS MUCH AS YOU NEED, BUT NOT MORE.

Slide 47

Slide 47 text

MONOLITH ONE MEGA REPO

Slide 48

Slide 48 text

MICROSERVICES MANY ICKLE REPOS

Slide 49

Slide 49 text

GROW WITH EACH VERSION BINARY FILES WILL

Slide 50

Slide 50 text

FOR VERY LARGE FILES USE OFF-SITE STORAGE

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

GOLDEN RULE INCLUDE ONLY WHAT YOU NEED. ▸ Outsource your dependency management. ▸ Break your repository into smaller service repositories when it's time. ▸ Binary ﬁles grow when versioned. ▸ Use shallow clones for faster deployments.

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

RESOURCES WWW.GITFORTEAMS.COM

Slide 55

Slide 55 text

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/

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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-bigﬁles - http://caca.zoy.org/wiki/git-bigﬁles ▸ GLFS - https://git-lfs.github.com ** start here ▸ http://blogs.atlassian.com/2014/05/handle-big- repositories-git/