Your SlideShare is downloading. ×
0
40 square's git workflow
40 square's git workflow
40 square's git workflow
40 square's git workflow
40 square's git workflow
40 square's git workflow
40 square's git workflow
40 square's git workflow
40 square's git workflow
40 square's git workflow
40 square's git workflow
40 square's git workflow
40 square's git workflow
40 square's git workflow
40 square's git workflow
40 square's git workflow
40 square's git workflow
40 square's git workflow
40 square's git workflow
40 square's git workflow
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

40 square's git workflow

3,379

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
3,379
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
34
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Transcript

    • 1. 40 Square’s GIT Workflow Who Am I?Lead developer in 40 square softwareFirst Love: 6 years in Java (omfg what was I thinking)Ex-GF: PHP hobbyist turned full time engineerWife: Node.JS, and Javascript in generalTwitter: @roguejs This will be a warp speed presentation!
    • 2. Mercurial vs GitWe used fogbugz + kiln initiallyStarted off with feature branchesMerging conflicts took foreverREAL REASON: Bad practicesHIDDEN REASON: Fogbugz is expensive...
    • 3. Other annoyancesNo dry runsDifficult to do code reviewNo cherry-pickingBad planning and structureBranching is expensive?
    • 4. Our Deployment Process LDC Dev C1 LDC B1 push hg pull CDCDev repo B Branches CDC Dev - qa C - master
    • 5. 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
    • 6. 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
    • 7. 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
    • 8. 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
    • 9. Forking Model & PolicyYour own fork is your own responsibilityFeel free to force update your own forkRebase before sending pull requests
    • 10. 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
    • 11. Typical Workflow (dev)git fetch --all (git version 1.7.x)git branch --track up-devel upstream/develgit branch P1-1305 up-develgit fetch upstream develgit checkout up-develgit merge upstream/develgit checkout P1-1305git rebase up-devel
    • 12. Typical Workflow (integrator)Integrator receives pull requestCreate a new branch in blessed repoPull update into that branchReview codeMerge into staging/devel
    • 13. Typical Workflow (Integrator)git branch soggie-P1-1305 develgit checkout soggie-P1-1305git pull soggie P1-1305git rebase develgit checkout develgit merge soggie-P1-1305git push origin devel:devel
    • 14. Overall Workflow LDC Dev C1 LDC git B1 repo push git git pull CDCDev repo integrate repo B git CDC repo Dev C
    • 15. Timeline ViewBlack line = masterBlue line = stagingGreen line = dev
    • 16. 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
    • 17. 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
    • 18. 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
    • 19. 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
    • 20. 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/

    ×