Slide 1

Slide 1 text

Design Patterns for Git Lorna Mitchell, IBM Velocity Amsterdam 2016

Slide 2

Slide 2 text

Well-Organised Repositories @lornajane

Slide 3

Slide 3 text

Git Branching @lornajane

Slide 4

Slide 4 text

A Branch is a Label • A branch is a pointer to a commit. • The pointer moves along when you commit on a branch. [master]$ git rev-parse master ba8969833794d14abb218f8532edb5fcdc4ce9ab [master]$ cat .git/refs/heads/master ba8969833794d14abb218f8532edb5fcdc4ce9ab @lornajane

Slide 5

Slide 5 text

Commits Aren't "On" Branches @lornajane

Slide 6

Slide 6 text

Commits Aren't "On" Branches @lornajane

Slide 7

Slide 7 text

Pro-tip: The reflog Command If you move a branch pointer and then regret it: git reflog Will show every revision your HEAD pointer has visited To rescue a "lost" revision check it out and then create a new branch @lornajane

Slide 8

Slide 8 text

Branching Strategies @lornajane

Slide 9

Slide 9 text

Branching Strategies A living, changing process document. @lornajane

Slide 10

Slide 10 text

Git Flow Comprehensive branching strategy, supported by scripts. • Article: http://lrnja.net/1ebawKU • Scripts: https://github.com/nvie/gitflow @lornajane

Slide 11

Slide 11 text

Alternatively: Github Flow Use with feature toggles @lornajane

Slide 12

Slide 12 text

Topic Branches Pattern Starting something new? Use a branch. @lornajane

Slide 13

Slide 13 text

Topic Branches Pattern Rebase branch onto master, review and merge @lornajane

Slide 14

Slide 14 text

Branch Naming • master default branch name • develop often used for bleeding edge branch Configure your repo accordingly @lornajane

Slide 15

Slide 15 text

Environment Branches Maintain one branch per platform • branch always reflects current state of platform • plays well with automated deployment • non-live branches can be disposed of at any time @lornajane

Slide 16

Slide 16 text

Environment Branches @lornajane

Slide 17

Slide 17 text

Hotfix Pattern @lornajane

Slide 18

Slide 18 text

Hotfix Pattern Branch off, commit once, merge with --no-ff • makes it very clear what happened • easily merge the branch back upstream if needed • makes it possible to cleanly undo without losing anything @lornajane

Slide 19

Slide 19 text

Tagging for Releases Use annotated tags and attach a message git tag -a v2.11 -m "v2.11 with caching" @lornajane

Slide 20

Slide 20 text

One Repo Per Person? Normal for open source, rare for commercial teams @lornajane

Slide 21

Slide 21 text

One Repo Per Deployable One codebase tracked in revision control, many deploys https://12factor.net/ @lornajane

Slide 22

Slide 22 text

One Repo Per Deployable • Keep projects independent • Separate ownership allows separate evolution • Different components can use different workflows @lornajane

Slide 23

Slide 23 text

Working With Many Repos Think about how to manage upgrades • It's hard to deploy two components at the same time reliably • Can safely add features • Breaking changes may require a new version number @lornajane

Slide 24

Slide 24 text

Build Every Platform The Same Way Keep development, staging, and production as similar as possible https://12factor.net/ @lornajane

Slide 25

Slide 25 text

Build Every Platform The Same Way Keeping platforms the same: • Use the same config mechanisms • Check for required services the same way • Use the same dependency management @lornajane

Slide 26

Slide 26 text

Managing Internal Dependencies Explicitly declare and isolate dependencies https://12factor.net/ @lornajane

Slide 27

Slide 27 text

Managing Internal Dependencies Your options are: • Keep everything in one repo • Use git's submodules or subtrees to organise dependencies • Bring in dependencies at build time @lornajane

Slide 28

Slide 28 text

Git Submodules vs Subtrees Both approaches allow keeping code in a separate repo • submodules put a nested repo into a subdirectory • subtree adds part of another repo as a first-class citizen of your current repo @lornajane

Slide 29

Slide 29 text

Surviving Submodules @lornajane

Slide 30

Slide 30 text

Surviving Submodules @lornajane

Slide 31

Slide 31 text

Surviving Submodules @lornajane

Slide 32

Slide 32 text

Surviving Submodules @lornajane

Slide 33

Slide 33 text

Manage Private Dependencies With npm: "package-name": "git+ssh://[email protected]//.git" With composer: "repositories": [ { "type": "vcs", "url": "[email protected]:vendor/my-private-repo.git" } ] @lornajane

Slide 34

Slide 34 text

Well-Organised Repositories @lornajane

Slide 35

Slide 35 text

Resources • These slides: http://lornajane.net/resources • My git book: http://gitworkbook.com/ • Twitter: @lornajane • Email: [email protected] @lornajane