gitメタデータ戦略をClearCaseのものと比較するにはどうすればいいですか？

Question

私の以前の開発者の生活では、Clearcaseはバージョン管理のための10年以上のツールでした。今私が働いている組織は、4年後にgitに移行しました。クリアケースでは、リポジトリやブランチやラベルなど、アイテムのすべてのレベルの属性など、簡単にアクセス可能なメタデータ構造があります。 git notesは存在しますが、いくつかのWebサーフィンの後、私はこれを効率的に行う明確な方法とその理由を見つけていません。たとえば、UCM ClearCaseのベースラインプロモーションレベルは、私がgitでシンプルにすることを望む良いコンセプトです。私は、この特定の問題のために表す

開発コミュニティの統計：< 100開発者は、< 5メジャーリリースブランチ、< 100顧客パッチ支店、コードベースサイズ：コードの< 1000000ライン。

したがって、適切なメタデータ戦略とツールが必要です。

はClearCaseのでは、次のメタデータの構築物は、存在する：

• 標識（一般的な使用法：外部SW配信に含まれるすべてのファイルのリビジョンを指摘）

• 属性は、ラベルまたはブランチに適用することができる。

  • label属性は、一般的な使用を任意の値を持つことができます。ラベルの状況を伝える：TEST_RESULT：OK | NOKまたはCUSTOMER_AVAILABILITY：GENERAL |限定| INTERNAL_ONLY
  • 分岐属性、一般的な使用法：BRANCH_STATUS：ACTIVE | OBSOLETE

• ステータス属性 とラベルの一形態であるUCMベースライン（例えば以下を参照してくださいhttps://www-304.ibm.com/support/docview.wss?uid=swg21135893）マージを指定するのに使用される

• ハイパーリンク（例えば方向）特に

：

• ラベル+私は10年以上のためのClearCaseを使用した後に、確認して、gitのは、単純なメタデータについてであることを年7+のためのgit BRANCH_STATUS

Answer 1

に明確さをもたらすことができるTEST_RESULT

ブランチ+属性のために使用することができる建設属性：タグ、ブランチ、ブロブ、コミット、日付、著者、実行ビット、...それはかなりです。
追加のプロパティはgitノートで管理されます。

私の古い答え "What are the basic ClearCase concepts every developer should know?"では、GitとClearCaseの比較を見ることができます。

• マージワークフロー（およびbranch strategy）：

  メタデータのすべてのリリース管理の種類のいずれかによって管理されています。 git-flowが最も有名ですが、certainly not the only oneです。

• 公開ワークフローでは、同じリポジトリの複数のインスタンスを管理していました（gitで使用される分散モデルでは、リポジトリをクローンする必要があります）。
  テストがトリガされたQAリポジトリにプッシュする前に、 "有効な"コミット（コードのコンパイルとテストの受け取りを知っていることを意味する）だけを受け付けた、礼儀のあるレポにプッシュすることができます。
  これは、またはcode reviewを使用して、 "guardedコミット"アプローチです。

分散モデルでは、「Distributed Version Control Systems and the Enterprise - a Good mix?」のように、認証や承認に関連するものはすべて削除されています。

---

• ラベル：gitのノートによって、または専用支店を持つか、専用のレポで管理：これらは属性
• （すべてのレポのために）Gitのタグで行われます。
• UCMベースライン：（あなたは、通常のラベルと区別したい場合は、命名規則で）再びタグ
• ハイパーリンク：gitの（インクルードは任意の中間「ハイパーリンク」せずにコミットタグ参照）には必要ありません。マージは、マージの感覚を明確に示す親のコミットを「マージコミット」として記憶されます。
  gitに親/子ストリームがない（ブランチのみ）ので、同じ "配信/リベース"の意味を持ちません。

注意：gitでは、repoはUCMコンポーネントに似ています。