In a community setting here at WeWork Labs in NYC, Kevin McNamee, our lead developer, presented an introductory course on adding git best practices to your team's dev workflow.

1. HOW WE USE GIT
A Look into the NYC Devshop Git Workflow
@mcnameekm
Kevin McNamee: Developer
kevinmcnamee

2. MUCH DISCUSSION ABOUT GIT-FLOWTime
release
branches masterdevelop hotfixes
feature
branches
Feature
for future
release
Tag
1.0
Major
feature for
next release
From this point on,
“next release”
means the release
after 1.0
Severe bug
fixed for
production:
hotfix 0.2
Bugfixes from
rel. branch
may be
continuously
merged back
into develop
Tag
0.1
Tag
0.2
Incorporate
bugfix in
develop
Only
bugfixes!
Start of
release
branch for
1.0
Author: Vincent Driessen
Original blog post: http://nvie.com/posts/a-succesful-git-branching-model
License: Creative Commons BY-SA
Infinite Branches
Master•
Develop•
Feature Branches
Feature•
*create your feature
Release•
Supports preparation of new production release
Hotfix•
Branch off of master to fix urgent bugs.
https://github.com/nvie/gitflow
http://nvie.com/posts/a-successful-git-branching-model/
Author: Vincent Driessen

3. WE BUILT A WEBSITE!
And we re-flavored our workflow

4. ONE INFINITE BRANCH... MASTER
We never push directly to master
We don’t merge our own branches into master
All code on master should be production ready and
deployable at anytime
•
•
•
Pushed to
Master

5. MANY MANY FEATURE
BRANCHES
Each feature is checked out locally with a declaratively
named branch
•
Commit early and commit often•
Pull requests are merged when feature is complete•
Peer review for all pull requests•
You delete your own feature branch•
Reviewer merges request•

6. EXPLICIT BRANCH NAMING
Branches allow each of us to see what features are
currently in development
•
Git fetch will pull down all current branches in active
development
•

7. COMMIT EARLY & OFTEN
We constantly commit and
push our code
•
Small team; Small iterations;
Big fun
•
Feature branches are never
deployed so no worries on
pushing buggy code
•

8. YOU NO MERGE OWN PULL REQUEST
All feature merges into master are
done through peer review
•
No hierarchy. Anybody can review
and merge
•
Do not merge your own commits else
you will be hurt
•
Pull request is merged when feature
is complete. Zero Exceptions
•
You delete branch in order to keep all
features active
•

9. WE ALSO USE PULL REQUESTS FOR
Questions about feature
implementation
•
Ad hoc code review•
Pull request doesn’t necessarily need
to be merged
•
Open a discussion thread for feature•

10. README FOR EVERY PROJECT
We create a detailed readme for each project•
We each have different ways of creating seed data•
Step by step setup as if each project was OS•
Flexible schedules, flexible coding styles means good
documentation
•

11. QUESTIONS?
COMMENTS?
SUGGESTIONS?