to be fixed live, you have an exact copy locally • No surprise code, everyone knows what went into master and there's a neatly compressed log of it • It'll always be the first thing a new developer sees: How it works live. develop develop is a work in progress • This is where the latest work goes to when it's ready • If things break here it's fine, because it's not going anywhere yet • If you need to start on something new, you've got this fresh and untainted branch to come from features are for new work or changes • Features are where the new meat is being processed • Feature branches have 2 steps a. create, with develop as base b. merge, into develop • When you need to do something different, or new, just make a new feature branch from develop feature/... releases are controlled ships • With enough features it's time for a release branch to be made • Release branches are good for compiling, scripting, or anything needed for production (vs development) • Release branch names are also tags, so it's a snapshot (ie 6.0) release/... hotfix/... hotfixes never touch unfinished code • Hotfixes are like releases, but come from master instead of develop • Hotfix branches are the only branch to merge into master • With git-flow, you are forced to finish 1 hotfix before starting another
Checking out a co- workers problem, process, final result is trivial • Larger barrier to incomplete work • Plethoria of tools for shortcutting the process • A process exists and you must learn it • Change can be scary, and incomplete change is worse • Convincing people this works is not easy • When working solo, not much is gained for that person
of commit hook applications • Hosted wiki for docs and issue list for bug • Easy to use organizations and teams for • Very usable API for your own tools
letting you ship something • Without Github Flow any Git Flow process is useless among 10+ size teams • Bad organization management, or barriers between two groups, chokes everything • You can't be afraid to push your work, git makes it way too easy to step back • Holidays or vacations don't kill nearly as much productivity
under the same organization • Don't let anyone push directly to master • Have developers branch off of develop using a stuctured naming scheme • Grab one of those free stack overflow clones so you can store question/anmswers • Make sure contributors are discussing the pull requests both inline and in the comments section
many, but it can also be used for isolating feature work • Github is a service that hosts your repositories, but it can also be used to better communication and improve quality • Anything can start using GitTao as long as you have some form of branching and pull request system
"How Github Uses Github Flow for Github", Zach Holman • "Why aren't you using Git Flow?", Jeff Kreeftmeijer • "Streamed Lines: Branching Patterns for Parallel Software Development", Brad Appleton, Stephen Berczuk, Ralph Cabrera, and Robert Orenstein
Git • Gitlabs, which is an FOSS (and pretty) alterantive to Github, just got Pull Requests • Gitosis has a slightly better method of pull requests called "Push Requests"