Git[Hub] Tao Distributed Flow For Distributed VCS 

What We Know ● Git is recursive, so you don't have to be ● Git is concerned with changes, not files ● Git branching is very cheap, and fast ● Git makes "distributed" easy 

The Version Control Rigmarole git init master Add Commit Push Code master master master 

Kurtis Angela Now With Friends master Add Commit Push Code master master Github master master master master master master master Pull 

Bold Assumptions ● Commiters wont get moved or change tasks ● No hotfixes need to be dealt with ● Commiters only push perfect code ● The features don't change things others are working on 

"A Successful Git Branching Model" ● Decentralized, but centralized ● Feature, Hotfix, Support, Release Branches ● Rebasing, clean changelogs ● Tags for snapshots 

Git Man master master is production ● If something needs 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 

Pros & Cons ● Work is introduced from isolation ● 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 

The Missing Puzzle Piece ● Instant distributed gratification ● Cornicopia 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 

But wait, there's more! 

What We Found ● Git Flow handles flakey developers by 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 

Making The Change ● Make sure all parties are working 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 

Conclusion ● Git is a tool for distributing projects among 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 

Sources ● "A successful Git Branching model", Vincent Driessen ● "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 

Alternative Tools ● Bitbucket, which now has Pull Request and 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"