Moving to Git

Editor's Notes

• #2: \n
• #3: Our Subversion workflow: how it worked and why we wanted to switch\nOur migration process: how we made the switch to Git without disruption\nOur Git workflow: what we changed and why it's better now\n
• #4: Most commits go to trunk\n
• #5: Most commits go to trunk\n
• #6: When we need to do a release, we would freeze trunk\nand create a stable branch to release from\n
• #7: When we need to do a release, we would freeze trunk\nand create a stable branch to release from\n
• #8: Update version on the stable branch\nTag it\n
• #9: Unfreeze trunk\n
• #10: Keep committing there\nThis is good for the ideal situation: everything on trunk is good, stable doesn’t need to change\n
• #11: Now nobody can commit at all\nCan’t release until it’s fixed\n\nWe tried topic branches to reduce risk on trunk, but ran into frequent conflicts\nMerge hell\n
• #12: What about a bug on stable?\n
• #13: You have to fix it on stable\n
• #14: Bump the version, tag and release\n
• #15: Merge to trunk\nPray there are no conflicts\nIf the intervening commit changed something on trunk that changed on the branch, you’re in merge hell\nThe merge doesn’t explicitly track the second parent\nIf you need to merge again from the branch, you’re in merge hell\n
• #16: Subversion handles conflicts more poorly than DVCS tools\nThis svn development workflow increases mistakes\nWe’ve had dependencies go backwards\nTree conflicts\nSemantic conflicts: think about tests\nConflicts are often resolved on trunk\nSometimes you forget to merge changes on branches\nSubversion doesn’t visualise branches well\nSubversion doesn’t track merges well\nSome clients don’t work with merge tracking—bolted on\n\nWe needed to escape\nWanted to move to a workflow where risky changes are isolated\nWithout risking constant merge hell\n
• #17: \n
• #18: Get to know git first\nMinimize time that devs can’t commit\nKeep builds running\nKeep code reviews\nEnsure you can always release\nDon’t change process at the same time—wait until after you migrate\nLeave time/flexibility in your plan to deal with unforeseen issues\n
• #19: \n
• #20: \n
• #21: \n
• #22: \n
• #23: Migration Algorithm: similar to blue-green deploy model, or database replication\nConvert svn repo to git\nMirror svn to git as a read-only copy\nMigrate tools first (readers)\nMigrate people last (writers)\nLook at the converted repo, make sure it makes sense\nClean up tags\nNo hierarchical branches\nConsider trimming\nPrivate branches\nLarge objects in single branches\nConsider archive repo\nNever commit/push directly to this: use for mirroring only\nConsider periodically pushing this repo to a separate remote repo\n
• #24: Migration Algorithm: similar to blue-green deploy model, or database replication\nConvert svn repo to git\nMirror svn to git as a read-only copy\nMigrate tools first (readers)\nMigrate people last (writers)\nLook at the converted repo, make sure it makes sense\nClean up tags\nNo hierarchical branches\nConsider trimming\nPrivate branches\nLarge objects in single branches\nConsider archive repo\nNever commit/push directly to this: use for mirroring only\nConsider periodically pushing this repo to a separate remote repo\n
• #25: Migration Algorithm: similar to blue-green deploy model, or database replication\nConvert svn repo to git\nMirror svn to git as a read-only copy\nMigrate tools first (readers)\nMigrate people last (writers)\nLook at the converted repo, make sure it makes sense\nClean up tags\nNo hierarchical branches\nConsider trimming\nPrivate branches\nLarge objects in single branches\nConsider archive repo\nNever commit/push directly to this: use for mirroring only\nConsider periodically pushing this repo to a separate remote repo\n
• #26: Migration Algorithm: similar to blue-green deploy model, or database replication\nConvert svn repo to git\nMirror svn to git as a read-only copy\nMigrate tools first (readers)\nMigrate people last (writers)\nLook at the converted repo, make sure it makes sense\nClean up tags\nNo hierarchical branches\nConsider trimming\nPrivate branches\nLarge objects in single branches\nConsider archive repo\nNever commit/push directly to this: use for mirroring only\nConsider periodically pushing this repo to a separate remote repo\n
• #27: Migration Algorithm: similar to blue-green deploy model, or database replication\nConvert svn repo to git\nMirror svn to git as a read-only copy\nMigrate tools first (readers)\nMigrate people last (writers)\nLook at the converted repo, make sure it makes sense\nClean up tags\nNo hierarchical branches\nConsider trimming\nPrivate branches\nLarge objects in single branches\nConsider archive repo\nNever commit/push directly to this: use for mirroring only\nConsider periodically pushing this repo to a separate remote repo\n
• #28: Migration Algorithm: similar to blue-green deploy model, or database replication\nConvert svn repo to git\nMirror svn to git as a read-only copy\nMigrate tools first (readers)\nMigrate people last (writers)\nLook at the converted repo, make sure it makes sense\nClean up tags\nNo hierarchical branches\nConsider trimming\nPrivate branches\nLarge objects in single branches\nConsider archive repo\nNever commit/push directly to this: use for mirroring only\nConsider periodically pushing this repo to a separate remote repo\n
• #29: Migration Algorithm: similar to blue-green deploy model, or database replication\nConvert svn repo to git\nMirror svn to git as a read-only copy\nMigrate tools first (readers)\nMigrate people last (writers)\nLook at the converted repo, make sure it makes sense\nClean up tags\nNo hierarchical branches\nConsider trimming\nPrivate branches\nLarge objects in single branches\nConsider archive repo\nNever commit/push directly to this: use for mirroring only\nConsider periodically pushing this repo to a separate remote repo\n
• #30: Post-commit hook in Subversion\nCron job on a machine hosting the conversion repo\nCI server\n
• #31: \n
• #32: \n
• #33: \n
• #34: \n
• #35: \n
• #36: \n
• #37: \n
• #38: \n
• #39: \n
• #40: \n
• #41: \n
• #42: \n
• #43: \n
• #44: Move tools one at a time\nStart with a separate CI plan\nMake sure its behaviour matches the normal one\nHow to decide when to pass here?\nMove normal one when you’re confident\nYou might want to hold off on automated release builds until later, but test them now\nCode review/source browsing/searching\nDashboards\n
• #45: All at once\nTry to get everyone committed, otherwise need to use patches\nCode freeze svn\nClone remote git repo\nYou’re off!\n
• #46: \n
• #47: \n
• #48: \n
• #49: \n
• #50: \n
• #51: \n
• #52: Consider leaving the original svn repo running, read-only to avoid breaking links\nOnly change process after you're comfortable with the new tools\n
• #53: \n
• #54: We release from master directly\nMaster is the stable branch\n
• #55: We put changes on a branch\nIssue key (for traceability)\nTextual description (for readability)\nProtip: use git bash completion\n
• #56: We do reviews and QA on the branch\n
• #57: When the branch is ready to release, we do a fast-forward merge to master\n
• #58: Fast-forwarding ensures no untested commits hit master\n
• #59: \n
• #60: Simultaneous features are on separate branches\n
• #61: Can keep committing to topic branches while master is merged and released\n
• #62: New commits on master are merged to active topic branches\n
• #63: Merge commits are tested on the branch\n
• #64: Fast-forward master when it’s ready to release\n\nmaster is always stable & releasable\nchanges & merges are always tested before hitting master\nbalances continuous integration with scalability & safety\n
• #65: \n