• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
How We Use GitHub
 

How We Use GitHub

on

  • 701 views

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.

Statistics

Views

Total Views
701
Views on SlideShare
425
Embed Views
276

Actions

Likes
0
Downloads
6
Comments
0

4 Embeds 276

http://nycdevshop.com 182
https://twitter.com 44
http://localhost 44
http://www.nycdevshop.com 6

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    How We Use GitHub How We Use GitHub Presentation Transcript

    • HOW WE USE GIT A Look into the NYC Devshop Git Workflow @mcnameekm Kevin McNamee: Developer kevinmcnamee
    • 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
    • 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 to Master
    • 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•
    • 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 •
    • 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 •
    • 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 •
    • 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•
    • 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 •
    • QUESTIONS? COMMENTS? SUGGESTIONS?