Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Github Tao

Github Tao

Finding the perfect balance to process and progress.

Kurtis Rainbolt-Greene

January 26, 2012
Tweet

More Decks by Kurtis Rainbolt-Greene

Other Decks in Programming

Transcript

  1. 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
  2. Kurtis Angela Now With Friends master Add Commit Push Code

    master master Github master master master master master master master Pull
  3. 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
  4. "A Successful Git Branching Model" • Decentralized, but centralized •

    Feature, Hotfix, Support, Release Branches • Rebasing, clean changelogs • Tags for snapshots
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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"