企業におけるGitベースのソース管理：推奨されるツールとプラクティス？

私は個人的なプロジェクトにgitを使用していて、すばらしいと思います。高速、柔軟、強力で、リモート開発に最適です。

しかし、今では仕事で義務付けられており、率直に言って、私たちは問題を抱えています。

そのままでは、gitはさまざまな機能とgitの高度なレベルの開発者がいる大規模な（20人以上の開発者）組織での集中型開発にはうまく機能しないようです。特に、PerforceやSubversionなどの他のソース管理システムと比較すると、そのような環境を目指しています。（そうです、Linusがそのために意図したことはありません。）

しかし-政治的な理由から-gitでやろうとしていることがうまくいかなくても、gitで立ち往生しています。

ここに私たちが見ているもののいくつかがあります：

• GUIツールは成熟していない
• コマンドラインツールを使用すると、マージを台無しにして他の人の変更を抹消するのは簡単です
• グローバルな読み取り専用または読み取り/書き込み特権を超えて、ユーザーごとのリポジトリ権限を提供しません
• リポジトリの任意の部分に対する権限がある場合は、リポジトリのすべての部分に対して同じことを行うことができるため、中央サーバーに小さなグループのトラッキングブランチを作成するようなことはできません。手を出す。
• 「すべてがうまくいく」または「慈悲深い独裁者」以外のワークフローは、実施はもちろん、奨励するのが難しい
• 単一の大きなリポジトリー（誰もがすべてを混乱させることができる）を使用する方がよいのか、コンポーネントごとの多数のリポジトリー（バージョンを同期しようとする頭痛の種になる）を使用する方が良いのかは明らかではありません。
• 複数のリポジトリーがある場合、中央リポジトリーからプルして他の誰かが持っているすべてのソースを複製する方法や、昨日の午後4時30分の時点ですべてを取得する方法なども明確ではありません。

しかし、人々は大規模な開発組織でgitをうまく使用していると聞いています。

あなたがそのような状況にある場合-または、コマンドラインのファンではない大規模な組織でgitをより簡単かつより生産的にするためのツール、ヒント、およびトリックがある場合-私はあなたが持っているものを聞きたいです提案する。

ところで、私はすでにLinkedInでこの質問のバージョンを尋ねましたが、本当の答えはありませんでしたが、たくさんの「まあ、私もそれを知りたいです！」

更新：明確にしましょう...

私が働いている場所では、git以外は使用できません。それはオプションではありません。私たちはそれで立ち往生しています。mercurial、svn、bitkeeper、Visual Source Safe、ClearCase、PVCS、SCCS、RCS、bazaar、Darcs、monotone、Perforce、Fossil、AccuRev、CVS、または1987年に使用したAppleの優れたol 'Projectorは使用できません。したがって、他のオプションについて話し合うことは歓迎されますが、gitについて話し合わなければ、賞金を受け取ることはできません。

また、企業でのgitの使用方法に関する実用的なヒントも探しています。私たちが抱えている問題の完全なリストをこの質問の一番上に置きます。繰り返しになりますが、人々は理論について議論することができますが、賞金を獲得したい場合は、解決策を教えてください。

一般的な意見に反して、DVCSを使用すると、非常に柔軟なワークフローが可能になるため、企業の設定では理想的な選択肢だと思います。最初にDVCSとCVCSの使用について話し合い、次にベストプラクティス、特にgitについて話します。

企業におけるDVCSとCVCSの比較：

ここでは、一般的な長所/短所については説明しませんが、コンテキストに焦点を当てます。DVCSを使用する場合は、集中型システムを使用するよりも統制のとれたチームが必要になるというのが一般的な概念です。これは、中央集中型システムがワークフローを適用する簡単な方法を提供するためです。分散型システムを使用すると、確立された規則に固執するために、より多くのコミュニケーションと規律が必要になります。これはオーバーヘッドを誘発するように見えるかもしれませんが、それを優れたプロセスにするために必要なコミュニケーションの増加にはメリットがあります。チームは、コード、変更、プロジェクトステータス全般について連絡する必要があります。

規律の文脈における別の側面は、分岐と実験を奨励することです。Martin Fowlerの最近のバージョン管理ツールに関する blikiエントリからの引用は次のとおりです。彼はこの現象について非常に簡潔な説明を見つけました。

DVCSは、実験のための迅速な分岐を促進します。Subversionでブランチを作成することはできますが、ブランチがすべてに表示されるため、実験的な作業のためにブランチを開くことはできません。同様に、DVCSは作業のチェックポイントを奨励します。つまり、テストをコンパイルまたはパスすることさえできない不完全な変更をローカルリポジトリにコミットします。繰り返しますが、Subversionの開発者ブランチでこれを行うことができますが、そのようなブランチが共有スペースにあるという事実は、人々がそうする可能性を低くします。

DVCSは、単純なテキスト形式の差分ではなく、有向非巡回グラフ（DAG）でグローバルに一意の識別子を介してチェンジセットトラッキングを提供するため、柔軟なワークフローを可能にします。これにより、チェンジセットの起源と履歴を透過的に追跡できます。これは非常に重要です。

ワークフロー：

Larry Osterman（Windowsチームで働いているMicrosoft開発者）が、Windowsチームで採用しているワークフローについてのすばらしいブログ投稿を公開しています。最も注目すべき点は次のとおりです。

• クリーンで高品質のコードのみのトランク（マスターリポジトリ）
• すべての開発は機能ブランチで行われます
• 機能チームにはチームリポジトリがあります
• 彼らは定期的に最新のトランクの変更を機能ブランチにマージします（Forward Integrate）
• 完全な機能は、レビュー、テストカバレッジ、Q＆A（独自のリポジトリ）など、いくつかの品質ゲートを通過する必要があります。
• 機能が完成し、許容できる品質の場合、機能はトランクにマージされます（リバース統合）

ご覧のように、これらのリポジトリをそれぞれ単独で稼働させることで、異なるペースで進んでいる異なるチームを切り離すことができます。また、柔軟な品質のゲートシステムを実装する可能性は、DVCSとCVCSを区別します。このレベルでも権限の問題を解決できます。ほんの一握りの人だけがマスターリポジトリへのアクセスを許可されるべきです。階層の各レベルについて、対応するアクセスポリシーを持つ個別のリポジトリを用意します。実際、このアプローチはチームレベルで非常に柔軟です。チームリポジトリをチーム内で共有するか、チームリーダーのみがチームリポジトリにコミットできるようなより階層的なアプローチが必要かを決定するには、各チームに任せる必要があります。

（写真はJoel Spolskyのhginit.comから盗まれました。）

ただし、この時点ではまだ1つ注意すべき点があります。DVCSは優れたマージ機能を提供しますが、これは継続的インテグレーションを使用する代わりにはなりません。その時点でも、かなりの柔軟性があります。トランクリポジトリのCI、チームリポジトリのCI、Q＆Aリポジトリなどです。

エンタープライズコンテキストでのGit：

すでに指摘したように、Gitはエンタープライズコンテキストにとって理想的なソリューションではない可能性があります。あなたの懸念のいくつかを繰り返しますが、最も顕著なのは次のとおりです。

• Windowsでのサポートはまだ少し未熟です（最近変更された場合は修正してください）現在、windowsにはgithub windows client、tortoisegit、atlassianのSourceTreeがあります
• 成熟したGUIツールの欠如、一流の市民vdiff /マージツール統合なし
• 内部の仕組みに加えて、非常に低いレベルの抽象化を伴う一貫性のないインターフェース
• SVNユーザーにとって非常に急な学習曲線
• Gitは非常に強力で、履歴を簡単に変更できます。自分が何をしているかがわからない場合は非常に危険です（知っていると思っていても、ときどき危険です）。
• 商用サポートオプションはありません

ここでgit vs. hg flamewarを開始したくありません。DVCSに切り替えることで、すでに正しい手順を実行しています。Mercurialは上記のポイントのいくつかに対処しているため、企業のコンテキストに適していると思います。

• Pythonを実行するすべてのプラットフォームがサポートされています
• すべての主要なプラットフォーム（win / linux / OS X）の優れたGUIツール、ファーストクラスのマージ/ vdiffツールの統合
• 非常に一貫性のあるインターフェース、SVNユーザーの簡単な移行
• gitもできることのほとんどを行うことができますが、より明確な抽象化を提供します。危険な操作は常に明白です。高度な機能は、明示的に有効にする必要がある拡張機能を介して提供されます。
• selenicから商用サポートを利用できます。

つまり、企業でDVCSを使用する場合、摩擦が最も少ないツールを選択することが重要だと思います。移行を成功させるには、（VCSに関して）開発者間のスキルの違いを考慮することが特に重要です。

摩擦を減らす：

わかりました、あなたは本当にその状況に行き詰まっているように見えるので、私見には2つの選択肢があります。gitの複雑さを軽減するツールはありません。git は複雑です。これに直面するか、gitを回避します。

1. チーム全体のgit入門コースを取得します。これには、基本のみといくつかの演習（重要！）を含める必要があります。
2. マスターリポジトリをsvnに変換し、「young-stars」にgit-svnを許可します。これにより、ほとんどの開発者に使いやすいインターフェースが提供され、チームに欠けている規律を補うことができる一方で、若いスターは引き続き自分のリポジトリにgitを使用できます。

正直なところ、あなたは本当にツールの問題ではなく人の問題を抱えていると思います。この状況を改善するために何ができるでしょうか？

• 現在のプロセスが保守可能なコードベースで終了すると考えることを明確にする必要があります。
• 継続的インテグレーションに時間をかけてください。上で概説したように、使用するVCSの種類に関係なく、CIに代わるものはありません。あなたは、がらくたをマスターリポジトリにプッシュする人がいると言いました：赤いアラートが鳴り、ビルドを破壊した（または品質メトリックに適合していないなど）と非難する間に、がらくたを修正してもらいます。

私はかなり大規模な開発組織のSCMエンジニアです。昨年かそこらでsvnからgitに変換しました。集中的に使用します。

リポジトリをホストするためにgitosisを使用します。gitのブランチユニットは基本的にリポジトリであるため、モノリシックなsvnリポジトリを多数の小さなgitリポジトリに分割しました。（それを回避する方法はいくつかありますが、扱いにくいものです。）ブランチごとの種類のアクセス制御が必要な場合は、gitoliteの方が適切なアプローチです。お金を使いたいなら、GitHubのファイアウォールの内側のバージョンもあります。私たちの目的では、リポジトリに対してかなりオープンなアクセス許可があるため、gitosisは問題ありません。（私たちはリポジトリのグループへの書き込みアクセス権を持つ人々のグループを持っています、そして誰もがすべてのリポジトリへの読み取りアクセス権を持っています。）私たちはウェブインターフェースにgitwebを使用しています。

あなたの特定の懸念のいくつかについては：

• マージ：任意のビジュアルマージツールを使用できます。セットアップ方法については、さまざまな場所に説明があります。私の意見では、マージを実行してその有効性を完全にローカルリポジトリで確認できるという事実は、gitにとって大きなプラスです。何かをプッシュする前にマージを確認できます。
• GUI：TortoiseGitを使用している人が何人かいますが、私は実際にはお勧めしません。コマンドラインと奇妙な方法で相互作用するようです。これは改善が必要な分野であることに同意する必要があります。（とはいえ、私はバージョン管理全般のGUIのファンではありません。）
• 小グループ追跡ブランチ：gitoliteなどのよりきめの細かいACLを提供するものを使用する場合、これを行うのは十分簡単ですが、さまざまな開発者のローカルリポジトリを接続して共有ブランチを作成することもできます。gitリポジトリには複数のリモートがある場合があります。

リモート開発者がたくさんいること、およびSubversionで多くの問題があったため、gitに切り替えました。ワークフローはまだ実験中ですが、現時点では、基本的にはSubversionを使用するときと同じように使用します。私たちが気に入ったもう1つの点は、ステージングリポジトリを使用してコードをレビューしたり、小規模なグループ間でコードを共有したりするなど、他の可能なワークフローが開かれたことです。また、リポジトリの作成が非常に簡単であるため、多くの人が個人的なスクリプトなどの追跡を開始することも奨励されています。

はい、知っています。Linusがそのために意図したことはありません。

実際、Linusは、集中システムは機能しないと主張しています。

そして、独裁者と中尉のワークフローの何が問題になっていますか？

gitは分散システムであることを忘れないでください。中心的なもののように使用しないでください。

（更新しました）

「ステロイドのsvn」であるかのようにgitを使用しない場合、ほとんどの問題は解消されます（そうでないため）。

誰でもプッシュできる（そして失敗する可能性がある）中央サーバーとしてベアリポジトリを使用する代わりに、マージを処理するいくつかの統合マネージャーをセットアップして、自分だけがベアリポジトリにプッシュできるようにします。

通常、これらの人々はチームリーダーである必要があります。各リーダーは自分のチームの作業を統合し、祝福されたリポジトリにプッシュします。

さらに良いことに、他の誰か（つまり、独裁者）がチームリーダーから引き出し、その変更を祝福されたリポジトリに統合します。

そのワークフローには何も問題はありませんが、私たちは働きすぎのスタートアップであり、人間の時間と注意の代わりとなるツールが必要です。誰もが慈善的な独裁者であることは言うまでもなく、コードレビューを行うための帯域幅はありません。

インテグレーターがコードを確認する時間がない場合は問題ありませんが、すべての人からのマージを統合する人が必要です。

git pullを行うのにそれほど時間はかかりません。

git pull A
git pull B
git pull C

git は人間の時間と注意の代わりをします。それがそもそも書かれた理由です。

• GUIツールは成熟していない

GUIツールは基本的なものをかなりうまく処理できます。

高度な操作には、コーダー/オタクの考え方が必要です（たとえば、コマンドラインから作業するのが快適です）。概念を理解するには少し時間がかかりますが、それほど難しくありません。

• コマンドラインツールを使用すると、マージを台無しにして他の人の変更を抹消するのは簡単です

「中央リポジトリ」への完全な書き込みアクセス権を持つ多くの無能な開発者がいない限り、これは問題になりません。

ただし、「祝福された」リポジトリに書き込む人（インテグレータ）がわずかになるようにワークフローを設定した場合、問題はありません。

Gitはマージを台無しにすることを容易にしません。

マージの競合がある場合、gitは競合する行を明確にマークするので、どの変更が自分のもので、どれがそうでないかがわかります。

また、svnや他の（配布されていない）ツールを使用して、他の人のコードを簡単に消去することもできます。実際、これらの他のツールを使用すると、長時間「変更の上に座る」傾向があり、ある時点でマージが非常に困難になる可能性があるため、はるかに簡単です。

また、これらのツールはマージする方法を知らないため、常に手動でマージする必要があります。たとえば、ローカルで編集しているファイルに誰かがコミットするとすぐに、手動で解決する必要がある競合としてマークされます。今、それはメンテナンスの悪夢です。

gitを使用すると、実際にgitがマージできるため、ほとんどの場合、マージの競合は発生しません。競合が発生した場合、gitは行を明確にマークするので、どの変更が自分のもので、どの変更が他の人からのものかを正確に知ることができます。

マージ競合の解決中に誰かが他の人の変更を抹消した場合、それは間違いではありません。それは、競合の解決に必要であったためか、彼らが何をしているのかを知らないためです。

• グローバルな読み取り専用または読み取り/書き込み特権を超えて、ユーザーごとのリポジトリ権限を提供しません

• リポジトリの任意の部分に対する権限がある場合は、リポジトリのすべての部分に対して同じことを行うことができるため、中央サーバーに小さなグループのトラッキングブランチを作成するようなことはできません。手を出す。

• 「すべてがうまくいく」または「慈悲深い独裁者」以外のワークフローは、実施はもちろん、奨励するのが難しい

一元化されたシステムであるかのように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とEclipseをGitプラグインで正常に使用しています。また、ほとんどのLinux開発者は問題なくCLI gitクライアントを使用しています。一部のMac開発者はTower Gitの使用に成功しています。これらのクライアントはどれもサーバ側制御mechamismが必要とされている中央リポジトリと「めちゃくちゃ」にユーザーを防ぐことはできません

サーバーのアクセス制御と統合

開発者がGitリポジトリを「混乱させる」ことを避けたい場合は、次のようなソリューションを選択する必要があります。

• すべての操作を行うためのまともなWeb管理インターフェイスを公開します
• ユーザーIDを適用することができます（「ベア」Gitリポジトリーを使用すると、他の人のために非常に簡単にコミットできます）
• きめ細かいセキュリティを提供します（たとえば、FORCE-PUSHを防ぎ、一部のブランチを一部の開発者/グループのみが読み取り専用に設定できるようにします）
• 企業の認証システム（LDAP、Windows ActiveDirectoryなど）と統合する
• 完全な監査を提供します（SOXコンプライアンスは大企業にとって非常に重要な場合があります）

これに役立つ、すぐに使用できるサーバー側のソリューションはそれほど多くありません。次のいずれかを確認することをお勧めします。

• Gitorious：基本的なアクセスレベルのセキュリティを提供できますが、すぐに使用できるきめの細かいアクセス許可制御がないため、ブランチレベルのアクセス許可などのシナリオを処理するには、おそらくいくつかのコーディングを行う必要があります。また、既存の企業認証メカニズムとの統合が欠如している
• GitHub Enterprise：最近GitHubによって公開され、企業内でGitHubを使用しています。SOXコンプライアンスときめ細かなセキュリティが欠如している
• Gerrit：きめ細かいアクセスレベルのセキュリティと企業認証システムとの統合を提供できますが、SOXコンプライアンスとSSOがありません。また、一部の操作はSSH経由でのみCLI経由で実行できます
• GitEnterprise：ブランチレベルの権限、SSO、SOXコンプライアンス、完全なWebベースの管理を提供します。最近Gerritとも統合されたため、完全なGerritインスタンスも提供されます

お役に立てれば！

問題は、ワークフローを決めていないか、ワークフローを確立していないことです。Gitはsvnや他のVCSのように柔軟に使用できますが、非常に強力であるため、誰もが従わなければならないルールを確立しないと、混乱を招くだけです。私は、誰かが上で述べた独裁者-中尉のワークフローをお勧めしますが、Vincent Driessenによって記述された分岐モデルと組み合わせます。詳細については、David Bockによるこれらのスクリーンキャストと、Mark Derricuttによるスクリーンキャストを参照してください。

上のツールやMacOS-XのユーザーはGitX（http://gitx.frim.nl/）非常にシンプルかつ効果的なを見つけます。欠点は、Gitクライアントフック（$ GIT_ROOT / .git / hooksの下のフック）をサポートしないことです。

全体的に、私は以下に対するきめの細かいアクセス制御をサポートするツールを選択することを強く行います。 ）。これは、SOX -gitコマンドの制限-監査証跡の鍵です。これはSOXのキーです

これらの機能でうまく使用できたものは次のとおりです。

1. Gerritコードレビュー（http://code.google.com/p/gerrit/）
2. GitEnterprise（http://gitenterprise.com）
3. CollabNet TeamForge（http://www.collab.net/gotgit）、舞台裏でGerrit 2.1.8を使用

PS SOXおよびCMMIコンプライアンスを過小評価しないでください。多くの場合、セキュリティに関する企業のエンタープライズポリシーによって決定される選択肢のセットが制限されます。

お役に立てれば。

ルカ。

最近、svnからgitに切り替えました。git-daemonはmsysgitでは動作しないため、gitosisを使用するLinuxサーバーで中央リポジトリーアプローチを選択しました。

マスターを台無しにする可能性を排除するために、単純にそれを削除しました。代わりに、テスト用に選択されたブランチをマージしてすべてのリリースを準備し、マージにタグを付けます。テストに合格すると、コミットにバージョンのタグが付けられ、本番環境に配置されます。

これを処理するために、リリースマネージャのローテーションロールがあります。リリースマネージャーは、テストの準備ができる前に各ブランチを確認する責任があります。次に、製品の所有者が、承認されたブランチを新しいテストリリース用にバンドルする時期に来たと判断した場合、リリースマネージャーはマージを実行します。

また、2番目のレベルのヘルプデスクのローテーションロールもあり、少なくとも私たちにとっては、両方のロールを同時に持つことができるようなワークロードです。

マスターがないことの利点として、リリースマネージャーを経由せずにプロジェクトにコードを追加することはできないため、以前にプロジェクトに静かに追加されたコードの量を直接発見しました。

レビュープロセスは、ブランチの所有者がレビューボードに差分を送信し、「レビュー用」の下にブランチ名（私たちはかんばんベースのワークフローがあります）を含むホワイトボードに緑色のポストイットを置くか、または完成したユーザーの一部である場合に始まります。ストーリー、ストーリーカード全体を「レビュー用」に移動し、その上にポストイットを配置します。リリースマネージャーは、カードとポストイットを「テストの準備完了」に移動し、製品の所有者は次のテストリリースに含めるものを選択できます。

マージを実行するとき、リリースマネージャは、マージコミットに製品所有者の変更ログで使用できる適切なコミットメッセージがあることも確認します。

リリースが本番環境に配置されると、タグはブランチの新しいベースとして使用され、既存のすべてのブランチがマージされます。この方法では、すべてのブランチに共通の親があり、マージの処理が簡単になります。

「検討しましたか」という投稿も追加します。

バザールの優れた点の1つは、その柔軟性です。これは、他のすべての分散システムに勝るものです。Bazaarを集中モード、分散モード、または両方で操作できます：両方（開発者が快適なモデルまたはワークグループに最適なモデルを選択できることを意味します）。また、外出中に集中リポジトリを切断し、戻ったときに再接続することもできます。

その上、優れたドキュメントと、企業を幸せにする何か：商用サポートが利用可能です。

• Github FIなどの適切なWebインターフェイスをインストールする
• 人々を快適に保つために、（最初は）比較的集中化されたモデルに固執します。
• すべてに対して継続的インテグレーションビルドを実行する共有ブランチ。
• グローバルgit構成オプションの適切なセットを共有します。
• シェルにgitを統合し、bash補完を行い、現在のブランチでプロンプトを表示します。
• マージツールとしてIntelliJのGit統合を試してください。
• 必要に応じて.gitignoreを使用してください。

ポイント3と4（ユーザーごと、セクションごと、ブランチごとのアクセス許可）については、gitoliteをご覧ください（Pro Gitブック：http : //progit.org/book/ch4-8.htmlで説明されています）。）。

政治的であろうとなかろうと、Gitは他のDCVSと同じくらい良い選択です。他の強力なツールと同様に、ツールがどのように機能するように設計されているかを理解するために少し前に時間を費やす価値があります。このため、Pro Gitブックを強くお勧めします。それに数時間費やすことで、長期的には多くのフラストレーションを節約できます。

GUI：現時点では、TortoiseGit v1.7.6はほとんどの日常的な操作で問題ありません。ログ、コミット、プッシュ、プル、フェッチ、差分、マージ、ブランチ、チェリーピック、リベース、タグ、エクスポート、スタッシュ、サブモジュールの追加など... x64もネイティブでサポート

多くの開発者がいる開発チームでgitを効率的に使用するには、ビルドとテストを継続的に行うCIシステムが必要です。ジェンキンスはそのような車両を提供しており、私はそれを強くお勧めします。統合の部分は何があっても実行する必要があり、それをより早く、より頻繁に行う方がはるかに安価です。

gitosisやgitoliteよりも共同開発に適していますが、オープンソースはGitoriousです。これは、リポジトリの管理とマージを処理するRuby on Railsアプリケーションです。それはあなたの問題の多くを解決するはずです。

Gitではプライベートブランチを作成できます。これにより、開発者は頻繁にコミットして、変更を小さなコミットに分解することができます。開発者が変更を公開する準備ができたら、中央サーバーにプッシュします。必要に応じて、事前コミットスクリプトを使用してコードを検証できます。

NXPはGitとSubversionを1つの共通プラットフォーム（エンタープライズ規模）で管理しており、Androidモバイル開発を従来のソフトウェアプロジェクトと統合しています：http : //www.youtube.com/watch?v=QX5wn0igv7Q