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
2. 2008 - 2012 MEng Software Engineering
4. I’m the Head of Development at 3Squared
8. Version Control is Key to our Success !
9. Who has used a Version Control System? "
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.
11. We use Git
12. Git is a Distributed Version Control System (DVCS) #
13. Designed for Linux Development
14. I'm an egotistical bastard, and I name all my projects after myself. First 'Linux', now 'git'. - Linus Torvalds
15. It has Lots of Benefits $ It allows us to…
16. Backup our Work %
17. Work as a Team &
18. Work Offline ✈
19. Do things Fast ⚡
20. Identify, Diagnose & Fix Bugs ()
21. Bug!
22. Bug! git bisect
23. Bad
24. Good Bad
25. Step 1 Good Bad
26. Good Bad Step 1 Bad
27. Step 2 Good Bad
28. Step 2 Good Good Bad
29. Good Bad Step 3
30. Good Bad Step 3 Good
31. Good Bad First Bad Commit
32. Be Flexible *
33. But…
34. With Great Power comes Great Responsibility
35. Effective Team Work requires Rules +
36. Write descriptive Commit Messages ✏ Explain why you did something
37. Commit Early & Commit Often -
38. Follow a Branching Policy .
39. We use Git-Flow
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.
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.
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.
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.
45. http://nvie.com/posts/a-successful-git-branching-model/
49. Git & Git-Flow Caveats ⚠
50. A Release contains all Completed Features 0
51. Merge Conflicts will occur 1 so approach them in the right way…
52. Communicate with your Team 2 to minimise changes to the same file across branches
53. Prevent Feature Divergence 3 by periodically merging develop into feature branches
55. Potentially nasty merge conflicts
56. Smaller merge conflicts Smaller merge conflicts
58. Collaboration requires Connectivity 4
59. Use a Centralised “Truth” Repository 5
63. Git Repositories Hosted Internally 6
64. Merge Requests used for Code Review 7
65. develop feature branches
66. develop feature branches 8
67. develop feature branches ? Merge Request = code review 8
68. develop feature branches 8
69. develop feature branches ? Merge Request = code review 8
70. develop feature branches Merge Request accepted 8
71. Branches form basis for Deployments 9
72. 9!QA 9!QA 9!QA 9!QA
73. 9!Stag 9!Stag 9!Stag 9!Prod
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
75. Thank You : luke.stringer@3squared.com Twitter / GitHub: lukestringer90