git - GIT権限の管理-複数のリポジトリ

Question

いくつかの開発チームがあり、それぞれが複数のプロジェクトを開発しています（通常は10以上）。現在CVSに参加しており、SVNとGITのどちらに移行するかを評価しています。私はGITに傾倒していますが、権限を効率的に管理する方法がわかりません。例えば。

開発チームA、開発チームB、開発チームCがあります。それぞれに12人の開発者がいます。各開発チームには、少なくとも10の個別のプロジェクトがあります。チームAは全員のコードを見ることができ、チームBとCは自分のコードしか見ることができません。さらに、一部の開発者は読み取り専用アクセスのみを持ち、他の開発者はフルアクセスを持ちます。

したがって、CVSには、チームごとに1つずつ、合計3つのリポジトリがあります。つまり、次のようになります。

/cvsroot/TeamARepos/project1
/cvsroot/TeamARepos/project2

/cvsroot/TeamBRepos/project1
/cvsroot/TeamBRepos/project2 

/cvsroot/TeamCRepos/project1
/cvsroot/TeamCRepos/project2 

等々。リポジトリ全体を管理でき、John DoeはAへの読み取り専用アクセス権を持っているが、Bへの書き込みアクセス権はあり、Cへのアクセス権はないと言うことができます。したがって、各プロジェクトへの明示的なアクセス権を彼に与える必要はありません（そして、それらはかなり頻繁に追加されます。したがって、毎回すべての新しいプロジェクトに全員を追加する必要はありません）。

GITについての私の理解は、プロジェクトごとに1つのリポジトリがあるということです。したがって、「チームAのすべてのコードがここにあり、これらのユーザーはそれに書き込むことができます」および「チームBのすべてのコードがここにあり、これらのユーザーはそれを読み取ることができます」と言って、そのように分離しておくという論理的な方法はありません。

質問を正しく行う方法すらわからないのですが、管理上の悪夢としてGITに移行することを想定しています。

また、antスクリプトを使用して、CVSからコードをチェックアウトし、ビルドを実行して、サーバーにデプロイします。見始めたばかりですが、そういう意味でもアリがGITとうまくやってくれることを願っています。

Answer 1

速度、分散バージョン管理モデル、および全体的に適切な方法のために、gitoversvnを使用することをお勧めします。私たちは数年間仕事でSVNを使用していましたが、gitと比較して非常に苦痛でした。私がSVNで見た唯一の利点は、TortoiseSVNなどのWindowsとの統合でした。ただし、これは、GUIに制約されることを望み、はるかに強力なコマンドラインを学習したくない場合にのみ発生します。

gitを使用すると、アクセス制御を処理するために明らかにgitoliteが必要になります。このモデルでは、プロジェクトごとに異なるリポジトリを設定します。Gitolite構成ファイルを使用すると、開発者をチームにグループ化でき、リポジトリ、ブランチ、さらには作業ツリーパスごとに非常にきめ細かいアクセス制御を設定できます。チームまたは個人のどちらか最適な方法で権限を指定できます。

コードレビューが必要な場合は、 gerritが適切なツールであるかどうかも確認する必要があります。両方は必要ありません。gitoliteまたはgerritのいずれかを使用してください。

時々人々はgitを学ぶのが難しいと感じます。そのために、私は開発者に良い本、例えばこれを紹介することを提案します。印刷物でもご利用いただけます。

Answer 2

複数のプロジェクトでチームAのすべてのコードを確認したい場合は、すべてのリポジトリへのリモートを含むキャッチオールリポジトリを作成してからgit fetch --all、分析を行うことができます。

Gitoliteは、管理（カスタムフックまで）を簡単にします。これにより、ブランチの読み取りまたは書き込みができるユーザーを制御できます。独自のgitフックを実装して、すべての人が各コミットメッセージにチケット参照を含めるようにするなど、他のカスタムの安全対策を講じることもできます。私は過去2年以上それを使用していて、それは素晴らしいです。

競合解決の苦痛、速度、その他多くの理由から、SVNからGitに移行しました。その理由のひとつは、gitの採用率でした。rerereに解像度を保存すると、機能を簡単に組み合わせることができます。フックは簡単に作成でき、コードコントラクトを含む特定のリポジトリにOCPを適用できます。これはすべて、SVNでは非常に面倒でした-不可能ではないにしても。

CIプロセスに従って、gitはコマンドラインから適切に機能するため、自動ビルドツールで好きなことを実行できます。現在、この種のすべての主要なツールのサポートがすぐに利用できます。

これは、gitを使用して各リポジトリで実行するプロセスです：http：//dymitruk.com/blog/2012/02/05/branch-per-feature/

Answer 3

Subversionは、よりスムーズな方法である可能性があります（少なくとも、後の移行および管理領域では）。

「MergeHell」は、Git-boysと怠惰な資格のないSVNユーザーの側からの非常に誇大宣伝された神話とボギーです。まあ、それは実際に何らかの条件の下で存在します（あらゆる品質のチームの「リファクタリング地獄」の形で）、あなたはただ検出する必要があります、この条件はあなたのワークフローに適用できますか？

既存のサーバーOSとインフラストラクチャの共通点については何も言わなかったが、それが重要な場合もある。GitサーバーとWinの下の一部のフロントエンドは、Linux側にとっては本当に悪夢と恐怖です。Windows用のVisualSVNサーバー（Enterprise Edition）（UberSVNは私のPOVから肥大化しています）のように、httpを介したSubversionのコンパクトで使用可能なソリューションを見つけることができません。 ）。サーバー上にJavaがある場合は、（チームのサイズとリポジトリの量について）SCMマネージャーについて考えることができます（選択したSCMの場合-ボックスからGit、SVN、Hgをサポートします）