Clearcase Vs git version control [fechado]

@zzz777: a sua pergunta foi feita numa visão central tão clara que não foi compreensível para pessoas que nunca usaram o ClearCase antes. Na verdade, o Git está anos-luz à frente da ClearCase, são os SCMs comerciais que precisam alcançar os sistemas OSS.

Tenho experiência tanto com o ClearCase como com o git e posso dizer-lhe que a funcionalidade do ClearCase do Find merges (mis)é um resultado do seu design (fundamentalmente quebrado) baseado em ficheiros de versão, mas no git não precisa de tal ferramenta primitiva para fundir ao seu ramo privado o ramo partilhado. ClearCase é orientado a arquivos, e checkin-s são baseados em arquivos, é por isso que você precisa do Find (arquivos) para fundir utilitário, mas o git é baseado em commit, e esse é o modelo certo, uma vez que quando você corrige um problema ou implementa uma funcionalidade, todo o changeset ou nenhum deles são as únicas opções que fazem sentido.

O Git tem uma funcionalidade de junção muito poderosa e faz a coisa certa, e há duas maneiras de fazer o que está a pedir (actualização seu ramo privado para ser o ramo compartilhado + suas alterações).

O mais óbvio é fazer uma fusão, por isso, enquanto estiver no seu ramo privado, basta fazer:

git merge sharedbranch

Então, se houver conflitos (realmente muito mais raros do que no ClearCase), ou resolvê-los e {[[9]}

git commit

E pronto. Como um Bônus, porque o git tem toda a história localmente, você não tem que desperdiçar incontáveis horas, se você tem muitos arquivos, como você faz no ClearCase, a junção é muito rápido, pelo tempo ClearCase em um o dynamic view faz uma junção de 10 arquivos, o git provavelmente terminará a junção de 100, facilmente.

Se usar a junção do git significa que preserva o histórico e se o seu histórico se assemelhar a este antes da junção:

o---1---2---3 (sharedbranch)
 \
  a---b---c (privatebranch)

Depois da fusão, ficará assim:

o---1---2---3 (sharedbranch)
 \           \
  a---b---c---m (privatebranch)

Isto preserva a história das suas mudanças e pode permitir que outros revejam o seu trabalho. E lembre-se, estes não são histórias de revisão de arquivos, estes se o histórico da árvore, que é a única história que faz sentido armazenar, mesmo que os ramos diferem apenas por 1 ou 2 arquivos, o estado que você quer preservar é a árvore, não um arquivo.

A segunda opção é usar rebase, o que significa que você faz com que pareça que todas as suas alterações foram feitas a partir do último código no ramo compartilhado.

O comando que usa (novamente, enquanto está no ramo privado):

git rebase sharedbranch

A árvore de história vai mudar de:

o---1---2---3 (sharedbranch)
 \
  a---b---c (privatebranch)

A

o---1---2---3 (sharedbranch)
             \
              a'--b'--c' (privatebranch)

Por isso, se deres algum tempo ao git ... entendê-lo, e usá-lo um pouco, você vai ver o quanto melhor é o modelo git e como quebrado o modelo ClearCase é.

BTW, o problema do gémeo do mal no ClearCase simplesmente não existe no git porque o git não segue directórios (confie em mim, você não precisa disso).

Além disso, se você já teve um esquema de configuração que é um pouco mais complicado com vários ramos e você migrou arquivos de um ramo para o outro, você provavelmente sabe o quão importante a ordem das regras na configuração spec é, e quão frustrante é ver versões antigas de arquivos porque a spec de configuração é "errado". Isso acontece na ClearCase devido ao seu design básico, e, escusado será dizer, esse tipo de porcaria não pode acontecer na git.

Então, para concluir, o git não tem uma ferramenta primitiva como "encontrar a junção" porque não precisa dela. Ele tem um modelo superior e um modelo superior merge que realmente funciona. É muito rápido em comparação com o ClearCase (CCRC static view ou dynamic view, Você pode chamá-lo).

A apenas o local onde o ClearCase poderá ter uma aresta é a actualização instantânea da janela dinâmica, mas isso também é atenuado pelo facto de poder escrever mais rapidamente git checkout branch do que pode actualizar a espectrula de configuração.

Problemas que tive num escritório profissional misto:

História Mutável.
Você pode fazer algumas coisas realmente tolas (e poderosas) com GIT. Isso pode causar perda de fonte.
1. Fusão Automática.
   Esta é a melhor característica do git. Mas tivemos de desligar o desenvolvimento durante uma semana para encontrar o código fonte que desapareceu. MSVS tem um problema feliz com mudanças aleatórias de terminações de linha e se você não puxar do repositório regularmente ele fica confuso, e as mudanças obter perdido.
2. Ordem de empurrar / puxar.
   O Clearcase trata do pedido de data e do histórico para si, mas o git ignora-o.
Encenação.
Clearcase (pelo menos UCM) lida com a promoção de branch e outras coisas para você. O Git não. Terá de gerir isto com cuidado. $ID$
Não existe para o git. O rastreamento de versões de lançamentos reais e a descoberta de problemas a partir de saber qual é a versão do arquivo fonte terá de ser manuseado manualmente. (Eu não tenho certeza de qual seu processo de liberação e).

Para você repositório de código final, eu poderia sugerir um repositório de lançamento ou outro sistema de controle de fonte ou um repositório de git separado, que é gerenciado e só aceita puxa.

Estou a usar o git para o meu projecto solo e está tudo bem. Mas, em uma casa de habilidade mix com uma variedade de editores eu teria cuidado. Podes mesmo rebentar-te o pé sem saberes com o Git.

Não usei nem hg nem bzr. Talvez valha a pena olhar para estes como alguns dos os problemas desaparecem e eles têm características para mitigar alguns dos problemas acima.

Espero que isto ajude.

Como mencionei em " Quais são os conceitos básicos do ClearCase que todos os programadores devem saber?[[5]}", ClearCase pode ter algumas características "descentralizadas" com seus repos multi-site, mas ainda um CVCS em seu núcleo:

• Ele tem uma forte ligação com o user-id do sistema (que não é relevante em um DVCS, onde não há um referencial único do Usuário).

• Tem um acordo de recompra único para a gestão de etiquetas e nomes de ramificações (admin vob), enquanto você pode definir um' test ' em 15 repos git diferentes sem problema (exceto que você precisa saber o que repo1/test significa, em relação a repos2/test).

• Ele também centraliza uma definição de fluxo de trabalho de merge através da hierarquia de fluxo (UCM) (você pode visualizar onde você deve mergir um trabalho de um fluxo para outro).

• Propõe através da UCM uma definição de subconjunto de códigos (componente), com gestão de dependências. O Git só tem submódulos, sem sobrepor / sobrepor a detecção mecanismo.

• Ele gerencia qualquer tipo de arquivos, mesmo grandes binários, enquanto um DVCS (qualquer tipo de DVCS) é melhor fora de gerenciar apenas o código fonte.

A linha de fundo (na nossa migração do ClearCase para o Git) é que envolve bastante alguns refactoring/reorganização do código fonte, a fim de ter repositórios Git gerenciáveis.

Trabalhei com o Git e com o ClearCase e assim que aprenderes a usar o Git e depois fizeres a troca, nunca mais vais olhar para trás. Certifique-se de que você tem tempo para treinar seus desenvolvedores -- esta deve ser a sua prioridade máxima. Git é uma abordagem totalmente diferente do SCM do que ClearCase.

Algumas coisas a considerar (possíveis desvantagens):

1. você vai precisar de umverdadeiro mestre repo, não apenas alguém para cuidar da fonte, mas alguém que entende como o SCM realmente funciona (não apenas o que uma interface gráfica mostra para eles) e pode lidar com o seu modelo de ramificação (ver #2)
Adoptar / desenvolver um modelo de ramo robusto. Um grande exemplo, e um que eu usei é http://nvie.com/posts/a-successful-git-branching-model/ Vais ter de investir muito tempo a ajudar os teus devs a reaprender tudo o que pensavam que sabias sobre usar/interagir com o SCM.

Se conseguires superar os três acima, então há muito pouca desvantagem (#3 sendo a mais difícil.) Quanto ao @PAntoine, a maioria dessas questões estão relacionadas com o treinamento -- #1 teria que exigir uma decisão realmente ruim para perder o código fonte. git reflog dar-lhe-á acesso a todos os compromissos do repo. A única maneira de destruir a fonte seria através git reflog expire --expire=whatever refs/heads/master, git fsck --unreachable, git prune, e git gc, que só deve ser tratado pelo mestre do repo -- e depois há a questão universal de um desenvolvedor não cometer a sua fonte (d'Oh!)

Você precisa de uma ferramenta para ajudá-lo com o seu gerenciamento de configuração de software (SCM) ou o seu controle de versão [system] (VCS)?

É a isso que se resume a discussão ClearCase vs Git. Por assim dizer, estás a comparar maçãs com laranjas. Pensar em ClearCase como apenas outro VCS é uma visão estreita do que é ClearCase; fique com ClearCase se o seu objetivo é enviar o produto certo para fora de sua loja. Por outro lado, o Git é provavelmente o melhor VCS do mundo. o mercado neste momento, (embora não ofereça qualquer suporte SCM) então você muda para ele se a sua preocupação é ramificar e fundir .... (a side note the merging conflicts are the result of a poorly set base line and improperly configured views)... A replicação do VOB é uma porcaria.

A desvantagem da tua jogada planeada é que vais deitar fora o teu suporte de ferramentas SCM. E você terá que enfrentar uma miríade de outras ferramentas e muito trabalho manual para alcançar o que você tinha fora de a caixa com o ClearCase.

De qualquer forma, um bom VCS é a espinha dorsal de qualquer SCM, por isso a tua mudança para o Git pode compensar a longo prazo.