ClearCaseからGitへの移行

clearcase git workflow
ClearCaseからGitへの移行

ClearCaseのバックグラウンドから来ています。単純に言えば、左端のトランクが不安定で、中央のトランクが品質保証で、右端が安定している3つのステップで構成されるワークフローがありました。 つまり)

A  A  A
|  |  |
B  C  |
| /|  |
C  |  E
|  | /
D  E
| /
E

ご覧のとおり、安定したトランクには、認定されたバージョンのみが含まれています。 バージョンB、C、およびDもQAトランクにプッシュされ、その後安定したトランクになるため、Gitでこのワークフローを複製する際に問題が発生しています。 私の目には、これは安定したバージョンのみを含む「クリーン」なトランクの目的に反します。

GitとClearCaseには明らかに根本的な違いがあります。これは、以前の概念を使用してワークフローを指定するのに問題がある理由を説明していると確信しています。

私はこれらの新しいSCMツール(私はMercurialも見てきました)に頭を巻きつけようとして数日が経ちましたが、実際に進め方についていくつかの指針を使うことができました*。 私たちはMacとWindows PCで開発しており、チームの大半はコマンドラインよりもGUIツールを好みます。

ありがとうございます。 🙂

  1  1


ベストアンサー

まず、これを読むことができますhttps://stackoverflow.com/questions/645008/what-are-the-basic-clearcase-concepts-every-developer-should-know/645771#645771[ClearCaseとGitの比較]

https://stackoverflow.com/questions/932586/middle-ground-between-submodules-and-branches/932868#932868 [サブモジュールとブランチの間の中間?]で説明されているように、あなたをだます可能性のある概念ClearCaseから来る場合は構成の概念です(構成の継承):https://stackoverflow.com/questions/763099/flexible-vs-static-branching-git-vs-clearcase-accurev/764219#764219[Flexible vs static分岐(GIT対Clearcase / Accurev)]。

ClearCaseはファイルごとに動作します(またはアクティビティごとのアクティビティ。各アクティビティはファイルのグループです)。 + Gitはblob delta by blob deltaで動作します(各blobは_content_を表します:2つのファイルのコンテンツが同じ場合、1つの「blob」のみが保存されます)

つまり、ブランチ/ストリームおよびアクティビティを通じてClearCaseで実行しようとしていること(UCMを使用している場合)は、次の方法で達成される可能性が高くなります。

並べ替え+マージ(まだ「公開」されていない、つまりプッシュされていないコミットのみ):+必要なものだけをマージするために、コードに適用された変更デルタを並べ替えています。

trunk => trunk'  QA => QA'  stable
  A        B'
  |        |
  B        D'
  |        |
  C        A'----A'    C''
  |        |     |     |
  D        C'    C'    A''--  A''  (--: merge to branch)
  |        |     |     |      |
  E        E     E     E      E
  • 再注文+出版(プッシュ):

独自のgitリポジトリで各コードプロモーションを表すこともできます。 +コミットが適切な順序になったら、関連するブランチをQAリポジトリまたは安定したリポジトリにプッシュします。

” ” ‘

並べ替え(履歴の書き換え)は次のとおりです。

また見なさい:

3


タイトルとURLをコピーしました