How We Use GitHub

  • 595 views
Uploaded 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.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
595
On Slideshare
0
From Embeds
0
Number of Embeds
5

Actions

Shares
Downloads
9
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

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