[解決済み] 企業におけるGitベースのソース管理。推奨されるツールとプラクティス？

質問

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

しかし今、仕事場ではそれが義務付けられ、率直に言って、問題を抱えています。

特に、Perforce や Subversion のような他のソース管理システムと比較すると、そのような環境を対象としています。(そう、Linus がそのようなことを意図していないことは知っています)。

しかし - 政治的な理由から - 私たちは git に固執しています。たとえそれが、私たちがそれでやろうとしていることに対して最悪であったとしても。

以下は、私たちが目にしていることの一部です。

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

しかし、大規模な開発組織でgitをうまく使っている人がいると聞いたことがあります。

もしあなたがそのような状況にあるのなら、あるいは一般的に、コマンドラインを好まない人々がいる大規模な組織で git をより簡単に、より生産的に使うためのツールやヒントやトリックを持っているなら、私はあなたが何か提案するのを聞くのが大好きです。

ところで、私は LinkedIn ですでにこの質問のバージョンを尋ねましたが、本当の答えは得られませんでした。

UPDATE: はっきりさせましょう...

私が働いているところでは、git 以外は使えません。 . それは選択肢ではありません。git に縛られています。mercurial, svn, bitkeeper, Visual Source Safe, ClearCase, PVCS, SCCS, RCS, bazaar, Darcs, monotone, Perforce, Fossil, AccuRev, CVS, あるいは 1987 年に私が使った Apple の good ol' Projector も使うことができません。ですから、他の選択肢を議論するのは歓迎しますが。 git について議論しないなら、賞金をもらうことはできないでしょう。

また、私が探しているのは 企業で git を使用する方法についての実用的なヒントを探しています。 . 私はこの質問の一番上に、私たちが抱えている問題の洗濯物リストを載せました。繰り返しになりますが、人々が理論について議論することは歓迎されますが もしあなたが賞金を稼ぎたいなら、解決策を教えてください。

どのように解決するのですか？

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

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

ここでは、一般的な長所/短所について話すことはしませんが、むしろあなたのコンテキストに焦点を当てます。DVCS を使用すると、集中型システムを使用するよりも規律正しいチームが必要になるというのが、一般的な考え方です。これは、集中型システムを使用すると、次のような簡単な方法が得られるからです。 強制する ワークフローを実施する簡単な方法を提供するからです。一方、分散型システムを使用するには より多くのコミュニケーション そして、確立された慣習を守るための規律が必要です。これはオーバーヘッドを誘発するように見えるかもしれませんが、私は、それを良いプロセスにするために必要なコミュニケーションの増加という点で有益だと考えています。あなたのチームは、コード、変更、そして一般的なプロジェクトの状況についてコミュニケーションをとる必要があります。

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

DVCSは実験のための素早い分岐を推奨しています。 実験ができます。Subversionでもブランチ を行うことができますが、ブランチが が全員に見えるという事実があります。 実験的な作業のためにブランチをオープンすることを 実験的な作業のためにブランチを開くことを躊躇させてしまいます。同様に、DVCS は作業のチェックポイントを推奨しています。 不完全な変更をコミットすると コンパイルもテストも通らないような不完全な変更をローカルリポジトリにコミットすることです。 ローカルリポジトリにコミットすることです。ここでも の開発者ブランチでこれを行うこともできます。 Subversion の開発者用ブランチでこれを行うこともできますが、このような ブランチが共有スペースにあるため の開発者ブランチで行うこともできますが、そのようなブランチは共有スペースにあるという事実が、人々がそうする可能性を低くしています。

DVCS は、単純なテキストの差分ではなく、有向無サイクルグラフ (DAG) のグローバルにユニークな識別子によるチェンジセットの追跡を提供するので、柔軟なワークフローを可能にします。これにより、チェンジセットの起源と履歴を透過的に追跡することができ、これは非常に重要なことです。

ワークフロー。