Your SlideShare is downloading. ×
How We Use GitHub
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

How We Use GitHub


Published on

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.

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.

Published in: Technology

  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 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: 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. 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 •