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...
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 mas...
MANY MANY FEATURE
BRANCHES
Each feature is checked out locally with a declaratively
named branch
•
Commit early and commit...
EXPLICIT BRANCH NAMING
Branches allow each of us to see what features are
currently in development
•
Git fetch will pull d...
COMMIT EARLY & OFTEN
We constantly commit and
push our code
•
Small team; Small iterations;
Big fun
•
Feature branches are...
YOU NO MERGE OWN PULL REQUEST
All feature merges into master are
done through peer review
•
No hierarchy. Anybody can revi...
WE ALSO USE PULL REQUESTS FOR
Questions about feature
implementation
•
Ad hoc code review•
Pull request doesn’t necessaril...
README FOR EVERY PROJECT
We create a detailed readme for each project•
We each have different ways of creating seed data•
...
QUESTIONS?
COMMENTS?
SUGGESTIONS?
Upcoming SlideShare
Loading in...5
×

How We Use GitHub

712

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.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
712
On Slideshare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
10
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "How We Use GitHub"

  1. 1. HOW WE USE GIT A Look into the NYC Devshop Git Workflow @mcnameekm Kevin McNamee: Developer kevinmcnamee
  2. 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. 3. WE BUILT A WEBSITE! And we re-flavored our workflow
  4. 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. 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. 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. 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. 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. 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. 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. 11. QUESTIONS? COMMENTS? SUGGESTIONS?
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×