SVNからGitLab CE(Self-hosted)への移行ステップガイド

はじめに

近年ではバージョン管理システムのディファクトスタンダードといっても過言ではないGitですが、実際にはまだまだSubversion(以下、SVN)で管理をしている現場も多いと思われます。また、「GitやGitlabの名前は聞いたことがあるけど、SVNとの違いがよくわからない」「SVNの管理から移行するメリットはなんなのか？」「今のプロジェクトを移行してみたいけど、どうすればいいのか？安全に移行できる？」といった疑問をお持ちの方も多いのではないでしょうか。

確かに、使い慣れたツールや管理方法を変更するのであれば、相応のメリットが欲しいところです。また、実際に移行する作業もわかりやすく、かつ安全に実行できることが望ましいです。

そこで本記事では、前半で「SVNとGitの違いはなにか」「バージョン管理をGit(GitLab)で行うメリット」について紹介をし、後半でSVN管理のプロジェクトをGit/GitLab管理のプロジェクトに移行する移行する手順を紹介します。

SVNとGitについて

ここでは、SVNとGitの違いや、Git・GitLabを導入するメリットについて紹介をしていきます。

SVNとGit・GitLab

まずはSVNとGitについて述べていきます。大前提として、SVNもGitも同じ「バージョン管理システム」です。つまり、ソースコードをはじめとした様々なファイルの変更履歴を「リポジトリ(= 書庫)」に記録し、管理・追跡するためのシステムです。しかし、 SVNとGitは構造的な違いを持っています。

SVN : 集中型バージョン管理システム

SVNは、集中型バージョン管理システムです。SVNの場合は、リモート環境にインストールしたリモートリポジトリだけが、ソースコードのバージョンを管理しています。開発に参加するメンバーは、各自がこの中央リポジトリにアクセスして、ローカル環境にあるファイルをコミット（新バージョンとしてファイルを保存）したり、ローカル環境へチェックアウト（特定のバージョンのファイルを取得）したりします。

このように、SVNはバージョン管理を行うリポジトリが、リモート環境にのみ存在するという構造を持っています。

Git : 分散型バージョン管理システム

Gitは分散型バージョン管理システムです。Gitの場合は、リモート環境にあるリモートリポジトリだけでなく、各開発メンバーのローカル環境にもリポジトリ(ローカルリポジトリ)が存在します。開発メンバーはこのローカルリポジトリに対して修正や追加したファイルをコミットしていきます。

このローカルリポジトリは、リモートリポジトリの完全なコピー(クローン)として作成されます。ローカルリポジトリにコミットされた変更内容は、リモートリポジトリへプッシュすることで、リモート側へ反映されます。また、リモートリポジトリからプルをすることで、ローカルリポジトリの内容をリモートリポジトリとあわせることができます。

このように、バージョン管理を行うリポジトリが、リモート側のみでなく各々のローカル環境にも存在するという構造を持っています(分散型の所以ですね)。

さて、ここまででSVNとGitとその違いについて紹介しました。次に、残る`GitLab`についても紹介していきます。

GitLab : Gitリポジトリのホスティングサービス

GitLabはGitリポジトリのホスティングサービスです。ざっくりと説明してしまうと、「Gitのリモートリポジトリを集中管理できるソフトウェア開発支援環境」がGitLabです。 GitLabを利用することで、複数のリモートリポジトリを集中管理することが可能になるため、プロジェクト毎にいちいちリモートリポジトリのサーバー環境を作成する必要がありません。つまり、GitLabを社内共通の開発基盤として使うことができるのです。

また、GitLabにはissue管理やマイルストン機能をはじめとした、様々なソフトウェア開発の支援機能が備わっています。これらを利用することで、統一的なソフトウェア開発サイクルや、プロジェクトのコンテンツ共有が容易に実現できます。

GitLabの詳細については、公式ホームページを参照してください。

SVNの問題点

SVNは集中型のバージョン管理であるため、とてもシンプルで理解しやすい構造をしています。その一方で、次のような問題点もあります。

一回のコミットが直接リポジトリに影響する

SVNは、変更履歴を管理する場所(リポジトリ)は1つしかありません。そのため、変更してコミットを行った結果はすぐさま他の開発メンバーも取得可能になります。そのため、仮にバグを修正しきれていないコードをコミットしてしまうと、それが即座にチーム全体に影響してしまいます。

また、1回のコミットが全体に影響するため、必要な実装や作業を完全に終えてからコミットをする必要があります。「一つの機能を細かいタスクに分け、分割してコミットしていく」という方法がとれないことになるため、

修正が必要になったとき、どの段階で間違いが起きたかが追跡しにくい
変更内容のレビューを行う場合、一つの作業全体をまとめてレビューする必要があり、負荷が大きいといった問題も発生します。

コンフリクト発生の機会が多くなる

同じファイルを別々のユーザーが編集してしまうと「コンフリクト(= 衝突)」が発生します。当然、コンフリクトが発生した状態ではファイルのコミットを行う事ができないため、この状態を解消してから再度コミットをする作業をする必要があります。

SVNの場合、リポジトリが単一であることや、(説明は省略していますが)ファイル差分の管理方法や、ブランチ作成の原理の影響で、このコンフリクトが発生しやすい構造となっています。

複数プロジェクトの管理が難しい

これはSVNの問題というよりはGitLab、GitHub、BitBucketのメリットの裏返しになりますが、SVNではリポジトリがプロジェクトごとにバラバラに作成されます。そのため、自分の関わっていないリポジトリについて知ることが非常に困難です。

また、リポジトリ間・プロジェクト間での情報共有も、「情報共有の場」としてはSVN単体では機能しないため、他のチームなどでも類似のコードを書いてしまう、車輪の再発明が起こりがちと行った問題があります。

SVNサーバーを社内で1台立ててそれに皆で情報・リポジトリ・ライブラリを共有する、といったこともGit系のサービスと比べると非常に難しいです。

Git・GitLabを取り入れる利点

分散型なので、ローカルリポジトリで様々な開発ができることや、以下のような利点が挙げられます。

ローカルリポジトリでの開発は、リモートリポジトリに影響しない。そのため細かにコミットしてリポジトリにPushすることでデータの欠損を防げます。また、実験的な実装をした後に戻す（Revert）などが容易です
SVNではConflictが起きがちですが、自分の手元で一旦自分のタスクに必要な修正や試行作業を他の人への影響を気にせず行い、マージしたいタイミングでConflictを解消する、といったことが行いやすいです。
ブランチを簡単に作成できる
- 機能毎や担当者毎で軽量にブランチを作成できる。大きな単位での開発になりづらく開発サイクルが高速化する
- 機能毎のマージ可否や、ある機能部分のみを取り込むなど、柔軟な開発が可能。無駄になるコードや手戻りが少なく出来る
レビュー作業が容易
- ブランチが簡単に作成できるので、機能毎でのレビューと取り込みができる
- ホスティングサービスやSelf-HostedのGitLabなどを利用することで、レビューやマージ作業がさらに容易にできる
GIｔリポジトリのホスティングサービスであるGitLabの利用可能
- 多数のプロジェクト(リポジトリ)を一元的に管理です
- issue管理やマイルストン機能の利用も出来、単なるコードのホスティングサービス以上の価値を生み出します
- wikiなどを使った情報共有もすることが出来ます
- マージリクエストの機能により、差分表示やレビュー/ディスカッション・マージが簡単に行えます
- slackなどの外部ツールとの連携が可能です。メジャーなツールであるため、GitLab CIなども活用することで多くのサービスとの連携が可能です。

バージョン管理システムではGitの方がSVNに比べ後発ですが、現在はGitが最もメジャーな管理システムとなっています。 cf. https://insights.stackoverflow.com/survey/2018#work-_-version-control

SVNからGitへの移行作業

ここからは、実際にSVNのリポジトリをGit・GitLabへ移行するための手順を示します。この手順では、SVNリポジトリの内容を自分のローカルな環境にimportし、それを整理してGitLabに反映させるという作業を行います。そのため、実際に開発チームで運用しているリポジトリを移行する場合は、専任の作業者を決めて行うことをお勧めします。

また、この移行作業はSVNからGit・GitLabへの一方向の変換を想定しています。そのため、Git・GitLabからSVNへの逆変換や相互連携については対象としていません。

本手順を行うにあたって、まずは以下の事を確認してください。

移行先のGitLabサーバーが立ち上がっていていること
作業者のローカル環境にGitがインストールされていること
作業者のローカル環境でSVNが使えること
作業者がGitLabにサインインして、移行先のプロジェクトにアクセスできること

対象とするSVNリポジトリは、標準的なレイアウトであること(trunk、branches、tagsの構成) であることを想定しています。

概要

移行手順全体の外観を示します。

移行作業は大きく分けて3つのステップに分かれます。

1.`git svn`を使い、SVNリポジトリをGitリポジトリとしてimport

git svnを使って、SVNのリポジトリをローカル環境へimportします。 SVNリポジトリのブランチ・タグ情報やコミットログなどが、Git形式のリポジトリに変換された形で、作業者のローカル環境に取り込まれます。

2. ローカルリポジトリでタグの抽出とブランチの整理

importされたGitリポジトリは、タグ情報が完全に反映されておらず、ブランチも整理されていません。そのため、タグ情報の抽出・設定や、ブランチの整理を行い、GitLabへ反映できる形にしていきます。

3. GitLabの新しいプロジェクトへ反映

整理されたGitリポジトリをGitLabへpushし、新たなプロジェクトとして反映させます。

今回の作業では、SVNリポジトリと、作業対象となるGitリポジトリは完全に独立したものになります。そのため、 Git・GitLabへの移行作業は、元のSVNリポジトリに影響を与えることなく実行することができます。

今回検証に使ったローカル環境は Ubuntu 16.04 LTS です。また、テスト用に用意したSVNリポジトリは、次のような構成になっています。

リビジョン数 : 30
リポジトリ構成

<Root>
├── branches
│   ├── release_1
│   └── release_2
├── tags
│   ├── release1_0
│   ├── release1_1
│   ├── release1_2
│   └── release2_0
└── trunk
    ├── include
    └── src

事前準備

`git-svn`のインストール

SVNのリポジトリを、Gitのリポジトリとしてimportするために必要なgit-svnをインストールします。

$ sudo apt-get install git-svn

インストールが終了したら、次のコマンドを入力して、正常にインストールできたかを確認してみましょう。

$ git svn --version

コンソールにgit-svnのバージョン情報が表示されれば、インストールはOKです。

なお、git-svnの詳細な機能についてはGitの公式ドキュメントに記述されていますので、必要に応じて参照して下さい。

ユーザーマップファイルの作成

SVNは各リビジョンの作成者のユーザー名のみをログに保存します。一方、Gitは作成者のフルネームとメールアドレスをログに保存します。そのため、SVNのコミットログを正しく変換するためには、SVNのユーザー名をGitのユーザーと対応付けを記したテキストファイルを作成し、 import時に渡してあげる必要があります。

ユーザー名のマッピングファイルは、次のような書式で記述されます。ファイル名に指定はありませんが、ここではuser_map.txtというファイル名で作成するものとします。

t.yamada = Taro.Yamada <taro.yamada@example.com>
m.ozawa = Masahiro.Ozawa <masahiro.ozawa@example.com>
y.takahashi = Yuki.Takahashi <yuki.takahashi@example.com>

各行はSVNのユーザ名 = Gitのユーザ名 <Gitのメールアドレス>という書式になっています。

マッピングファイルを全て手動で作成をしても問題ありません。ですが、 svn logの出力結果を使って、過去にリビジョンを作成したユーザーの一覧を取得することもできます。対象となるSVNの作業フォルダ内で次のコマンドを実行します。

$ svn log --xml | grep author | sort -u | perl -pe 's/.*>(.*?)<.*/$1 = /' > user_map.txt

このコマンドは、まずSVNのlogをxml形式で出力します。その中からauthorのタグを含む行を抽出し、重複を削除します。そこからXMLタグを除去し、結果をuser_map.txtにリダイレクトで書き込みます。

生成されたuser_map.txtは次のようになっていますので、空いている個所(Gitのユーザ名 <Gitのメールアドレス>の部分)を埋めていけばマッピングファイルは完成です。

t.yamada = 
m.ozawa = 
y.takahashi = 
    ⋮

作成したuser_map.txtは後の変換作業時に使用するため、適当な場所にコピーをしておいてください。

SVNリポジトリのimport

さて、ここからは実際にSVNのリポジトリをGit形式のローカルリポジトリへimportする作業を行います。まず、作業を行うための適当なディレクトリを作成して、そこへ移動します。併せて、 3.2で作成したマッピングファイルもコピーしてカレントディレクトリに置いておきましょう。

次のコマンドを実行し、SVNサーバーからリポジトリをimportします。

$ git svn clone -s --prefix="" --authors-file=user_map.txt <SVN_REPOS> svntogit_project

SVN_REPOSで対象とするSVNリポジトリを指定します。例えば、svn+sshでSVNサーバーにアクセスするケースでは、次のようになります

# ユーザー名が必要な場合は`--username=`で指定する
$ git svn clone -s --prefix="" --authors-file=user_map.txt --username=username https://your.svn.repos/project svntogit_project

コマンドを実行すると、コンソールにimport処理のログが流れ始めます。検証用のリポジトリでは、終了まで30秒程度かかりました。 import処理が終了すると、svntogit_projectディレクトリが作成され、この内部にGit形式のローカルリポジトリが形成されます。

今回試した環境の場合、以下のようなブランチ構成のGitリポジトリが作成されました。

$ cd svntogit_project   # 作成されたディレクトリ内部へ移動
$ git branch -a         # リポジトリのブランチを全て表示
* master
  remotes/release_1
  remotes/release_2
  remotes/tags/release1_0
  remotes/tags/release1_1
  remotes/tags/release1_2
  remotes/tags/release2_0
  remotes/trunk

見てわかる通り、SVNで作成されていたブランチの他、tags内にあった各タグと、本流のtrunkもそれぞれGitのブランチとして作成されています。

また、git logコマンドでログを確認してみることもできます。SVNのコミットログが、Gitリポジトリのコミットログに反映されていることが確認できます。

ブランチ・タグの抽出と整理

先ほどのimpoert作業で、SVNリポジトリをGit形式のローカルリポジトリとして取得することができました。ここから、さらにGitLabへ反映するために情報の抽出やブランチ・タグの整理を行っていきます。

除外ファイルの反映

SVNリポジトリで設定されていた除外ファイルの内容を、Gitリポジトリ側に反映させます。

svntogit_projectディレクトリで、次のコマンドを実行します。

$ git svn show-ignore > .gitignore

SVNの除外ファイルの内容が.gitignoreファイルに反映されます。これで、 Gitリポジトリでも、同じファイル・ディレクトリを管理対象から除外することができます。

タグ情報の抽出とリポジトリへの反映

importをしたままの状態では、SVNのタグはただのリモートブランチとなっており、タグ情報としては設定されていません。そのため、タグの情報を抽出して、 Git形式のタグとして改めて設定する作業が必要になります。

svntogit_projectディレクトリで、次のコマンドを実行します。

for t in $(git for-each-ref --format='%(refname:short)' refs/remotes/tags); do git tag ${t/tags//} $t && git branch -D -r $t; done

このコマンドでは、Gitリポジトリの各リモートブランチ名からrefs/remotes/tagsで開始するものを出力し、そのブランチ名をgit tag <tag name>コマンドで Git形式のタグとして設定しています。また、不要となったリモートブランチをgit branch -D -rコマンドで削除しています。

今回の検証環境に対してこのコマンドを実行した結果、リポジトリ内は以下のようになりました。

# タグ抽出実行前
$ git branch -a         
* master
  remotes/release_1
  remotes/release_2
  remotes/tags/release1_0
  remotes/tags/release1_1
  remotes/tags/release1_2
  remotes/tags/release2_0
  remotes/trunk
$ git tag  # タグ一覧の表示 何も表示されない 

# タグ抽出実行後
$ git branch -a
* master
  remotes/release_1
  remotes/release_2
  remotes/trunk
$ git tag   # タグ一覧の表示
release1_0
release1_1
release1_2
release2_0

不要なリモートブランチが削除され、タグがリポジトリに反映されていることが確認できます。

ブランチをローカルブランチへ移動

GitLabへ反映させるために、残りのリモートブランチを一度ローカルブランチへ移動させます。

svntogit_projectディレクトリで、次のコマンドを実行します。

$ for b in $(git for-each-ref --format='%(refname:short)' refs/remotes); do git branch $b refs/remotes/$b && git branch -D -r $b; done

このコマンドでは、Gitリポジトリの各リモートブランチ名からrefs/remotesで開始するものを出力し、そのブランチを git branch <branch name> <remote branch name>コマンドでローカルブランチとしています。また、不要となったリモートブランチをgit branch -D -rコマンドで削除しています。

今回の検証環境に対してこのコマンドを実行した結果、リポジトリ内は以下のようになりました。

# ローカルブランチ移動前
$ git branch -a
* master
  remotes/release_1
  remotes/release_2
  remotes/trunk 

# ローカルブランチ移動後
$ git branch -a
* master
  release_1
  release_2
  trunk

リモートブランチが削除され、同名のローカルブランチが作成されていることがわかります。

不要なブランチを削除

最後に、ローカルブランチに残っているtrunkブランチの削除を行います。

trunkブランチはSVNでは本流のブランチとなりますが、Gitではmasterというブランチが本流となります。masterブランチは、import実行時にtrunkの内容を含めた形で作成されるため、 trunkブランチは不要となります。

svntogit_projectディレクトリで、次のコマンドを実行します。

$ git branch -d trunk

これで、不要なブランチは全てなくなり、リポジトリにはmasterと、SVNから引き継いだブランチのみが残ります。検証環境では、最終的に次のようになりました。

$ git branch -a
* master
  release_1
  release_2
$ git tag
release1_0
release1_1
release1_2
release2_0

note

今回の検証環境には出てきていませんが、SVNからリポジトリをimportしてくると、 @123のようなsuffixがついたブランチが作成されることがあります。これは、SVNのpeg-revisionという機能で作成されるもので、Gitにはない機能です。

これ自体は、特に影響があるものではないのですが、Gitにはない機能であり、ブランチを管理する上では邪魔にもなるため、ローカルブランチから削除をしてしまうことをお勧めします。

数が少ない場合は、git branch -d <branch name>で手動削除するのが確実ですが、数が多い場合は次のコマンドで一括削除することができます。

$ for p in $(git for-each-ref --format='%(refname:short)' | grep @); do git branch -D $p; done

これは、ローカルブランチ内から@を含むブランチを検出して、それを削除するというものです。GitLabのプロジェクトへ反映

前節までで、SVNのリポジトリを変換し、移行のためのローカルリポジトリを作成しました。いよいよ、作成したローカルリポジトリをGitLab上のプロジェクトに反映させます。

GitLabのプロジェクトを作成する

(既にプロジェクトが作成済みの場合は、この節はスキップしてください)

SVNのプロジェクトを引き継ぐ、新しいプロジェクトをGitLabに作成します。 GitLabサーバーにアクセスし、新しい空プロジェクトを作成してください。

対象のプロジェクトへローカルリポジトリをpushする

ローカルリポジトリを作成したプロジェクトにpushします。 3.3で作成したsvntogit_projectディレクトリへ移動し、次のコマンドを実行します。

$ git remote add origin git@your-git-server:your-new-repository.git  # 新しいリモートリポジトリを設定
$ git push origin -u --all   # リモートリポジトリへ、ローカルのすべてのブランチをpush
$ git push -u origin --tags  # リモートリポジトリへ、ローカルのタグを反映させる

コミット・タグの反映が終わったら、実際にGitLabに反映ができたかを確認しましょう。
GitLabのプロジェクト画面を更新すると、空であったプロジェクトにpushしたローカルリポジトリの内容や、ブランチ・タグが反映されていることが確認できます。

以上で、移行作業は終了となります。これ以降の開発では、GitLabのプロジェクトをリモートリポジトリとして使用することができます。

移行の際のTips

ここでは、SVNからGitLabへ移行する際のちょっとしたtipsを記載します。

標準的ではないディレクトリ構成となっている場合

プロジェクトによっては、SVNリポジトリが標準的なレイアウトやディレクトリ名(trunk、branches、tagsの構成)になっていない事もあります。その場合は、-sオプションのかわりに--trunk, --branches, --tagsを使うことで、直接ディレクトリを指定することができます。例として、次のような構成のリポジトリをimportするとしましょう。

<Root>
├── develop
│   ├── local_branch      # ブランチのディレクトリ その1
│   │   └── dev_branch_1
│   └── release_branch    # ブランチのディレクトリ その2
│       └── release_1
├── main                  # 本流ディレクトリ(=trunkと同じ扱い)
└── tags                  # タグのディレクトリ
    └── 1_0

この場合は、import時に次のように指定をします。

# `-s`を外すのを忘れないように
$ git svn clone --trunk=/main --branches=/develop/local_branch --branches=/develop/release_branch --tags=/tags --prefix="" --authors-file=user_map.txt <SVN_REPOS> svntogit_project

import後にできるGitリポジトリは次のようになります。リポジトリの内容が正しく反映されていることが確認できます。

$ git branch -a
* master
  remotes/dev_branch_1
  remotes/release_1
  remotes/tags/1_0
  remotes/trunk

リポジトリ内に不要なディレクトリがある場合

SVNリポジトリ内に不要なファイルやディレクトリがコミットされている場合は、import時に除外することができます。対象は、--ignore-pathsオプションを使い、除外するファイルやディレクトリ名を正規表現で指定します。

例として、trunk内に”backup”という不要なディレクトリがあるとします

trunk
├── backup
├── src
└── test

これで、trunk内に”backup”ディレクトリは除外された形でimportされます。正規表現の組み合わせで、複数のファイル・ディレクトリを除外することが可能です。

SVNのリポジトリに空ディレクトリがある

SVNでは、ファイルをもたないディレクトリをリポジトリ内で管理することができます。一方、Gitではファイルを持たないディレクトリは管理対象にする事ができません。そのため、移行作業時には、この空ディレクトリに対するケアが必要になります。

SVNのリポジトリをimportする際、--preserve-empty-dirsオプションをつけることで、空ディレクトリ内に自動的に .gitignoreファイルを生成することができます(生成されるのが.gitkeepではないことに注意してください)

$ git svn clone -s --prefix="" --authors-file=user_map.txt --preserve-empty-dirs <SVN_REPOS> svntogit_project

.gitignore以外のファイルを生成したい場合は、--placeholder-filenameオプションで生成ファイル名を指定することができます。例として、空ディレクトリに”Empty_dir”というファイルを生成したい場合は次のように設定します

$ git svn clone -s --prefix="" --authors-file=user_map.txt --preserve-empty-dirs --placeholder-filename="Empty_dir" <SVN_REPOS> svntogit_project

まとめ

この記事では以下の3つについて紹介をさせていただきました
- git/GitLabの紹介
- svnとの違いや利点
- svnのリポジトリをGit/GitLabのプロジェクトへ移行する手順
Git/GitLabへの移行で、以下のような利点があります
- gitのリモート/ローカルリポジトリでの分散開発や軽量なブランチ作成機能による柔軟な開発作業
- issue機能やタスクボート、マイルストーン機能による課題・進捗管理
- マージリクエスト機能によるコードの品質管理
- slackなどの外部機能との連携
- 多数のプロジェクトの一元的な管理による情報共有や開発基盤の共通化
Git/GitLabの移行は、コストがかかるのも事実です
- プロジェクトの移行作業
- ツールとして再学習

SVNからGitへの移行はコストが掛かるのも事実ですが、GitのローカルリポジトリでのConflictを恐れない開発などによって、生産性が大きく向上するため、移行コストをなるべく早く支払うほど、リターン（トータルの生産性）は大きくなると思います。

また、GitLabやGitHub、BitBucketを導入することで、組織内、チーム感での情報の共有、タスク管理の集約などの、プロジェクト全体・組織全体の生産性を上げることにも向上します。それに加え、コードのスキャン機能、脆弱性のあるOSSを教えてくれる機能などがついているGitホスティングサービスも多く、素のSVNからGitホスティングサービスに移行することは、当初の想定よりも非常に大きくなると思います。
ぜひ移行をお勧めします！

なお、スリーク社で提供している以下の2サービスはGitHub、GitLabに対応しており、クラウド版であればセットアップの所要時間も数分のため、もしご興味あれば試して頂ければ幸いです。

コードレビュー支援サービスSider。GitHub Pull RequestやGitLab Merge Requestに対応し、RequestのOpenや更新のタイミングで様々な解析器で新しく書かれたコードを検査、問題を発見し、開発者に通知します。それによって人が見るべきレビューの量を減らし、人間のレビューの品質を上げることが出来ます。
https://sider.review/ja

プロジェクト管理ツールのSleeek。JIRAやSlack、GitHub、GitLabと接続しデータを収集、日々の開発チームのアクティビティから、チーム内で起きている問題などについて早急に把握し、対処を行うことを支援します。
また、日報機能、体調を聞く機能、それらのサマリをSlackに投稿する機能などが有り、「周りが何をしているのかわからない」といったリモート業務でありがちな問題を解決するのに役立ちます。
https://www.sleeek.io/ja/home

今後も定期的に本メディアを更新していきますのでぜひ今後もご覧頂ければ幸いです！

コピペ管理

修正もれ確認

はじめに

SVNとGitについて

SVNとGit・GitLab

SVN : 集中型バージョン管理システム

Git : 分散型バージョン管理システム

GitLab : Gitリポジトリのホスティングサービス

SVNの問題点

一回のコミットが直接リポジトリに影響する

コンフリクト発生の機会が多くなる

複数プロジェクトの管理が難しい

Git・GitLabを取り入れる利点

SVNからGitへの移行作業

概要

1.`git svn`を使い、SVNリポジトリをGitリポジトリとしてimport

2. ローカルリポジトリでタグの抽出とブランチの整理

3. GitLabの新しいプロジェクトへ反映

事前準備

`git-svn`のインストール

ユーザーマップファイルの作成

SVNリポジトリのimport

ブランチ・タグの抽出と整理

除外ファイルの反映

タグ情報の抽出とリポジトリへの反映

ブランチをローカルブランチへ移動

不要なブランチを削除

note

GitLabのプロジェクトを作成する

対象のプロジェクトへローカルリポジトリをpushする

移行の際のTips

標準的ではないディレクトリ構成となっている場合

リポジトリ内に不要なディレクトリがある場合

SVNのリポジトリに空ディレクトリがある

まとめ

ソフトウェアメトリクス2:ソースコードの規模

コピペ管理

修正もれ確認

SVNからGitLab CE(Self-hosted)への移行ステップガイド

はじめに

SVNとGitについて

SVNとGit・GitLab

SVN : 集中型バージョン管理システム

Git : 分散型バージョン管理システム

GitLab : Gitリポジトリのホスティングサービス

SVNの問題点

一回のコミットが直接リポジトリに影響する

コンフリクト発生の機会が多くなる

複数プロジェクトの管理が難しい

Git・GitLabを取り入れる利点

SVNからGitへの移行作業

概要

1.git svnを使い、SVNリポジトリをGitリポジトリとしてimport

2. ローカルリポジトリでタグの抽出とブランチの整理

3. GitLabの新しいプロジェクトへ反映

事前準備

git-svnのインストール

ユーザーマップファイルの作成

SVNリポジトリのimport

ブランチ・タグの抽出と整理

除外ファイルの反映

タグ情報の抽出とリポジトリへの反映

ブランチをローカルブランチへ移動

不要なブランチを削除

note

GitLabのプロジェクトを作成する

対象のプロジェクトへローカルリポジトリをpushする

移行の際のTips

標準的ではないディレクトリ構成となっている場合

リポジトリ内に不要なディレクトリがある場合

SVNのリポジトリに空ディレクトリがある

まとめ

関連記事

ソフトウェアメトリクス2:ソースコードの規模

1.`git svn`を使い、SVNリポジトリをGitリポジトリとしてimport

`git-svn`のインストール