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

Get Good with Git

Luke Stringer
December 06, 2018

Get Good with Git

Using Version Control to Deliver Quality Software.

A look into how 3Squared use version control to enable collaboration, ensure code quality, fix bugs, and ultimately release software.

Delivered at The University of Sheffield as part of the Institute of Coding talks

Luke Stringer

December 06, 2018
Tweet

More Decks by Luke Stringer

Other Decks in Technology

Transcript

  1. Get Good with Git
    Using Version Control to Deliver Quality Software

    View Slide

  2. 2008 - 2012
    MEng Software
    Engineering

    View Slide

  3. View Slide

  4. I’m the
    Head of
    Development
    at 3Squared

    View Slide

  5. View Slide

  6. View Slide

  7. View Slide

  8. Version Control is
    Key to our Success !

    View Slide

  9. Who has used a
    Version Control System? "

    View Slide

  10. Version control is a system that
    records changes to a file or set
    of files over time so that you
    can recall specific versions
    later.

    View Slide

  11. We use Git

    View Slide

  12. Git is a Distributed
    Version Control
    System (DVCS) #

    View Slide

  13. Designed for
    Linux
    Development

    View Slide

  14. I'm an egotistical bastard, and
    I name all my projects after
    myself. First 'Linux', now 'git'.
    - Linus Torvalds

    View Slide

  15. It has
    Lots of Benefits $
    It allows us to…

    View Slide

  16. Backup our Work %

    View Slide

  17. Work as a Team &

    View Slide

  18. Work Offline ✈

    View Slide

  19. Do things Fast ⚡

    View Slide

  20. Identify, Diagnose &
    Fix Bugs ()

    View Slide

  21. Bug!

    View Slide

  22. Bug!
    git bisect

    View Slide

  23. Bad

    View Slide

  24. Good
    Bad

    View Slide

  25. Step 1
    Good
    Bad

    View Slide

  26. Good
    Bad
    Step 1
    Bad

    View Slide

  27. Step 2
    Good
    Bad

    View Slide

  28. Step 2
    Good
    Good
    Bad

    View Slide

  29. Good
    Bad
    Step 3

    View Slide

  30. Good
    Bad
    Step 3
    Good

    View Slide

  31. Good
    Bad
    First Bad
    Commit

    View Slide

  32. Be Flexible *

    View Slide

  33. But…

    View Slide

  34. With Great Power
    comes Great
    Responsibility

    View Slide

  35. Effective Team Work
    requires Rules +

    View Slide

  36. Write descriptive
    Commit Messages ✏
    Explain why you did something

    View Slide

  37. Commit Early &
    Commit Often -

    View Slide

  38. Follow a
    Branching Policy .

    View Slide

  39. We use Git-Flow

    View Slide

  40. The Main Branches
    • master represents code in a
    production ready state.
    • Each commit on master is
    tagged with a release
    number
    • develop represents code
    for the next release.

    View Slide

  41. Feature Branches
    • Developing features for the
    next release.
    • Branch from: develop
    • Merge into: develop
    • Named: feature/_, e.g.
    feature/login
    • Multiple features can be
    worked on in parallel by
    the team.

    View Slide

  42. View Slide

  43. Release Branches
    • Prepare for production when
    all features are complete.
    • Branch from: develop
    • Merge into: develop &
    master
    • Named: release/_, e.g.
    release/1.0.1
    • Only one release at a time.
    • Merge with master is tagged
    with the release number.

    View Slide

  44. Hotfix Branches
    • Used to quickly react to
    critical bugs in production.
    • Branch from: master
    • Merge into: develop &
    master
    • Named: hotfix/_, e.g.
    release/1.2.1
    • Other team member can
    carry on with feature work.

    View Slide

  45. http://nvie.com/posts/a-successful-git-branching-model/

    View Slide

  46. View Slide

  47. View Slide

  48. View Slide

  49. Git & Git-Flow
    Caveats ⚠

    View Slide

  50. A Release contains all
    Completed Features 0

    View Slide

  51. Merge Conflicts
    will occur 1
    so approach them in the right way…

    View Slide

  52. Communicate with
    your Team 2
    to minimise changes to the same file across
    branches

    View Slide

  53. Prevent Feature
    Divergence 3
    by periodically merging develop into
    feature branches

    View Slide

  54. View Slide

  55. Potentially nasty merge conflicts

    View Slide

  56. Smaller merge conflicts
    Smaller merge conflicts

    View Slide

  57. View Slide

  58. Collaboration requires
    Connectivity 4

    View Slide

  59. Use a Centralised
    “Truth” Repository 5

    View Slide

  60. View Slide

  61. View Slide

  62. View Slide

  63. Git Repositories
    Hosted Internally 6

    View Slide

  64. Merge Requests used
    for Code Review 7

    View Slide

  65. develop
    feature
    branches

    View Slide

  66. develop
    feature
    branches
    8

    View Slide

  67. develop
    feature
    branches
    ? Merge Request = code review
    8

    View Slide

  68. develop
    feature
    branches
    8

    View Slide

  69. develop
    feature
    branches
    ? Merge Request = code review
    8

    View Slide

  70. develop
    feature
    branches
    Merge Request accepted
    8

    View Slide

  71. Branches form basis
    for Deployments 9

    View Slide

  72. 9!QA
    9!QA
    9!QA
    9!QA

    View Slide

  73. 9!Stag
    9!Stag
    9!Stag
    9!Prod

    View Slide

  74. Summary
    • Git is enables fast, flexible collaborative software
    development
    • Bug-fixing is made easier with git bisect
    • With Great Power comes Great Responsibility
    • Following a branching policy like Git-Flow standardises
    development & deployment processes
    !"#$%&✈⚡ ()* +✏ -.⚠ 0 1 2 3 4 6 7 9

    View Slide

  75. Thank You :
    [email protected]
    Twitter / GitHub: lukestringer90

    View Slide