私は、急速に成長しているIT企業のRuby開発者として働いています。 そして、Gitと連携するためのサービスを変更するという戦略的な決定を下したら、 猫の下で興味のある方、どうぞ。
パート1.はじめに
この瞬間まで、我々はジトライトを使用しました 。 少し歴史に触れて、これがどんな獣なのか知らない人に伝えます。
公式ウェブサイトはこちらです： gitolite
git-scm.comからの短い説明：
Gitoliteは、アクセス権を管理するための十分な機会を提供するGitの上の追加レイヤーです。
Habrに関する素敵な記事： ジトライトの知り合い
非常に簡単に言えば、これは小さなコンソールユーティリティであり、通常の開発者ができる限り簡単にリポジトリとチームのリポジトリに最小限の保護を設定できるようにします。
順番に始めましょう。 以下は、設定ファイルの基本的な例です。 サイト：
# sample conf/gitolite.conf file @staff = dilbert alice # groups @projects = foo bar repo @projects baz # repos RW+ = @staff # rules - master = ashok RW = ashok R = wally option deny-rules = 1 # options config hooks.emailprefix = '[%GL_REPO] ' # git-config
これらの行は、ユーザーのセット（ @staff ）とリポジトリ（ @projects ）を宣言します。
@staff = dilbert alice # groups @projects = foo bar
このブロックは、 プロジェクトセットのリポジトリとbazリポジトリへのアクセスレベルを設定します。
また、権限、特に、フルアクセス権限がスタッフユーザーグループに設定されていることについても説明します。
次の行は、ユーザーashokの masterブランチへのアクセスの禁止を示しています。 どうやら、彼はどこかでしっかりとねじ込んだ:)
repo @projects baz # repos RW+ = @staff # rules - master = ashok RW = ashok R = wally
まあなど...これはすべてドキュメントで詳しく説明されており、誰でも詳細を見ることができます。
パート2.新しい希望
続けましょう！
これはすべて、優雅で、本物の専門家だけが対象です。 かつて、 markdownの目で解析せずに、ブラウザでREADMEファイルを直接見たいと思っていました。 そして、彼らはどこかでGitLabと呼ばれるスタンドアロンソリューションを見たことを思い出しました 。
それでは、このすばらしいツールに移りましょう！
公式ウェブサイト： GtiLab
GitHubのGitLabを使用した皮肉なリポジトリ： リポジトリ
これは十分に開発された巨大な製品であり、元の形式の情報はすべてサイトの説明とドキュメントに完全に記載されているため、大量のスクリーンショットと抱擁を提供しません。
つまり、これはGitHubの一種です（トマトを投げさせてください）。 GitHubに似た分化モデルを使用します。 gitoliteとの主な違いは、いわゆる名前空間です。 Gitoliteでリポジトリにアクセスできるユーザーのセットを明示的に指定した場合、GitLabではプロジェクトは特定のスペースにある必要があり、それに応じてURLに影響します。 例：
ジトライト
git@git.yourcompany.com:some_repo
GitLab（プロジェクトが名前空間rubyを取得したとしましょう）
git@git.yourcompany.com:ruby/some_repo
実際のところ、ローカル開発者リポジトリのリモートを変更する必要があるため、これは私たちの動きの中で最も邪魔な問題でした。
GitLabサブスクリプションに関しては、いくつかのオプションがあります。 1つ目は、CE-Community Edition-オープンソース製品およびオムニバスインストールです。 実際、このオプションはハードウェアに展開して使用します。 さらに、プロジェクトがRubyで記述されている場合、必要なファイル（少なくともRubyを知っている人）を自由に変更できます。
Enterprise Editionもあります-名前に続いて、これが開発の第一人者の大規模で強力なコミュニティ向けのバージョンであることが明らかになります。 ただし、費用がかかり、CEバージョンは必要なすべてのタスクを迅速に実行するため、実際には必要ありません。
パート3.利点
しかし、それはサブスクリプションに関するものではありません。 私は、完全に実装され、有用な（純粋に私にとって）機能であると考えるものを本当に説明したいと思います。
1.プロジェクトの問題の可用性。 はい、GitHubにありますが、現在は内部サーバーにあります。
2.マージリクエストを処理します。 常に使用するとは限りませんが、コンソールでコードを表示するよりもグラフィカルな表示の方がはるかに便利です。
3.スニペット-Gistの類似物。 繰り返しますが、私のものです。
4. GitLab CIは継続的インテグレーションに最適なツールです。 バージョン管理システムに直接統合され、デフォルトでDockerがサポートされます。
5.プロジェクトにキーを展開します-展開中にリポジトリを読み取るためのキー（たとえば、Capistranoと組み合わせて）。 gitoliteでは、これらの目的のために読み取り権限を持つ別のユーザーが作成されました。
6.サービステンプレート-一連のサービス（JIRA、Asana、HipChatなど）と統合するための準備された設定のセット
7. GitLabをSaaSとして使用することは無料です。 Bitbucketの優れた代替品。 ネタバレですが、私はすでにGitLabに何かを投稿しました（以下を参照）。
パート4.現実
しかし、正直なところ、すべてが順調に進んだわけではありません。 一つ面白いことがありました。
状況：〜50MBのサイズのリポジトリが突然ゴチャゴチャになり、〜18.5GBに肥大化しました！ 18.5GB、CARL！ 。
私たちは悪の根源を見つけていないことをすぐに言います。 問題は、パックファイルが適切にクリーンアップされず、各新しいパックファイルにリポジトリと以前のパックファイルへの変更が含まれていたということだけでした。 そして、これらすべては、開発者の1人が人気のあるIDEのインターフェースをプッシュした木曜日の雨の後のジョークでありました。
しかし、最終的に、魔法の助け、つまり1つのコマンドを使用して、問題を解決することができました（もしあれば、サーバー上のリポジトリーを持つフォルダーで実行します）。
git gc --auto
上で書いたように、正確に何が問題であったかは言えませんが、プロジェクトをインポートするときに私たち自身が台無しにしたという仮定があります。
パート5.貢献
また、gitoliteからGitLabに移行するための一連のrakeタスクも開発しました。
実際、これはGitLabにインポートするための再設計された標準タスクです。 GitLabのlib / tasksフォルダーに配置して、そこから実行できます。
ここで見つけることができます。
おわりに アンケート
どのバージョン管理ツールを使用していますか？ コメントで返信してください。 私は自分で最も興味深いものを試し、おそらく比較を行います。 すべての新しいツールは非常に急速に開発されているため、すべてに間に合うとは限りません。