HOW WE USE GITA Look into the NYC Devshop Git Workflow

@mcnameekm

Kevin McNamee: Developerkevinmcnamee

MUCH DISCUSSION ABOUT GIT-FLOWTime

release branches masterdevelop hot!xes

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 !xed for

production:hot!x 0.2

Bug!xes from rel. branch

may be continuously merged back into develop

Tag

0.1

Tag

0.2

Incorporate bug!x in develop

Only bug!xes!

Start of release

branch for1.0

Author: Vincent DriessenOriginal blog post: http://nvie.com/posts/a-succesful-git-branching-model

License: Creative Commons BY-SA

Infinite BranchesMaster•Develop•

Feature BranchesFeature•

*create your feature

Release•Supports preparation of new production release

Hotfix•Branch off of master to fix urgent bugs.

https://github.com/nvie/gitflowhttp://nvie.com/posts/a-successful-git-branching-model/Author: Vincent Driessen

WE BUILT A WEBSITE!

And we re-flavored our workflow

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 toMaster

MANY MANY FEATUREBRANCHES

Each feature is checked out locally with a declarativelynamed 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•

EXPLICIT BRANCH NAMINGBranches allow each of us to see what features are

currently in development•

Git fetch will pull down all current branches in activedevelopment•

COMMIT EARLY & OFTEN

We constantly commit andpush our code•

Small team; Small iterations;Big fun•

Feature branches are neverdeployed so no worries onpushing buggy code

•

YOU NO MERGE OWN PULL REQUEST

All feature merges into master aredone through peer review•

No hierarchy. Anybody can reviewand merge•

Do not merge your own commits elseyou will be hurt•

Pull request is merged when featureis complete. Zero Exceptions•

You delete branch in order to keep allfeatures active•

WE ALSO USE PULL REQUESTS FOR

Questions about featureimplementation•

Ad hoc code review•

Pull request doesn’t necessarily needto be merged•

Open a discussion thread for feature•

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 gooddocumentation•

QUESTIONS?

COMMENTS?

SUGGESTIONS?