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

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 :
    luke.stringer@3squared.com
    Twitter / GitHub: lukestringer90
    

    View Slide