Mercurial vs GitWe used fogbugz + kiln initiallyStarted off with feature branchesMerging conflicts took foreverREAL REASON: Bad practicesHIDDEN REASON: Fogbugz is expensive...
Other annoyancesNo dry runsDifficult to do code reviewNo cherry-pickingBad planning and structureBranching is expensive?
Our Deployment Process LDC Dev C1 LDC B1 push hg pull CDCDev repo B Branches CDC Dev - qa C - master
Deployment ProblemsAccidentally merge into master? RED ALERTQA testing on old codeDev: “Is my feature merged yet?”Lead: “Hold on, I’m fixing conflict #13285582309583” live dev1 invalidates previous test dev2
Why Git?Because github is sexyActually, because it’s cheaper than KilnWhy not bitbucket?Because github is sexy, and because I said soActually, because github still is cheaper (repo vs users)Git has more options for branching and merging
Our GoalsHave a staging server that is a clone of live serverAbstract devs from live serverNo more “it’s just one line of code, can I push to livedirectly?”Rapid deployment and lesser merge conflictsBuild better practices
Vincent Driessen Model 40 square styleLong Running Branches: master - live servers staging - last line of defense devel - weekly deploymentsDistributed blessed repo model Blessed repo managed by integrators Each dev gets own fork
Forking Model & PolicyYour own fork is your own responsibilityFeel free to force update your own forkRebase before sending pull requests
Typical Workflow (dev)Dev starts work on an issue in PivotalDetermine what kind of issue: P1- branch off from staging Bugs & Features - branch off from develPull upstream often and rebase on upstreamRebase again before sending pull request
Overall Workflow LDC Dev C1 LDC git B1 repo push git git pull CDCDev repo integrate repo B git CDC repo Dev C
Timeline ViewBlack line = masterBlue line = stagingGreen line = dev
Devel branch deploymentEvery MONDAY, merge to stagingOnce testing completes, tag and merge to masterIf testing fails, all bug fixes are designated as P1Bug fixes for release candidate is merged into staging master fail staging fix devel
Staging branch deploymentMerge to staging and testOnce QA approves it, merge to master AND develPolicy: Only one commit allowed to dangle master never!!! staging devel
PoliciesDo NOT force update blessed repo I will hunt you down, and kill youAlways rebase before sending pull requestIf P1, branch off staging. Otherwise, branch off develManage pull requests NOWNo dangling commits on staging
BenefitsEstablished workflow = peaceful work environmentPredictable integration & deploymentConflicts = dev responsibility instead of integrator’sCan dick around with own repo without killing blessedrepoNo more unpredictable testing environment
More InformationA successful branching modelhttp://nvie.com/posts/a-successful-git-branching-model/Githttp://git-scm.com/Githubhttp://github.com/Git video tutorialshttp://gitcasts.com/