The document discusses adopting a new Git-based workflow to address problems with code quality, releases, and Kanban effectiveness. It outlines the benefits of the new workflow, including seamless releases, predictable feature flow, more efficient QA, freedom to experiment, and better tools. It then provides an overview of key Git concepts like branches and independence, differences from Subversion, and the details of the new AE workflow using feature, release, hotfix and historical branches governed by pull requests and code reviews.

1. AE Git Training
or, "Octopus merge will save your soul"

2. Agenda
Why Git
What Git is
Differences from
Subversion
Workflow Training

3. We have a problem.

4. Code quality isn't great.

5. And releases are really
hard.

6. And we can't do Kanban
effectively.

7. And too much code goes
without review.

8. ...

9. well, we have several
problems.

10. Would a new workflow
solve these problems?

12. We've built a new
workflow on Git.

13. We'll go over it all in a
sec, but...

14. We get a lot of benefits!
Seamless releases (and rollbacks!)
Safe, predictable, reliable feature flow
More efficient QA
Freedom to experiment
Better tools

15. Git Concepts

16. Git is source control.
Manage history and changes of source tree,
just like Subversion
Open source
Widely used
Bewilderingly powerful and flexible

17. Git is about branches.
Everything is a branch
Merge one, two or many branches at once
Any branch can be authoritative
Take only the parts of a branch you want

18. Git makes you
independent.
A Git server is a role, not a position
Every Git user can be a server
Everybody has the complete history
Do whatever you want without affecting
others
Fault-tolerant: if one client fails, the rest are
unaffected

19. Git/SVN differences

20. Git changes - Commits
All Git commits are local only
Saving your work (commit) and sending it to
the server (pushing) are different
operations
svn commit == git commit && git push

21. Git changes - Branches
Branches are like commits -- local only
unless/until pushed to a server
Branches are not commits
Once merged, a branch can (and usually
should) be deleted
Branches are dirt cheap -- always use them

22. Git awesome: Stash
Not Stash the server, though that also rules
Stash is a clipboard with history for your
changes
Save your uncommitted changes, then switch
branches or revert to fresh
Once you use it, you'll wonder how you ever
lived without it

23. AE Workflow

25. Historical Branches

26. Two permanent branches: master, develop
master is always releaseable and commits
to it are always tagged
develop is the integration point for new
features and the base for CI

27. Owned by QA and team leads
Only they can merge to these branches
Preserve the history of the project
Deployer operates from master

28. Feature branches

29. Feature branches implement new work
Always branched from develop
Made by developers

30. Some feature branches are abandoned
Others will merge into develop
Merges happen through pull requests and
are contingent on passing code review / QA,
and then are deleted

31. Release branches

32. Created from develop by QA or team lead
Integrate QA'd and reviewed code into
release
Plus any last-minute fixes or documentation

33. After merge to master, tagged with version
for rollback
Also merged into develop so fixes are not
lost, then deleted

34. Hotfix branches

35. For emergency fixes in production
Branched from master
Merged back into master, but also into
develop so fixes aren't lost

36. Must pass code review and QA, so also
merged with pull requests
Perfect for Kanban fixes as well

37. Last words
Detailed instructions, including how to use
Stash and SourceTree, are on the wiki
It's a big change; ask questions and read
the docs!
Ask me, Kevin or Andrew for help if you get
stuck

38. That's it!
Git is awesome
Git will make you
awesomer
New workflow makes
for better code
All is happiness

39. Pose puny questions.