1. Effective git-flow
1.1. Get comfortable with the command line!
1.2. git plugin for git-flow
1.3. git-flow-avh
1.3.1. GitHub repository
1.3.2. Homebrew (for mac users)
1.3.3. Cygwin (for Windows users)
2. Adapting git-flow for scrum teams
2.1. PROBLEM: large, long-lived features (epics) SOLUTION: Use git-flow-avh
2.1.1. updated version of git-flow tool
2.1.2. supports sub-features (with merging back to parent feature, rather than develop)
2.1.3. some nice shortcuts
2.2. PROBLEM: QA testing of feature branches SOLUTION: Borrow idea from current model: sprint branch
2.2.1. lives only for the duration of the sprint
2.2.2. feature branches involved in the sprint are manually merged here
2.2.3. built regularly (many times a day?) and deployed to QA environment
2.2.4. at the end of the sprint, DESTROYED
3. Demo
3.1. init
3.2. create README
3.3. create feature branch
3.3.1. update README
3.3.2. commit
3.3.3. create sub-feature branch
3.3.4. add another file
3.3.5. commit
3.3.6. finish sub-feature
3.3.7. merge to sprint branch
3.3.8. finish feature
3.4. create release branch
3.4.1. do on-release bugfix
3.4.2. finish release
3.5. create hotfix branch
3.5.1. fix typo
3.5.2. finish hotfix
4. Server-branch relationships
4.1. DEV
4.1.1. Sprint
4.2. QA
4.2.1. Develop
4.3. STAGE
4.3.1. Master
4.3.2. Release
4.4. PROD
4.4.1. Master (release tag)
5. History
5.1. nvie.com
5.2. 2010
5.3. Vincent Driessen
5.4. A Successful Git Branching Model
6. Why a new branching model?
6.1. complexity
6.2. confusion
6.3. Why Aren't You Using git-flow?
7. What is git flow?
7.1. The branching model
7.1.1. Permanent branches
7.1.1.1. master
7.1.1.1.1. always reflects production
7.1.1.1.2. no commits, only merges (from release or hotfix branches)
7.1.1.1.3. tags reflect production version at each release
7.1.1.2. develop
7.1.1.2.1. "integration branch"
7.1.1.2.2. always reflects production-ready code for the next release
7.1.1.2.3. nightly builds
7.1.2. Transient branches
7.1.2.1. feature
7.1.2.1.1. naming
7.1.2.1.2. branches from
7.1.2.1.3. merges to
7.1.2.2. release
7.1.2.2.1. naming
7.1.2.2.2. branches from
7.1.2.2.3. merges to
7.1.2.3. hotfix
7.1.2.3.1. naming
7.1.2.3.2. branches from
7.1.2.3.3. merges to