Intro to Gitflow

Preview:

DESCRIPTION

Presentation from late 2013 introducing Git and Gitflow to my team.

Citation preview

AE Git Trainingor, "Octopus merge will save your soul"

Agenda

Why Git

What Git is

Differences from Subversion

Workflow Training

We have a problem.

Code quality isn't great.

And releases are really hard.

And we can't do Kanban effectively.

And too much code goes without review.

...

well, we have several problems.

Would a new workflow solve these problems?

We've built a new workflow on Git.

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

We get a lot of benefits!

Seamless releases (and rollbacks!)

Safe, predictable, reliable feature flow

More efficient QA

Freedom to experiment

Better tools

Git Concepts

Git is source control.

Manage history and changes of source tree, just like Subversion

Open source

Widely used

Bewilderingly powerful and flexible

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

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

Git/SVN differences

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

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

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

AE Workflow

Historical Branches

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

Owned by QA and team leads

Only they can merge to these branches

Preserve the history of the project

Deployer operates from master

Feature branches

Feature branches implement new work

Always branched from develop

Made by developers

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

Release branches

Created from develop by QA or team lead

Integrate QA'd and reviewed code into release

Plus any last-minute fixes or documentation

After merge to master, tagged with version for rollback

Also merged into develop so fixes are not lost, then deleted

Hotfix branches

For emergency fixes in production

Branched from master

Merged back into master, but also into develop so fixes aren't lost

Must pass code review and QA, so also merged with pull requests

Perfect for Kanban fixes as well

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

Last words

That's it!

Git is awesome

Git will make you awesomer

New workflow makes for better code

All is happiness

Pose puny questions.

Recommended