Переход от ClearCase к Git - PullRequest
Новая
       4

Переход от ClearCase к Git

1 голос
/ 18 августа 2010

Я работаю в фоновом режиме ClearCase, где у нас (проще говоря) рабочий процесс, состоящий из трех этапов, когда крайний левый ствол был нестабильным, средний ствол - гарантией качества, а самый правый - стабильным. то есть.) 

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

Как видите, стабильная магистраль содержит только версии, которые были квалифицированы. У меня проблемы с репликацией этого рабочего процесса в Git, так как версии B, C и D также помещаются в магистраль QA и впоследствии в стабильную магистраль. На мой взгляд, это побеждает цель «чистого» багажника, содержащего только стабильные версии.

Теперь, очевидно, есть фундаментальные различия между Git и ClearCase, которые, я уверен, объясняют, почему у меня возникают проблемы с использованием моих предыдущих концепций для определения рабочего процесса.

Я уже несколько дней пытаюсь обернуть голову вокруг этих новых инструментов SCM (я тоже смотрел на Mercurial), и действительно может использовать некоторые указатели о том, как действовать . Мы работаем на ПК под управлением Mac и Windows, и подавляющее большинство команд предпочитают инструменты с графическим интерфейсом по сравнению с командной строкой.

Спасибо! : -)

1 Ответ

3 голосов
/ 18 августа 2010

Сначала вы можете прочитать это сравнение между ClearCase и Git

Как объяснено в Промежуточное звено между подмодулями и ветвями? , единственное понятие, которое может вас обмануть при переходе из ClearCase, это понятие композиции (наследование конфигурации): см. Гибкость против статическое ветвление (GIT против Clearcase / Accurev) .

ClearCase работает файл за файлом (или действием по виду деятельности, причем каждое действие является группой файлов).
Git работает от дельты блоба до дельты блоба (каждый блоб представляет контент : если два файла имеют одинаковое содержимое, будет сохранен только один "блоб")

Это означает, что то, что вы пытаетесь сделать в ClearCase с помощью веток / потоков и действий (если вы используете UCM), с большей вероятностью будет достигнуто с помощью:

  • переупорядочение коммитов (rebase --interactive, то есть «мерзавец», и не рекомендуется в mercurial)
  • и / или публикация (которая является ортогональным размером для разветвления, характерным для DVCS)

переупорядочение + слияние (только для коммитов, которые еще не "опубликованы", т.е. не отправлены):
Вы изменяете порядок изменений, примененных к вашему коду, чтобы объединить только то, что вам нужно. 

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
  • переупорядочение + публикация (push):

Вы также можете представлять каждое продвижение кода в собственном git-репо.
Как только коммиты будут в правильном порядке, вы отправляете соответствующие ветки в репозиторий QA или стабильный репо.

Переупорядочение (переписывание истории):

Смотри также:

...