Commit 4de9efe7 authored by French, Robert's avatar French, Robert
Browse files

Update README.md

parent be1ddb46
......@@ -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
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment