Update README.md

git-flow-the-standard-git-workflow/README.md

@@ -6,3 +6,26 @@ collaboration workflow that works best for their needs. However, getting started
 from scratch can sometimes be daunting. This week we'll look at "Git-Flow", one
 of the most common workflow models. We'll discuss how it works, and how you can
 adapt it for your team's needs.
+
+## Don't Mess with The Best*
+ *\*or at least, the most popular*
+
+Git-Flow has a lot in common with development workflows from centralized version
+control systems, but enhances those ideas with some git-specific goodness. It 
+came into vogue several years ago, and the canonical reference is this blog
+post by Jeff Kreeftmeijer:
+
+* http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/
+
+### Major components of Git-Flow
+
+* Feature branches start from `develop`, and get merged back into `develop`
+* Release Candidates are refined in their own branches
+* Bugfixes in candidates also get merged into `develop`
+* Releases are **tagged commits to master** (Everybody know [how to make a tag](https://git-scm.com/book/en/v2/Git-Basics-Tagging#Annotated-Tags)?)
+* Emergency Bugfixes (aka "hotfixes") go into `master` and `develop`
+
+### Critiques of Git-Flow:
+There are simpler workflows like what [GitHub uses internally](https://guides.github.com/introduction/flow/),
+but they rely more on Continuous Integration, and may make for a more difficult
+transition for teams that are accustomed to centralized version control tools.
\ No newline at end of file