Bureaucrats, confirmed, Administrators
4,558
edits
Changes
Git/migrating to git (view source)
Revision as of 19:14, 24 September 2015
, 19:14, 24 September 2015minor tweaks
<li> Plan and structure your Git space
<li> Decide what to do with your existing code
<ol> <li> Archive your current CVS or SVN repository <li> Import your history into git </ol>
<li> Do the migration.
<ol> <li>Map users <li>Migrations must include at least the following details <ol> <li> Migration timeline <li> mapping of current code to new Git repos <li> decision regarding existing code (archive or import) <li> A description for each repository (which will be visible in the web view) </ol> <li>Use scripted recipes for LARGE migrations <ref>[https://github.com/maxandersen/jbosstools-gitmigration Max Anderson's recipe for migration of the JBoss Tools repos]</ref> </ol>
<li> Importing your SVN history into Git
<ol> <li> Using svn2git on a remote server <li> Using svn2git on build.eclipse.org </ol>
<li> Convert svn:ignore properties to .gitignore file (example of why you need to later delete empty commits which reflect properties not code changes)
<li> Git Team Provider for Eclipse / Developer Tools setup / Client and End User configurations <ol> <li> Create keys, add each to client and server <li> Install / setup TortoiseGit for Windows <li> Add EGit to Eclipse <li> [https://netbeans.org/kb/73/ide/git.html Netbeans natively supports Git] since v7.1 </ol>
<li> Repository permissions and group definitions, key imports
<li> Establish Git Resources
<li> Create Git Task Force
<li> Update references in your product brochuresliterature, project documents, websites, systems, reference materials and procedure documents to reference the new systems. This step can be ameliorated if in the beginning you reference code in a generic way such as "code.example.com" where you can then link to various aspects and implementations of your code systems; rather than naming them specifically based on technology or implementation.
</ol>