企業におけるGitベースのソース管理：推奨されるツールと実践？
私はgitを個人的なプロジェクトに使用していますが、素晴らしいと思います。高速、柔軟、強力で、リモート開発に最適です。
しかし、今では仕事で義務付けられており、率直に言って、私たちは問題を抱えています。
すぐに使えるgitは、さまざまな能力とレベルのgitの洗練度を備えた開発者がいる大規模（20人以上の開発者）の組織での集中開発ではうまく機能しないようです-特にPerforceやSubversionなどの他のソース管理システムと比較してそのような環境を目指しています。 （はい、私は知っています、Linusはそのためにそれを決して意図しませんでした。）
しかし、政治的な理由で、私たちはgitで行き詰っています。
ここに私たちが見ているもののいくつかがあります：
- GUIツールは成熟していません
- コマンドラインツールを使用すると、マージを台無しにして他の人の変更を消去するのは簡単ではありません
- グローバルな読み取り専用または読み取り/書き込み権限を超えるユーザーごとのリポジトリ権限は提供しません
- リポジトリのどの部分にもアクセス許可がある場合、リポジトリのすべての部分に同じことを行うことができるため、他の人にはできない中央サーバーで小グループ追跡ブランチを作成するようなことはできません手を出す。
- 「何でもする」または「慈悲深い独裁者」以外のワークフローは、実施するのはもちろんのこと、奨励するのは難しい
- 単一の大きなリポジトリー（誰もがすべてを混乱させる）を使用する方がよいのか、コンポーネントごとのリポジトリーを多数使用する（バージョンを同期しようとする頭痛の種になる）方が良いかどうかは明らかではありません。
- 複数のリポジトリがある場合、中央リポジトリからプルすることで他の誰かが持っているすべてのソースを複製する方法や、昨日の午後4時30分時点ですべてを取得するなどの方法も明確ではありません。
ただし、大規模な開発組織でgitがうまく使用されていると聞きました。
あなたがそのような状況にある場合-または一般的にコマンドラインファンではない大規模な組織でgitをより簡単かつ生産的に使用するためのツール、ヒント、コツがある場合-あなたが持っているものを聞いてみたい提案する。
ところで、私はすでにLinkedInでこの質問のバージョンを尋ねましたが、本当の答えは得られませんでしたが、「まあ、私もそれを知りたいです！」
更新：明確にしてみましょう...
私が働いているところでは、git以外は使用できません。オプションではありません。私たちはそれにこだわっています。 Mercurial、svn、bitkeeper、Visual Source Safe、ClearCase、PVCS、SCCS、RCS、Bazaar、Darcs、モノトーン、Perforce、Fossil、AccuRev、CVS、または1987年に使用したAppleの優れたolプロジェクターさえ使用できません。したがって、他のオプションについて議論することを歓迎しますが、gitについて議論しなければ賞金は得られません
また、私は企業でgitを使用する方法に関する実用的なヒントを探しています。私たちが抱えている問題の全リストをこの質問の一番上に置きました。繰り返しになりますが、人々は理論について議論することを歓迎しますが、賞金を獲得したい場合は、解決策を教えてください。
よくある意見に反して、DVCSを使用することは非常に柔軟なワークフローを可能にするため、エンタープライズ環境での理想的な選択だと思います。最初にDVCSとCVCSの使用、ベストプラクティス、そして特にgitについて説明します。
エンタープライズコンテキストでのDVCSとCVCS：
ここでは一般的な長所/短所については話しませんが、むしろあなたのコンテキストに焦点を当てます。 DVCSを使用するには、集中型システムを使用するよりも規律のあるチームが必要になるというのが一般的な概念です。これは、集中システムがワークフローをenforceする簡単な方法を提供するためです。分散システムを使用するには、より多くのコミュニケーションおよび慣習の確立。これはオーバーヘッドを誘発するように思えるかもしれませんが、良いプロセスにするために必要なコミュニケーションの増加にはメリットがあると思います。チームは、コード、変更、およびプロジェクトの一般的な状況について伝達する必要があります。
規律の文脈における別の側面は、分岐と実験を奨励することです。 Martin Fowlerの最近のblikiエントリ バージョン管理ツール からの引用です。彼はこの現象について非常に簡潔な説明を見つけました。
DVCSは、実験のための迅速な分岐を推奨します。 Subversionでブランチを作成できますが、すべてのブランチに表示されるという事実により、実験的な作業のためにブランチを開くことができなくなります。同様に、DVCSは作業のチェックポイントを推奨します。つまり、テストをコンパイルしたりパスしたりすることもない、不完全な変更をローカルリポジトリにコミットします。繰り返しになりますが、Subversionの開発者ブランチでこれを行うことができますが、そのようなブランチが共有スペースにあるという事実により、人々はそうする可能性が低くなります。
DVCSは、単純なテキストの差分ではなく、有向非巡回グラフ（DAG）のグローバルに一意な識別子を介して変更セットトラッキングを提供するため、柔軟なワークフローを実現します。これにより、Originと変更セットの履歴を透過的に追跡できます。これは非常に重要です。
ワークフロー：
Larry Osterman（Windowsチームで働いているMicrosoft開発者）は、Windowsチームで採用しているワークフローについて 素晴らしいブログ投稿 を持っています。最も注目すべき点は次のとおりです。
- クリーンで高品質なコードのみのトランク（マスターリポジトリ）
- すべての開発は機能ブランチで行われます
- 機能チームにはチームリポジトリがあります
- 彼らは定期的に最新のトランクの変更を機能ブランチにマージします（Forward Integrate）
- 完全な機能は、いくつかの品質ゲートを通過する必要があります。レビュー、テスト範囲、Q＆A（独自のリポジトリ）
- 機能が完成し、許容可能な品質を備えている場合、トランクにマージされます（Reverse Integrate）
ご覧のとおり、これらのリポジトリをそれぞれ独自にライブにすることで、さまざまなペースで前進するさまざまなチームを切り離すことができます。また、柔軟な品質ゲートシステムを実装する可能性により、DVCSとCVCSが区別されます。このレベルでも許可の問題を解決できます。マスターリポジトリへのアクセスを許可するのはほんの一握りの人だけにしてください。階層のレベルごとに、対応するアクセスポリシーを備えた個別のリポジトリを用意します。実際、このアプローチはチームレベルで非常に柔軟に対応できます。チームリポジトリをチーム間で共有するかどうか、またはチームリーダーのみがチームリポジトリにコミットできるようなより階層的なアプローチが必要かどうかを判断するには、各チームに任せてください。
（写真はジョエル・スポルスキーの hginit.com から盗まれています。）
ただし、DVCSは優れたマージ機能を提供しますが、これは継続的インテグレーションを使用するためのneverの代替品です。その時点でも、トランクリポジトリのCI、チームリポジトリのCI、Q＆Aリポジトリなど、かなりの柔軟性があります。
エンタープライズコンテキストでのGit：
既に指摘したように、Gitはエンタープライズコンテキストにとって理想的なソリューションではないかもしれません。あなたの懸念のいくつかを繰り返して、私は最も顕著に彼らがいると思います：
Windowsでもまだ未熟なサポート（最近変更された場合は修正してください）現在、windowsは github windows client 、 tortoisegit 、 atlassianのSourceTree- 成熟したGUIツールの欠如、ファーストクラスの市民vdiff/mergeツールの統合なし
- 内部の仕組みに加えて抽象化のレベルが非常に低い一貫性のないインターフェイス
- SVNユーザー向けの非常に急な学習曲線
- Gitは非常に強力であり、履歴を変更するのは簡単です
- 利用可能な商用サポートオプションはありません
ここでgit vs. hgのフレームウォーを開始したくありません。DVCSに切り替えることで正しい手順をすでに実行しています。 Mercurialは上記のいくつかのポイントに対応しているため、企業の状況により適していると思います。
- pythonを実行するすべてのプラットフォームがサポートされています
- すべての主要なプラットフォーム（win/linux/OS X）の優れたGUIツール、ファーストクラスのmerge/vdiffツールの統合
- 非常に一貫性のあるインターフェイス、svnユーザーの簡単な移行
- Gitでできることのほとんどを実行できますが、より簡潔な抽象化を提供します。危険な操作は常に明示的です。高度な機能は、明示的に有効にする必要がある拡張機能を介して提供されます。
- 商用サポートが利用可能 セレニックから。
要するに、企業でDVCSを使用するときは、摩擦が最も少ないツールを選択することが重要だと思います。移行を成功させるには、開発者間でのさまざまなスキルを考慮することが特に重要です（VCSに関して）。
摩擦の低減：
[OK]を、あなたは本当に状況に固執しているように見えるので、私見のままに2つのオプションがあります。 gitの複雑さを軽減するツールはありません。 gitisは複雑です。あなたはこれに直面するか、gitを回避します：
- チーム全体のgit入門コースを取得します。これには、基本事項といくつかの演習（重要！）のみを含める必要があります。
- マスターリポジトリをsvnに変換し、 "young-stars" git-svn にします。これにより、ほとんどの開発者は使いやすいインターフェイスを提供し、チームの規律の欠如を補うことができますが、若いスターは引き続き自分のリポジトリにgitを使用できます。
正直なところ、ツールの問題ではなく、人の問題が本当にあると思います。この状況を改善するために何ができますか？
- 現在のプロセスが保守可能なコードベースになると考えることを明確にする必要があります。
- 継続的な統合に時間をかけます。上で概説したように、使用するVCSの種類に関係なく、CIに代わるものはありません。マスターリポジトリにがらくたをプッシュする人がいると言いました：赤いアラートが鳴り、ビルドを壊した（または品質メトリックなどを満たしていない）ことを責めている間に、彼らのがらくたを修正してもらいます。
私はかなり大規模な開発組織のSCMエンジニアであり、過去1年ほどでsvnからgitに変換しました。集中的に使用します。
gitosis を使用してリポジトリをホストします。 gitの分岐ユニットは基本的にリポジトリであるため、モノリシックなsvnリポジトリを多くの小さなgitリポジトリに分割しました。 （それを回避する方法はありますが、それらは厄介です。）ブランチごとの種類のアクセス制御が必要な場合は、 gitolite がより良いアプローチかもしれません。お金を使いたければ、ファイアウォールの内側のバージョン GitHub もあります。私たちの目的では、リポジトリに対してかなりオープンなアクセス権があるため、gitosisは問題ありません。 （リポジトリのグループへの書き込みアクセス権を持つ人々のグループがあり、誰もがすべてのリポジトリへの読み取りアクセス権を持っています。）Webインターフェースにはgitwebを使用します。
あなたの特定の懸念のいくつかに関して：
- マージ：任意のビジュアルマージツールを使用できます。さまざまな場所に設定方法に関する指示があります。マージを実行してローカルリポジトリで完全に有効性を確認できるという事実は、私の意見では、gitにとって大きなプラスです。何かをプッシュする前にマージを確認できます。
- GUI：TortoiseGitを使用している人は何人かいますが、実際にはお勧めしません。コマンドラインと奇妙な方法で相互作用しているようです。これは改善が必要な分野であることに同意する必要があります。 （そうは言っても、私は一般にバージョン管理のためのGUIのファンではありません。）
- 小グループ追跡ブランチ：gitoliteのようなきめ細かいACLを提供するものを使用する場合、これを行うのは簡単ですが、さまざまな開発者のローカルリポジトリを接続することで共有ブランチを作成することもできます。gitリポジトリには複数のリモートがあります。
多数のリモート開発者がいるため、またSubversionで多くの問題があったため、gitに切り替えました。私たちはまだワークフローを試していますが、現時点では基本的にSubversionを使用するのと同じ方法で使用しています。私たちが気に入ったもう1つのことは、コードレビューのためのステージングリポジトリの使用や小さなグループ間でのコードの共有など、他の可能なワークフローを開いたことです。また、リポジトリを作成するのは非常に簡単なので、多くの人が自分の個人的なスクリプトなどの追跡を開始することを奨励しています。
はい、私は知っています、Linusはそれを意図していませんでした。
実際、Linusは、集中型システムは機能しないと主張しています。
そして、 独裁者と嘘つきのワークフロー？ の何が問題なのですか？
Gitはdistributedシステムであることに注意してください。中央のように使用しようとしないでください。
（更新しました）
Gitを「ステロイドのsvn」であるかのように使用しないと、ほとんどの問題は解消されます（そうではないため）。
誰もがプッシュ（および潜在的に台無し）できる中央サーバーとしてベアリポジトリを使用する代わりに、マージを処理する少数の統合マネージャーをセットアップし、彼らだけがベアリポジトリにプッシュできるようにします。
通常、これらの人々はチームのリーダーである必要があります。各リーダーは自分のチームの作業を統合し、それを祝福されたリポジトリにプッシュします。
さらに良いことには、誰か他の人（つまり独裁者）がチームリーダーから引き抜き、その変更を祝福されたリポジトリに統合します。
そのワークフローには何も問題はありませんが、私たちは働きすぎのスタートアップであり、人間の時間と注意に代わるツールが必要です。慈悲深い独裁者は言うまでもなく、コードレビューを行う帯域幅さえもありません。
インテグレーターがコードをレビューする時間がない場合はそれで問題ありませんが、それでも皆さんからのマージを統合する人々が必要です。
Git pullを行うのにそれほど時間はかかりません。
git pull A
git pull B
git pull C
gitdoes人間の時間と注意の代わり。それが最初に書かれた理由です。
- GUIツールは成熟していません
Guiツールは基本的なものをかなりうまく処理できます。
高度な操作には、コーダー/オタクの考え方が必要です（たとえば、コマンドラインから快適に作業できます）。概念を理解するには少し時間がかかりますが、それほど難しくはありません。
- コマンドラインツールを使用すると、マージを台無しにして他の人の変更を消去するのは簡単ではありません
これは、「中央リポジトリ」への完全な書き込みアクセス権を持つ多くの無能な開発者がいなければ問題になりません。
ただし、少数の人（インテグレーター）のみが「祝福された」リポジトリーに書き込むようにワークフローをセットアップする場合、それは問題になりません。
Gitはマージを簡単に台無しにすることはありません。
マージの競合がある場合、gitは競合する行を明確にマークするので、どの変更があなたのもので、どれがそうでないかがわかります。
Svnまたは他の（非分散型）ツールを使用して、他の人のコードを消去することも簡単です。実際、これらのその他のツールを使用する方がずっと簡単です。なぜなら、「変更を長時間待ち続ける」傾向があり、ある時点でマージがひどく困難になる可能性があるからです。
そして、これらのツールはマージ方法を知らないため、常に手動でマージする必要があります。たとえば、ローカルで編集しているファイルに誰かがコミットするとすぐに、手動で解決する必要がある競合としてマークされます。今thatはメンテナンスの悪夢です。
Gitでは、gitは実際にマージできるため、ほとんどの場合、マージの競合は発生しません。競合が発生した場合、gitは行を明確にマークするので、exactlyどの変更があなたのものであり、どの変更が他の人のものであるかがわかります。
マージ競合の解決中に誰かが他の人の変更を抹消しても、それは間違いではありません。それは、競合の解決に必要だったためか、彼らが何をしているかわからないためです。
グローバルな読み取り専用または読み取り/書き込み権限を超えるユーザーごとのリポジトリ権限は提供しません
リポジトリのどの部分にもアクセス許可がある場合、リポジトリのすべての部分に同じことを行うことができるため、他の人にはできない中央サーバーで小グループ追跡ブランチを作成するようなことはできません手を出す。
- 「何でもする」または「慈悲深い独裁者」以外のワークフローは、実施するのはもちろんのこと、奨励するのは難しい
Gitを集中システムのように使用しようとするのをやめると、これらの問題はなくなります。
- 単一の大きなリポジトリー（誰もがすべてを混乱させる）を使用する方がよいのか、コンポーネントごとのリポジトリーを多数使用する（バージョンを同期しようとする頭痛の種になる）方が良いかどうかは明らかではありません。
判定コール。
どんなプロジェクトがありますか？
たとえば、プロジェクトAのバージョンxyは、プロジェクトBのバージョンwzに正確に依存するため、毎回プロジェクトAのxyをチェックする必要があります。プロジェクトBのwz、そうでなければビルドしませんか？もしそうなら、私はプロジェクトAとプロジェクトBの両方を同じリポジトリに置くことにします。それらは明らかに単一のプロジェクトの2つの部分だからです。
ここでのベストプラクティスは、 脳を使用
- 複数のリポジトリがある場合、中央リポジトリからプルすることで他の誰かが持っているすべてのソースを複製する方法や、昨日の午後4時30分時点ですべてを取得するなどの方法も明確ではありません。
どういう意味かわかりません。
企業での仕事には http://code.google.com/p/gerrit/ を強くお勧めします。アクセス制御に加えて、組み込みのレビューベースのワークフローを提供します。 LDAPシステムに対して認証します。 http://wiki.hudson-ci.org/display/HUDSON/Gerrit+Plugin を使用してHudsonに接続し、まだレビュー中に変更をビルドおよびテストできます。それは本当に印象的なセットアップです。
Gerritを使用することに決めた場合は、オープンソースのような一部のブランチのような履歴ではなく、かなり直線的な履歴を保持することをお勧めします。 Gerritは、「早送りの変更のみを許可する」と表現しています。そうすれば、リリースやその他のために、あなたが今までに使っていた方法で分岐とマージを使用できます。
2010年にGitを採用した大規模な電話会社の開発者マネージャーとしての経験に基づいて、この質問に答えています。
ここには、まったく異なる一連の問題があります。
- ワークフロー
- クライアントツール
- サーバーのアクセス制御と統合
ワークフロー
中央リポジトリモードの採用に成功しました：エンタープライズプロジェクト（500万ユーザーベースの大規模ポータル）にあるものは、公式のビルドを生成し、配信プロセスで取得される事実上の中央リポジトリです（これは、 3つのレベルのテストと2つの展開で構成されています）。すべての開発者が自分のリポジトリを管理し、機能ごとにブランチを作成します。
クライアントツール
いくつかのオプションが利用可能になりました。これは非常に混雑したエリアです。多くの開発者が IntelliJ Idea および Gitプラグインを使用したEclipse を他のものなしで正常に使用しています。また、ほとんどのLinux開発者は問題なくCLI gitクライアントを使用しています。一部のMac開発者は Tower Git を正常に使用しています。 これらのクライアントはどれも、ユーザーが中央リポジトリを「混乱させる」ことを防ぐことができることに注意してください：サーバー側の制御メカニズムが必要です
サーバーのアクセス制御と統合
開発者がGitリポジトリを「台無しにする」ことを避けたい場合は、次のソリューションを選択する必要があります。
- すべての操作を行うための適切なWeb管理インターフェイスを公開します
- ユーザーIDを強制できます（「裸の」Gitリポジトリを使用すると、他の誰かに代わってコミットするのが非常に簡単です）
- きめ細かいセキュリティを提供します（たとえば、FORCE-Pushを防止し、一部の開発者/グループのみを読み取るようにブランチを設定できます）。
- 企業認証システム（LDAP、Windows ActiveDirectory）と統合する
- 完全な監査を提供します（SOXコンプライアンスは、大企業にとって非常に重要な場合があります）
これに役立つすぐに使えるサーバー側のソリューションはそれほど多くありません。次のいずれかをチェックすることをお勧めします。
- Gitorious ：基本的なアクセスレベルセキュリティを提供できますが、すぐに使用できるきめ細かいアクセス許可制御がないため、ブランチレベルのアクセス許可などのシナリオを処理するために、おそらくコーディングを行う必要があります。また、既存の企業認証メカニズムとの統合も欠いています
- GitHub Enterprise：GitHubによって最近公開された、企業内のGitHubを備えています。 SOX準拠ときめの細かいセキュリティが欠けている
- Gerrit ：きめ細かいアクセスレベルセキュリティと企業認証システムとの統合を提供できますが、SOXコンプライアンスとSSOがありません。また、一部の操作はCLI経由のSSH経由でのみ実行できます
- GitEnterprise ：ブランチレベルのアクセス許可、SSO、SOXコンプライアンス、完全なWebベースの管理を提供します。また、最近Gerritと統合されたため、完全なGerritインスタンスも提供されます。
お役に立てれば！
問題は、ワークフローを決定または設定していないことです。 Gitはsvnや他のVCSのように使用するのに十分な柔軟性を備えていますが、非常に強力であるため、誰もが従わなければならないルールを確立しないと、混乱に陥ります。上記の誰かが言及した独裁者-中utのワークフローをお勧めしますが、 Vincent Driessen で記述された分岐モデルと組み合わせます。詳細については、これらのスクリーンキャストをご覧ください デビッド・ボックによる 、およびこれは Mark Derricutt によるものです。
toolsでは、MacOS-XユーザーはGitX（http://gitx.frim.nl/）が非常にシンプルで効果的だと感じています。欠点は、Gitクライアントフック（$ GIT_ROOT/.git/hooksの下にあるもの）をサポートしていないことです。
全体的に、fine-grained access control onをサポートするツールを選択することを強くお勧めします：-ブランチ（より敏a性と柔軟性が必要なトピックブランチから厳密なセキュリティで安定したリリースブランチを分離するため） -IDの施行（作成者/コミッター）。 これはSOXのキーです-gitコマンドの制限-audit-trail。 これはSOXのキーです
これらの機能で私が首尾よく使用したものは次のとおりです。
- Gerrit Code Review（http://code.google.com/p/gerrit/）
- GitEnterprise（http://gitenterprise.com）
- CollabNet TeamForge（http://www.collab.net/gotgit）、舞台裏でGerrit 2.1.8を使用
PS SOXおよびCMMIコンプライアンスを過小評価しないでください：多くの場合、企業のセキュリティに関する企業ポリシーで規定されている選択肢の限られたセットがあります。
お役に立てれば。
ルカ。
最近、svnからgitに切り替えました。 git-daemonはmsysgitで動作しないため、gitosisを使用するLinuxサーバーで中央リポジトリのアプローチを選択しました。
マスターを台無しにする可能性を排除するために、私たちは単にそれを削除しました。代わりに、テスト用に選択されたブランチをマージしてすべてのリリースを準備し、マージにタグを付けます。テストに合格すると、コミットにバージョンのタグが付けられ、実稼働状態になります。
これに対処するために、リリースマネージャーの役割を交代で持っています。リリースマネージャーは、テストの準備ができる前に各ブランチを確認する責任があります。次に、製品所有者が承認されたブランチを新しいテストリリース用にバンドルする時が来たと判断すると、リリースマネージャーがマージを実行します。
また、第2レベルのヘルプデスクの役割を交代で持ち、少なくとも私たちにとっては、両方の役割を同時に持つことができるようなワークロードです。
マスターがいないことの利点として、リリースマネージャーを経由せずにプロジェクトにコードを追加することはできないため、以前にプロジェクトにサイレントに追加されたコードの量を直接発見しました。
レビュープロセスは、ブランチの所有者がレビューボードに差分を送信し、ホワイトボードに「レビュー用」の下にブランチ名（かんばんベースのワークフローがある）または完成したユーザーの一部である緑のポストイットを置くことから始まりますストーリーの場合、ストーリーカード全体を「レビュー用」に移動し、その上にポストイットを配置します。リリースマネージャーは、カードとポストイットを「テスト準備完了」に移動し、製品所有者は次のテストリリースに含めるものを選択できます。
マージを実行するとき、リリースマネージャは、マージコミットに、製品所有者の変更ログで使用できる実用的なコミットメッセージがあることも確認します。
リリースが実稼働状態になると、タグはブランチの新しいベースとして使用され、既存のすべてのブランチがそれにマージされます。このように、すべてのブランチには共通の親があり、マージの処理が容易になります。
ポイント3および4（ユーザーごと、セクションごと、ブランチごとのアクセス許可）については、 gitolite （Pro Gitブックで説明されています： http：// progit。 org/book/ch4-8.html ）。
政治の有無にかかわらず、Gitは他のDCVSと同様に優れた選択肢です。他の強力なツールと同様に、ツールがどのように機能するように設計されているかを理解するために少し時間をかける価値があります。このため、Pro Gitブックを強くお勧めします。数時間を費やすことで、長期的には多くのフラストレーションを軽減できます。
- Github FI のような適切なWebインターフェースをインストールします
- 人々を快適に保つために、比較的初期化されたモデルに（最初は）固執します。
- every共有ブランチの継続的統合ビルドを実行します。
- グローバルgit設定オプションの適切なセットを共有します。
- Gitをシェルに統合し、bashの補完を行い、現在のブランチでプロンプトを表示します。
- IntelliJのGit Integrationをマージツールとしてお試しください。
- 必要に応じて.gitignoreを確認してください。
「検討してもらえますか」という投稿にも追加します。
Bazaarの素晴らしい点の1つは、その柔軟性です。これは、他のすべての分散システムに勝るものです。 Bazaarを集中モード、分散モードで操作するか、両方を入手できます（開発者は自分のワークグループに最適なモデルまたは最適なモデルを選択できます）。また、外出中に集中リポジトリを切断し、戻ったときに再接続することもできます。
それに加えて、優れたドキュメントと企業を幸せにする何か：商用サポートが利用可能です。
多くの開発者がいる開発チームでgitを効率的に使用するには、継続的にビルドとテストを行うCIシステムが必要です。ジェンキンスはそのような乗り物を提供します、そして、私はそれを強くお勧めします。統合の部分は何があっても行われなければならず、それをより早くそしてより頻繁に行う方がはるかに安価です。
GUI：現在のところ、TortoiseGit v1.7.6はほとんどの日常の操作に適しています。ログ、コミット、プッシュ、プル、フェッチ、差分、マージ、ブランチ、チェリーピック、リベース、タグ、エクスポート、スタッシュ、サブモジュールの追加など。x64もネイティブサポート
Gitosisやgitoliteよりも共同開発に適していますが、オープンソースは Gitorious です。これはRuby on Railsリポジトリとマージの管理を処理するアプリケーションです。多くの問題を解決するはずです。
Gitでは、プライベートブランチを作成できます。これにより、開発者は頻繁にコミットして、変更を小さなコミットに分解することができます。開発者は自分の変更を公開する準備ができたら、中央サーバーにプッシュします。必要に応じて、事前コミットスクリプトを使用してコードを検証できます。
NXPは、1つの共通プラットフォーム（エンタープライズ規模）でGitとSubversionを管理し、Androidモバイル開発と従来のソフトウェアプロジェクトを統合しています： http://www.youtube.com/watch ？v = QX5wn0igv7Q