|
1 | 1 | --- |
2 | 2 | layout: cheat-sheet |
3 | | -title: Transitioning from Subversion to Git and GitHub |
4 | | -byline: When migrating from Subversion to Git, there's a vocabulary and command set to learn, in addition to the new capabilities only afforded by a DVCS such as Git. This cheat sheet aims to help you in your transition between the classic Subversion technology and the modern use of Git with the GitHub collaboration platform. |
| 3 | +title: Subversion to Git Migration |
| 4 | +byline: When migrating from Subversion to Git, there’s a vocabulary and command set to learn, in addition to the new capabilities only afforded by Git. This cheat sheet aims to help you in your transition between the classic Subversion technology and the modern use of Git with the GitHub collaboration platform. |
5 | 5 | --- |
6 | 6 |
|
7 | | -# Transitioning from Subversion to Git and GitHub |
8 | | - |
9 | | -When migrating from Subversion to Git, there's a vocabulary and command set to learn, in addition to the new capabilities only afforded by a DVCS such as Git. This cheat sheet aims to help you in your transition between the classic Subversion technology and the modern use of Git with the GitHub collaboration platform. |
| 7 | +{% capture migration %} |
| 8 | +## Migrating |
| 9 | +### GitHub importer |
10 | 10 |
|
11 | | -## Vocabulary |
| 11 | +For Internet-accessible projects, GitHub.com provides Importer for automatic migration and repository creation from Subversion, Team Foundation Server, Mercurial, or alternatively-hosted Git version controlled projects. |
12 | 12 |
|
13 | | -| Git command | SVN | SVN equivalent | Git Behavior | |
14 | | -|---|---|---|---| |
15 | | -| `status` | ✓ | | Report the state of working tree | |
16 | | -| `add` | ✓ | | Required for each path before making a commit | |
17 | | -| `commit` | ✓ | | Store prepared changes in local revision history | |
18 | | -| `rm` | ✓ | `rm`, `delete` | Prepare paths for deletion in next commit | |
19 | | -| `mv` | ✓ | `move` | Prepare relocated content for next commit | |
20 | | -| `branch` | ✓ | | Create local context for commits | |
21 | | -| `checkout` | ✓ | | Switch branches, or rewrite working tree from commit | |
22 | | -| `merge` | ✓ | | Join branch histories and changes to working tree | |
23 | | -| `log` | ✓ | | No network required | |
24 | | -| `clone` | ✗ | `checkout` | Acquire the entire history of a project locally for the first time | |
25 | | -| `push` | ✗ | `commit` | Upload commit history to GitHub/centralized Git host | |
26 | | -| `pull` | ✗ | | Download and integrate GitHub repository history with local one | |
27 | | -| `fetch` | ✗ | | Download GitHub repository history with no other action | |
| 13 | +The process is as simple, needing only you to sign into your GitHub account, if you aren’t already, entering your existing project’s version control URL in the repository field, and initiating the conversion. |
28 | 14 |
|
29 | | -**Key:** ✓ yes, ✗ no |
| 15 | +Depending on the detected version control system, Importer may request additional information for migration. This includes a mapping file for associating Subversion usernames with Git fields. |
30 | 16 |
|
31 | | -## Leveraging Git's support of SVN |
32 | | -During a VCS change, there may be a need to begin using Git locally while the hosted repositories remain under Subversion control. The `git svn` command and sub-commands provide the ability to interact with Subversion's repositories while using all the benefits of Git on the command line or with graphical clients. |
| 17 | +Begin migrating repositories by visiting the Importer home page: |
33 | 18 |
|
34 | | -Acquire an SVN repository, with a resulting Git repository locally: |
| 19 | +[https://importer.github.com](https://importer.github.com) |
35 | 20 |
|
36 | | -`git svn clone [svn-repo-url]` |
| 21 | +### SVN2Git Utility |
37 | 22 |
|
38 | | -**Note:** Keep in mind the *layout* of the SVN repository and whether this follows the standard pattern or not. If the Subversion repository follows the traditional `trunk`, `branches`, and `tags` pattern, supply the `--std-layout` option. When the Subversion repository is non-standard or organized in a more custom structure, the following options switches should be specified during the clone: |
| 23 | +When access limitations or non-public Subversion repositories need porting to Git, the SVN2Git utility is the command line utility of choice and provides control through every step of the process. |
39 | 24 |
|
40 | | -* `-T [trunk]` for alternate main source convention |
41 | | -* `-b [branches]` for alternate branch location |
42 | | -* `-t [tags]` for alternate tag structure location |
| 25 | +Subversion presents distinct differences in structure to that of a Git repository, and SVN2Git provides the flexibility and configuration for traditional and custom Subversion layouts. This ensures the resulting Git repository aligns with standard best practices for commits, branches, and tags for the entire project’s history. |
43 | 26 |
|
44 | | -Once the clone operation completes, you can proceed with any standard Git interactions, commands and processes. |
| 27 | +Notable features of SVN2Git include: |
45 | 28 |
|
46 | | -## Synchronizing with SVN repository |
| 29 | +- Converting all SVN conventions to traditional Git structure |
| 30 | +- Providing SVN users field to name and email data in Git commits |
| 31 | +- Permiting exclusion patterns for precise Git repository content |
47 | 32 |
|
48 | | -Once local history within a `git svn clone` repository has occurred, the commits must be published to the Subversion repository. |
| 33 | +Learn more about SVN2Git at the project’s official home page: |
49 | 34 |
|
50 | | -`git svn dcommit` |
| 35 | +[https://github.com/nirvdrum/svn2git](https://github.com/nirvdrum/svn2git) |
| 36 | +{% endcapture %} |
51 | 37 |
|
52 | | -If the Subversion repository has commits not yet on the local Git-equivalent, a `rebase` must first be performed. |
| 38 | +<div class="col-md-6"> |
| 39 | +{{ migration | markdownify }} |
| 40 | +</div> |
53 | 41 |
|
54 | | -`git svn rebase` |
| 42 | +{% capture bridging %} |
| 43 | +## Bridging |
55 | 44 |
|
56 | | -Keep in mind this rewrites local Git history and your Git commit refs will be different than before the command is run. |
| 45 | +### Leveraging Git’s support of SVN |
57 | 46 |
|
58 | | -## Subversion tooling bridge via GitHub |
| 47 | +Often times, during a transition to Git, the Subversion infrastructure remains in place while users become acquianted with local Git repository interactions, local workflows, and desktop applications. |
59 | 48 |
|
60 | | -For users familiar with Subversion toolsets and clients, [GitHub fully supports and bridges communications to the central repository](https://help.github.com/articles/support-for-subversion-clients/). All Subversion commits directed at a GitHub hosted repository will be automatically converted to Git commits. |
| 49 | +The `git svn` command permits users to synchronize with a centralized Subversion repository host while taking advantage of all the benefits local Git command line and graphical clients have to offer. |
61 | 50 |
|
62 | | -* [Topics about branch strategies with SVN](https://github.com/blog/1178-collaborating-on-github-with-subversion) |
63 | | -* Patterns for updating `trunk` or GitHub default branch equivalent |
| 51 | +To acquire a Subversion repository as a resulting local Git repository, download the project in its entirety with this command: |
64 | 52 |
|
| 53 | +``` |
| 54 | +git svn clone [svn-repo-url] --std-layout |
| 55 | +``` |
65 | 56 |
|
66 | | -## Migrating |
| 57 | +Make certain you are familiar with the targeted Subversion repository’s structure and whether it follows the standard layout or not. For non-traditional `trunk`, `branches`, and `tags` layouts, the following option switches should be specified during the `svn clone`: |
67 | 58 |
|
68 | | -The use of `git svn` should be a temporary bridge and complete migration to Git repositories for both local and upstream destinations is optimal. |
| 59 | +- `T [trunk]` for alternate main source convention |
| 60 | +- `b [branches]` for alternate branch location |
| 61 | +- `t [tags]` for alternate tag structure location |
69 | 62 |
|
70 | | -The most lightweight approach is by utilizing `git svn` as a one-time conversion from Subversion to Git repository. To migrate a Subversion repository, several aspects must be ensured: |
| 63 | +Once the clone operation completes, you can proceed with any local Git interactions on the command line or with graphical clients. |
71 | 64 |
|
72 | | -* Subversion commits cease prior to initiating the process |
73 | | -* One machine serves as intermediary during conversion |
74 | | -* GitHub "upstream" repository initialized and ready to receive history, branches, tags |
| 65 | +### Synchronizing with Subversion |
75 | 66 |
|
76 | | -### Git-SVN conversion method |
77 | | -* Create email/username mapping file |
78 | | -* Begin `git svn clone` |
79 | | -* Add `git remote add origin [GitHub-URL]` |
| 67 | +Publishing local Git history back to a central Subversion repository acquired with git svn clone is performed with one command: |
80 | 68 |
|
81 | | -Run each `ref` publish separately: |
| 69 | +``` |
| 70 | +git svn dcommit |
| 71 | +``` |
82 | 72 |
|
83 | | -* Run `git push --all origin` |
84 | | -* Run `git push --tags origin` |
| 73 | +If the hosted Subversion repository’s history possesses commits not yet in the local Git repository, the `dcommit` operation will be rejected until the commits are acquired with this command: |
85 | 74 |
|
86 | | -Or upload all `ref`s (branches, tags,) to upstream: |
| 75 | +``` |
| 76 | +git svn rebase |
| 77 | +``` |
87 | 78 |
|
88 | | -* `git push --mirror origin` |
| 79 | +Keep in mind this action rewrites your local Git history and your commit identifiers will be different. |
| 80 | +{% endcapture %} |
89 | 81 |
|
90 | | -### SVN2Git method |
| 82 | +<div class="col-md-6"> |
| 83 | +{{ bridging | markdownify }} |
| 84 | +</div> |
91 | 85 |
|
92 | | -* Install Ruby Gem [SVN2Git](https://github.com/nirvdrum/svn2git) |
93 | | -* Identify the projects in the Subversion repository |
94 | | -* Run `svn list [svn-repo-url]` |
95 | | -* Start `svn2git [repo-root|repo-root/project]` |
96 | 86 |
|
97 | | -Considerations on migration: |
| 87 | +## Understanding |
98 | 88 |
|
99 | | -* Convert "flat" history across all projects |
100 | | -* Utilize Git `filter-branch --subdirectory-filter` |
101 | | -* Migrate on a project-by-project basis |
102 | | -* Use `--trunk`, `--nobranches`, `--notags` or `--rootistrunk` for non-standard layouts |
103 | | -* Limit history from starting point ``--revision <<starting_rev>>``, or range `--revision <<start:end>>` |
| 89 | +Subversion and Git share similar vocabularies, but the commonality often is only is command names. Behavior and functionality are quite distinct given the unique qualities Git provides as a distributed version control system when compared to the centralized aspects of Subversion. |
104 | 90 |
|
105 | | -https://github.com/nirvdrum/svn2git |
106 | 91 |
|
107 | | -### GitHub importer (Porter) method |
108 | | -* [Read the import tool documentation](https://help.github.com/articles/importing-from-other-version-control-systems-to-github/) |
109 | | -* Expose the Subversion repository publicly |
110 | | -* [Visit the GitHub import tool page](https://porter.github.com/new) |
111 | | -* Point the import tool at your Subversion, TFS, or Mercurial repository |
112 | | -* Create the username mappings |
113 | | -* Wait for the tool to work in the background and complete the conversion |
| 92 | +| SVN command | Git command | Git behavior | |
| 93 | +| --- | --- | --- | |
| 94 | +| `status` | `status` | Report the state of working tree | |
| 95 | +| `add` | `add` | Required for each path before making a commit | |
| 96 | +| `commit` | `commit` | Store prepared changes in local revision history | |
| 97 | +| `rm`, `delete` | `rm` | Prepare paths for deletion in next commit | |
| 98 | +| `move` | `mv` | Prepare relocated content for next commit | |
| 99 | +| `checkout` | `clone` | Acquire the entire history of a project locally for the first tim | |
| 100 | +| | `branch` | Create local context for commits | |
| 101 | +| | `merge` | Join branch histories and changes to working tree | |
| 102 | +| | `log` | No network required | |
| 103 | +| | `push` | Upload commit history to GitHub/centralized Git host | |
| 104 | +| | `pull` | Download and integrate GitHub repository history with local on | |
| 105 | +| | `fetch` | Download GitHub repository history with no other action | |
0 commit comments