[git-users] Re: Git enterprise setup on a large project
Thomas, Daniel, Thanks a lot for sharing your experiences, this will help me a lot. I'll share my own experiences back to this list once the big work done ! Fred On Apr 4, 10:21 pm, Daniel dvdotse...@gmail.com wrote: Based on attempts to move from a similar humongous tree of code in SourceSafe to git here are my personal lessons: (this are my own notes, so i did not type this just for you) 1. Divide and conquer. - this pertains to the problem, not the code. You problems are actually separate issues: a) How do you control what gets deployed (following review by designated person) is somewhat agnostic to your code organization once you get to git. Leave changed to this steps for last. b) What version control tool you use. c) How you organize the source tree. d) How do you move devs and processes to the new structure. Here is what worked: Train, Parallel, Optimize. 1. Before you leave CVS, make sure ALL affected personnel is intimately familiar with git workflow specifically as it applies to your production code manipulation by: a) Do NOT switch to GIT. Use CVS and git concurrently by: Dev checks pulls and pushes to/from centralized CVS. On their hard drive the checked out folder structure is ONE and the same git repo (set ignore in git on all the CVS support stuff). CVS should NOT know about GIT. Trying to import all micro-level commits from GIT will muddy the water, process. Just large, occasional, stable diffs go up CVS. b) Cultivate the culture of local micro-revisions and branching, global clean commits At this stage, code is pushed vertically to CVS and laterally between devs by git format patches (in cases of shared branches) and plain patches. c) (At this stage) Don't break up the CVS structure into submodules or do anything that removes the parallel between the two. d) Don't try to make devs to push to centralized Git repo. Because of constant rebasing and history rewriting will not work. If devs don't do constant local rebasing, history rewriting, they are not using GIT well. Lack of centralized GIT structure allows devs freedom to learn GIT most efficiently. c) CVS is still you main, one and central repo. In case of fire, this is what you save and this is where you make all devs commit (albeit less regularly). Once you have a core of devs happy and familiar with micro revisions and branching and start to beg for centralized, formalized GIT repo, make sure that FIRST these champions of GIT work with others to get them on happy local micro-revisions board. Once everyone is ready undo my 1.d. rule (no centralized mainline Git repo) and make the devs maintain absolute parity (in code, not commits) between (still main) CVS and (convenience) GIT central, mainline repos. IMPORTANT NOTE: This is where your future Git repo starts. Start it right by importing CVS history into clean Git repo and making that wild public Git mirror of CVS. If devs mess up this wild public Git repo, you can always toss it restart this again and again by importing CVS history. However, if wild public Git repo has settled already, it's unsightly to rebase git history on top of new CVS import, as all hashes change. By this time, you will see that CVS is committed to, maybe, once in 2-3 days. Most of the group projects exchange format patches for group mainline branches in git. Most of the stupid commits will stay in local repos and your CVS will be in manageable state of somewhat stable. You will have A LOT of parallel efficiency gains by this time as semaphoring the code changes will not be a chore. 2. Change processes. Break down the chains. At this stable point, start changing your control process. Work out for yourself how you keep track of two - the only two - important things: what's in production right now and where can I see the latest state of all dev's 'semi-stable' work Again, divide the problem into smaller issues. I suggest to branch off this is in production now into a separate public GIT repo shared between people trusting each other to deploy production. It's the same 'tree' structure as the the one in (by now wild) CVS, mirroring dev Git repos. The flow of code goes ONLY ONE WAY: wild CVS/Git this is in production now Git. However, it allows deployment team to forget about commit parity, importing, and instead work on large, tested elsewhere patch levels. Do NOT EVER change code directly in this is in production now repo, even compile. ALL code changes to go CVS (percolate to Dev Git) and cycle back to this is in production repo as gargantuan patches, or, if deployment people are up to this, do a public clone of of wild Git repo and constantly do only pulls/merges at critical times, of specific commit / branches in wild Git. The reason you would not care about commit-level partity and tracking for this is in produciton right now repo is that you will throw it away once the wild Git repo becomes main and you move the this is
[git-users] Re: Git enterprise setup on a large project
Based on attempts to move from a similar humongous tree of code in SourceSafe to git here are my personal lessons: (this are my own notes, so i did not type this just for you) 1. Divide and conquer. - this pertains to the problem, not the code. You problems are actually separate issues: a) How do you control what gets deployed (following review by designated person) is somewhat agnostic to your code organization once you get to git. Leave changed to this steps for last. b) What version control tool you use. c) How you organize the source tree. d) How do you move devs and processes to the new structure. Here is what worked: Train, Parallel, Optimize. 1. Before you leave CVS, make sure ALL affected personnel is intimately familiar with git workflow specifically as it applies to your production code manipulation by: a) Do NOT switch to GIT. Use CVS and git concurrently by: Dev checks pulls and pushes to/from centralized CVS. On their hard drive the checked out folder structure is ONE and the same git repo (set ignore in git on all the CVS support stuff). CVS should NOT know about GIT. Trying to import all micro-level commits from GIT will muddy the water, process. Just large, occasional, stable diffs go up CVS. b) Cultivate the culture of local micro-revisions and branching, global clean commits At this stage, code is pushed vertically to CVS and laterally between devs by git format patches (in cases of shared branches) and plain patches. c) (At this stage) Don't break up the CVS structure into submodules or do anything that removes the parallel between the two. d) Don't try to make devs to push to centralized Git repo. Because of constant rebasing and history rewriting will not work. If devs don't do constant local rebasing, history rewriting, they are not using GIT well. Lack of centralized GIT structure allows devs freedom to learn GIT most efficiently. c) CVS is still you main, one and central repo. In case of fire, this is what you save and this is where you make all devs commit (albeit less regularly). Once you have a core of devs happy and familiar with micro revisions and branching and start to beg for centralized, formalized GIT repo, make sure that FIRST these champions of GIT work with others to get them on happy local micro-revisions board. Once everyone is ready undo my 1.d. rule (no centralized mainline Git repo) and make the devs maintain absolute parity (in code, not commits) between (still main) CVS and (convenience) GIT central, mainline repos. IMPORTANT NOTE: This is where your future Git repo starts. Start it right by importing CVS history into clean Git repo and making that wild public Git mirror of CVS. If devs mess up this wild public Git repo, you can always toss it restart this again and again by importing CVS history. However, if wild public Git repo has settled already, it's unsightly to rebase git history on top of new CVS import, as all hashes change. By this time, you will see that CVS is committed to, maybe, once in 2-3 days. Most of the group projects exchange format patches for group mainline branches in git. Most of the stupid commits will stay in local repos and your CVS will be in manageable state of somewhat stable. You will have A LOT of parallel efficiency gains by this time as semaphoring the code changes will not be a chore. 2. Change processes. Break down the chains. At this stable point, start changing your control process. Work out for yourself how you keep track of two - the only two - important things: what's in production right now and where can I see the latest state of all dev's 'semi-stable' work Again, divide the problem into smaller issues. I suggest to branch off this is in production now into a separate public GIT repo shared between people trusting each other to deploy production. It's the same 'tree' structure as the the one in (by now wild) CVS, mirroring dev Git repos. The flow of code goes ONLY ONE WAY: wild CVS/Git this is in production now Git. However, it allows deployment team to forget about commit parity, importing, and instead work on large, tested elsewhere patch levels. Do NOT EVER change code directly in this is in production now repo, even compile. ALL code changes to go CVS (percolate to Dev Git) and cycle back to this is in production repo as gargantuan patches, or, if deployment people are up to this, do a public clone of of wild Git repo and constantly do only pulls/merges at critical times, of specific commit / branches in wild Git. The reason you would not care about commit-level partity and tracking for this is in produciton right now repo is that you will throw it away once the wild Git repo becomes main and you move the this is in production now branch there. Once you gain procedural structure and control over the this is where most recent, semistable work is and this is in production right now Git workflow... 3. Finally, move to Git. Reapply the chains. At any point before here, you can revert back to CVS. It has your
