GIT vs. Perforce- Dois VCS vai entrar ... um vai deixar [fechado]

https://stackoverflow.com/questions/222782

03-07-2019
|

Pergunta

Então, eu estou no processo de obtenção GIT vendidos no trabalho. Primeira necessidade coisa que é convencer a todos que GIT é melhor no que eles já estão acostumados a fazer. Atualmente usamos Perforce. Qualquer outra pessoa passar por uma venda semelhante? Qualquer bom links / aconselhamento?

Uma das grandes vitórias é que podemos trabalhar com ele desconectado da rede. Outra vitória IMO é a maneira acrescenta / checkouts são manipulados. Mais pontos são bem-vindos! Também temos cerca de 10-20 devs total.

Solução

O código fonte intérprete Perl 5 está actualmente a atravessar as vias de conversão de Perforce para git. Talvez importador git-p4raw de Sam Vilain é de interesse.

Em qualquer caso, uma das maiores vitórias que você vai ter sobre cada VCS centralizado e os mais distribuídos também é cru, bolhas velocidade . Você não pode imaginar como libertadora que é ter toda a história projeto na mão, meras frações de frações de um segundo de distância, até que você tenha experimentado. Mesmo a gerar um registo de toda a história do projecto que inclui uma comparação completa para cada consolidação pode ser medida em fracções de um segundo cometer. Git é tão rápido o seu chapéu vai voar. VCSs que têm de ida e volta através da rede simplesmente não tem chance de competir, nem mesmo através de uma ligação Gigabit Ethernet.

Além disso, git torna muito fácil de ser cuidadosamente seletivo ao fazer commits, permitindo assim alterações na sua cópia de trabalho (ou mesmo dentro de um único arquivo) a ser distribuída ao longo de vários commits - e em diferentes ramos se você precisa disso. Isso permite que você faça menos notas mentais durante o trabalho - você não precisa planejar seu trabalho com tanto cuidado, decidir de antemão o conjunto de mudanças que você cometeu e certificando-se de adiar qualquer outra coisa. Você pode apenas fazer as alterações que deseja que eles ocorrem para você, e ainda desembaraçá-los - quase sempre com bastante facilidade - Quando é hora de cometer. O esconderijo pode ser uma ajuda muito grande aqui.

Eu descobri que em conjunto, esses fatos me fazem fazer naturalmente muitos mais e muito mais focada commits que antes eu usei git. Isto não só por sua vez faz com que sua história geralmente mais útil, mas é particularmente benéfico para ferramentas de valor agregado, tais como git bisect .

Eu tenho certeza que existem mais coisas que não posso pensar agora. Um problema com a proposição da venda de sua equipe sobre git é que muitos benefícios estão inter-relacionados e jogam entre si, como sugerido acima, de tal forma que é difícil simplesmente olhar para uma lista de características e benefícios do git e inferir como eles vão mudar seu fluxo de trabalho, e que as mudanças vão ser melhorias genuínos. Você precisa levar isso em conta, e você também precisa de apontá-lo explicitamente salientar.

Outras dicas

Eu uso Perforce no trabalho. Eu também uso Git porque eu ainda gostaria de alguma forma de controle de versão, quando eu estou trabalhando em código e não pode se conectar ao servidor. Não, trabalhar offline reconciliação só não é o mesmo. Aqui é onde eu encontrei git para ser um grande benefício:

Ramificação velocidade -. Git leva alguns segundos, no máximo
Conflitos - auto determinação de P4Merge destruída valor de uma semana de trabalho uma vez. Desde então eu preferiria resolver a mão ao mesclar. Quando Git leva-me sobre um conflito, é realmente um conflito. O resto do tempo, RESOLVE git coisas corretamente e eu salvar montes de tempo.
Manter o controle de fusões - Se você tem um ramo que é continuamente recebendo fusões de dois outros ramos, você sabe o que uma dor de cabeça, isso pode ser com forçosamente. Com git, a dor de cabeça é minimizado porque o resultado de uma mesclagem no git é na verdade um novo commit que sabe que seus antepassados ??são.
Permissões - Tenho pista perdida do número de vezes que eu tentei trabalhar em um arquivo, mas não podia porque não foi verificado no Perforce. Se você trabalhou com o Xcode (ou qualquer editor que não tem um sólido plug-in Perforce SCM) offline, você sabe como irritante isso pode ficar. Eu não precisa se preocupar com isso com Git. Eu faço as minhas alterações. Git não me e faixas-los parar no fundo.
Mantendo o principal arrumado árvore - Com git, eu posso classificar meus commits e arrumar o código de modo que a história agradável aparência e arrumado. Nada disso "check-in este arquivo porque ele era suposto ser parte do anterior checkin" lixo. I esmagar commits como essa, porque ajuda ninguém.
Stashing -. Suas necessidades do servidor Perforce ser a versão 2010.1 ou mais recente para usar o comando P4 prateleira
Criação de manchas - fácil de fazer em git. Não sei se é possível, em Perforce sem usar a linha de comando.
Mailing manchas do GUI -. Novamente, vitórias git aqui
O espaço em disco - Com forçosamente, cada ramo é uma cópia. Isso significa que se sua árvore fonte é enorme, o espaço em disco é comido rapidamente. Isto não é mesmo contando o espaço adicional uma vez que você começar a construir. Por que ainda têm uma ligação entre ramos e espaço em disco? Com git, você pode ter 100 agências e apenas um ramo em um momento já existe. Se você quiser especificamente para o trabalho em duas versões simultaneamente você pode clonar, fazer o seu trabalho e, em seguida, se livrar de um clone, se quiser, sem perder nada.
Se você estiver em XCode4, suporte forçosamente foi descartado e apoio git agora é construído em. Se você fazer o trabalho multiplataforma como eu, isso importa muito. Com o Visual Studio, você pode usar extensões git. Com forçosamente, é igualmente eca em ambos os sistemas operacionais. Bem, talvez um pouco mais sobre mac agora com XCode4 em cena.
Encontrar o checkin com defeito (ou, git bisect regras) - já tentou fazer uma busca binária com forçosamente para descobrir onde um erro foi introduzido? Bastante incómodo, sim? Ainda mais de um aborrecimento, quando houve integra de outros ramos no meio. Por quê? Porque não há nenhum automação para tais tarefas. Você precisa escrever a sua própria ferramenta de falar com forçosamente e você geralmente não têm o tempo. Com git, você dar-lhe os pontos de partida (o ponto "bom" e ponto "ruim") e automatiza a pesquisa para você. Ainda melhor, se você tem um script que pode automatizar o processo de construção e teste, você pode ligar git-se para o script e todo o processo de encontrar o check-in é automatizado. É assim que deve ser.
Acompanhamento de alterações em refatora - Tente divisão BigClass em SmallClass1 e SmallClass2. Para Perforce, BigClass já deixou de existir e duas novas classes (SmallClass1 e SmallClass2 aderiram à árvore de origem). Para Perforce, não há nenhuma relação entre BigClass e SmallClass1 e SmallClass2. Git, por outro lado, é inteligente o suficiente para saber que x% de BigClass está agora em SmallClass1 e y% de BigClass está em SmallClass2 e que BigClass tem ceased de existir. Agora, do ponto de vista de alguém que está revisando alterações em vários ramos, diga-me qual abordagem você gostaria de encontrar mais útil - Git do ou Perforce de. Pessoalmente, eu prefiro a abordagem de Git, pois reflete com mais precisão a mudança real no código. Git é capaz de fazer isso porque ele controla o conteúdo dentro do arquivo e não o próprio arquivo.
centralizada ou descentralizada: Git é um href="http://en.wikipedia.org/wiki/Distributed_revision_control" rel="noreferrer"> DVCS sistema enquanto forçosamente é centralizado. A centralizados VCS não pode ser descentralizada mais tarde, mas um DVCS (especialmente TGI) pode ser centralizado. Existem vários produtos que agreguem muito grão fino controle de acesso para git, se isso é algo que as necessidades de negócios. Pessoalmente, eu iria com um sistema que me dá maior flexibilidade a longo prazo.

mapeamentos Branch: Se você quer fazer ramificação direita no Perforce, você precisa criar um mapeamento ramo. Há razões para isso, mas estão ligadas à forma como Perforce conceitua um ramo. Como um desenvolvedor, ou uma equipe, isso simplesmente significa mais um passo no fluxo de trabalho, que eu não considero eficiente em tudo.

partilha de trabalho entre as equipes: Com Perforce, você não pode quebrar uma submissão. A equipe A está trabalhando no recurso A. equipa B no recurso B. equipa C funciona em correções de bugs. Agora, equipes A & B tem que corrigir um monte de erros, a fim de implementar as suas características. A única coisa é que eles não eram tão disciplinado quando cometer suas alterações (provavelmente porque eles estão correndo para um prazo) e assim os seus "correções" são partes de apresentações maiores, que também contêm material novo, tanto quanto o controle de versão em seu ramos estão em causa. No entanto, Equipe C está agora a fazer um ponto de libertação e gostaria de obter as correções das outras equipes. Se eles estavam usando Git, Equipe C pode cereja escolher alterações relevantes as outras equipas, dividi-los e só pegar o que eles precisavam sem se preocupar com a introdução de quaisquer características parcialmente implementadas. Com Perforce, Equipe C pode obter os arquivos afetados, mas teria que separar as alterações relevantes usando um processo muito mais manual.

Alterar plataforma - Se, por qualquer motivo, no futuro, você decidir mudar a sua plataforma de escolha, com Perforce, você está em à mercê de Perforce.com ea disponibilidade das ferramentas para a plataforma de sua escolha.

Mudando para o futuro motor incrível controle de origem X - Se você decidir Para alterar o que você usa para controle de origem, extraindo sua fonte controlar história do Perforce e movê-lo para novo sistema X é vai ser um pesadelo, porque ele é fechado e o melhor que você pode fazer é adivinhar - apenas o Google para Perforce à migração Git para get uma noção do que estou falando. Pelo menos com Git, sua aberto source, por isso elimina um monte de adivinhação envolvidas.

Bem, isso é o meu 2 centavos. Em defesa do Perforce, eu tenho que dizer as suas regras de apoio ao cliente e assim que faz sua ferramenta Time Lapse View. Eu não sei como obter uma visão lapso de tempo com git. Mas, para a conveniência e economia de tempo, eu iria com git qualquer dia.

Eu levaria um monte de convencer a mudar de forçosamente. Nas duas empresas que eu usei isso era mais do que adequado. Essas foram as duas empresas com escritórios diferentes, mas os escritórios foram criados com muita infra-estrutura de modo que não havia necessidade de ter as características disjuntos / desligado.

Como muitos desenvolvedores que você está falando mudando ao longo?

A verdadeira questão é - o que é cerca forçosamente que não está atendendo às necessidades da sua organização que git pode fornecer? E da mesma forma, que fraquezas não git têm comparação com forçosamente? Se você não pode responder a isso sozinho, então perguntando aqui não vai ajudar. Você precisa encontrar um caso de negócios para sua empresa. (Por exemplo Talvez seja com menor custo total de propriedade (que inclui perda de produtividade para a fase de aprendizagem interino, custos administrativos mais elevados (pelo menos inicialmente), etc.)

Eu acho que você está em uma tarefa difícil - forçosamente é uma boa bastante para tentar substituir. É um brainer não se você está tentando arrancar fora PVCs ou ssafe.

Eu acho que em termos de manter as pessoas felizes durante / switch pós acabou, uma das coisas para atravessar início é apenas como privado uma filial local pode estar em Git, e quanto a liberdade que lhes dá a cometer erros. Levá-los todos para clonar-se alguns ramos particulares do código actual e, em seguida, ir selvagem lá, experimentando. Renomear alguns arquivos, coisas check-in, coisas de mesclagem de outro ramo, história retrocesso, rebase um conjunto de alterações em cima da outra, e assim por diante. Mostrar como até mesmo seus piores acidentes localmente não têm consequências para os seus colegas. O que você quer é uma situação onde os desenvolvedores se sintam seguros, para que eles possam aprender mais rapidamente (uma vez que Git tem uma curva de aprendizagem que é importante) e, eventualmente, de modo que eles são mais eficazes como desenvolvedores.

Quando você está tentando aprender uma ferramenta centralizada, obviamente, você vai estar preocupado em fazer alguma brincadeira que causa problemas para outros usuários do repositório. O medo de constrangimento sozinho é suficiente para desencorajar as pessoas a experimentar. Mesmo tendo um especial "treinando" repositório não ajuda, porque inevitavelmente desenvolvedores irão encontrar uma situação no sistema de produção que nunca viu durante o treinamento, e assim eles estão de volta para se preocupar.

natureza distribuída

Mas o Git não acabar com isso. Você pode tentar qualquer experiência em um ramo local, e se ele vai horrivelmente errado, apenas jogar o ramo de distância e ninguém precisa saber. Desde que você pode criar uma filial local de qualquer coisa, você pode replicar um problema que você está vendo com o repositório de verdade, ainda não há perigo de "quebrar a construir" ou de outra forma de fazer um tolo de si mesmo. Você pode verificar absolutamente tudo em, assim que você fez isso, não tentando trabalho em lote em pacotes pequenos puros. Assim, não apenas os dois principais alterações de código que você passou quatro horas hoje, mas também que construir correção que você se lembrou meio, eo erro de ortografia na documentação que você viu ao explicar algo a um colega, e assim por diante. E se as principais mudanças são abandonados porque o projeto está mudando de direção, você pode cereja escolher a correção de construção e o erro de ortografia fora de seu ramo e manter aqueles sem problemas.

O comando que me vendeu no git, pessoalmente, foi bisect . Eu não acho que esse recurso está disponível em qualquer outro sistema de controle de versão a partir de agora.

Dito isto, se as pessoas estão acostumadas a um cliente GUI para controle de origem que eles não vão ficar impressionado com git. Neste momento, o cliente só full-featured é de linha de comando.

características que Perforce são pessoas usando?

múltiplas áreas de trabalho em uma única máquina
changelists numeradas
ramos de Desenvolvimento
Integração com IDE (Visual Studio, Eclipse, SlickEdit, ...)
Muitos construir variantes
espaços de trabalho Composite
Integração de algumas correções, mas não outros
etc

Eu pergunto porque se todas as pessoas estão fazendo é pegar e colocar na linha de comando, git tem que cobria, e assim fazer todas as outras RTS.

GitHub agora oferecem cursos de formação git para empresas . Quoth seu post sobre isso :

Eu fui para baixo para o campus do Google um número de vezes nas últimas semanas de ajudar a treinar os Androids lá em Git. Fui convidado por Shawn Pearce (você pode conhecê-lo de sua glória Git e EGit / JGit - ele é o herói que assume maintanance quando Junio ??está fora da cidade) para vir para ajudá-lo a treinar os engenheiros do Google trabalhando em Andriod em < b> transição de Perforce para Git , então o Android poderia ser compartilhada com as massas. Eu posso te dizer que eu era mais do que feliz em fazê-lo.

[...]

Logical impressionante é agora oficialmente oferecendo este tipo de serviço de treinamento personalizado para todas as empresas, onde podemos ajudar a sua organização com formação e planejamento, se você está pensando em mudar para Git também.

grifo meu.

Eu tenho usado o Perforce por um longo tempo e, recentemente, eu também comecei a usar GIT. Aqui é a minha opinião "objetiva":

Perforce características:

ferramentas GUI parecem ser mais rico em recursos (por exemplo Tempo vista lapso, gráfico Revisão)
velocidade ao sincronizar a revisão cabeça (sem sobrecarga de transferir história toda)
Eclipse / Visual Integration Studio é muito bom
Você pode desenvolver várias características em um ramo por Changelist (ainda não estou 100% de certeza se isso é uma vantagem sobre GIT)
Você pode "espião" que outros desenvolvedores estão fazendo -. Que tipo de arquivos que tenham check-out

GIT características:

Eu tenho impressões que linha de comando git é muito mais simples do Perforce (init / clone, add, cometer. Nenhuma configuração de áreas de trabalho complexos)
velocidade ao acessar histórico do projeto depois de um check-out (tem um custo de copiar história toda ao sincronizar)
O modo offline (desenvolvedores não se queixam de que servidor P4 inalcançável vai proibi-los de codificação)
Criar um novo ramos é muito mais rápido
O servidor GIT "principal" não precisam de muito TBytes de armazenamento, porque cada desenvolvedor pode ter a sua própria caixa de proteção local
GIT é OpenSource - sem taxas de licenciamento
Se a sua empresa está a contribuir também para projetos Open Source, em seguida, compartilhando manchas é forma muito mais fácil com GIT

Em geral, para OpenSource / projetos distribuídos Eu sempre recomendo GIT, porque é mais como uma aplicação P2P e todos podem participar no desenvolvimento. Por exemplo, lembro-me que quando eu estava fazendo o desenvolvimento remoto com Perforce eu estava sincronização Projetos 4GB sobre link de 1Mbps uma vez por semana. Um monte de tempo foi simplesmente desperdiçada por causa disso. Também o que for necessário configurar VPN para fazer isso.

Se você tem uma pequena empresa e servidor P4 será sempre para cima, então eu diria que Perforce é também uma opção muito boa.

Temos vindo a utilizar Git por algum tempo, recentemente disco rígido do nosso servidor Git caiu e não poderíamos voltar para o último estado. Conseguimos voltar para alguns dias velho estado. Quando o servidor estava de volta. Todos na equipe puxado / empurrado suas mudanças e voila, o servidor está de volta ao estado atual.

A única diferença importante entre Perforce e git (e uma das mais comumente mencionado) é o seu respectivo manuseio de grandes arquivos binários.

Como, por exemplo, neste blog de um funcionário de uma empresa de desenvolvimento de jogos de vídeo: http://corearchitecture.blogspot.com/2011/09/git-vs-perforce-from-game-development.html

No entanto, o importante é que, a diferença de velocidade entre git e forçosamente, quando você tem um enorme repositório de 6GB, contendo tudo, desde a documentação para cada binário já construído (e, finalmente, oh sim! A história verdadeira fonte), geralmente vem do fato de que grandes empresas tendem a correr Perforce, e assim eles configurá-lo para descarregar todas as operações significativas para o banco servidor enorme no porão.

Esta vantagem importante da parte de Perforce vem apenas de um fator que não tem nada a ver com Perforce, o fato de que a empresa de executá-lo pode pagar referido banco servidor.

E, de qualquer maneira, no final, Perforce e git são produtos diferentes. Git foi projetado para ser apenas um VCS, e ele faz isso muito melhor do que Perforce (na medida em que tem mais recursos, que são geralmente mais fácil de usar, em particular, nas palavras de outro, ramificação em Perforce é como a realização de coração aberto cirurgia, que só deve ser feito por especialistas: P) ( http://stevehanov.ca/ blog / index.php? id = 50 )

Quaisquer outros benefícios que as empresas que usam ganho Perforce vieram simplesmente porque Perforce não é apenas um VCS, é também um servidor de arquivos, bem como ter uma série de outros recursos para testar o desempenho de compilações, etc.

Finalmente:. Git ser open-source e muito mais flexível para boot, não seria tão difícil de git patch para descarregar operações importantes para um servidor central, correndo montes de hardware caro

Eu acho que a única coisa que eu sei GIT ganha em é sua capacidade de "preservar fins de linha" em todos os arquivos, enquanto forçosamente parece insistir em traduzi-las em qualquer formato MacOS9 Unix, DOS / Windows ou ( "\ n" "\ r \ n" ou "\ r).

Esta é uma dor real se você estiver escrevendo roteiros Unix em um ambiente Windows, ou um ambiente de sistema operacional misto. Não é ainda possível definir a regra em uma base per-file-extensão. Por exemplo, seria converter .sh, .bash, arquivos .unix para o formato Unix, e converter .ccp, .bat ou .com arquivos para o formato DOS / Windows.

Em GIT (Eu não tenho certeza se isso é padrão, uma opção ou a única opção), você pode configurá-lo para "preservar fins de linha". Isso significa que você pode alterar manualmente os fins de linha de um arquivo e, em seguida, GIT vai deixar que o formato do jeito que está. Esta parece-me que a maneira ideal de fazer as coisas, e eu não entendo por que isso não é uma opção com Perforce.

A única maneira você pode conseguir este comportamento, é para marcar os arquivos como binário. A meu ver isso, que seria um corte desagradável para resolver uma característica ausente. Além de ser tedioso ter que fazer em todos os scripts, etc, seria também, provavelmente, quebrar a maioria dos diffs, etc.

A "solução" que tenha resolvido para, no momento, é para executar um comando sed para remover todos os retornos de carro a partir dos scripts cada vez que está implantado em seu ambiente Unix. Este não é o ideal, quer, especialmente porque alguns deles são implantados dentro de arquivos WAR, ea linha sed tem que ser executado novamente quando eles são descompactados.

Este é apenas algo que eu acho que dá GIT uma grande vantagem, e que eu não acho que foi mencionado acima.

EDIT: Depois de ter vindo a utilizar Perforce para um pouco mais, eu gostaria de adicionar outro par de comentários:

A) Algo que eu realmente sinto falta no Perforce é um diff clara e exemplo, incluindo arquivos alterados, removidos e adicionados. Isto está disponível em GIT com o comando git diff, mas em Perforce, os arquivos devem ser verificados antes de suas alterações são registradas, e enquanto você pode ter seus principais editores (como o Eclipse) configurado para verificar automaticamente os arquivos para fora quando você editá-los, você pode, por vezes, editar arquivos de outras formas (bloco de notas, comandos UNIX, etc). E novos arquivos não parecem ser adicionados automaticamente em tudo, mesmo usando Eclipse e p4eclipse, que pode ser bastante irritante. Então, para encontrar todas as mudanças, você tem que executar um "diff contra a ..." em todo o espaço de trabalho, que antes de tudo leva um tempo para ser executado, e em segundo lugar inclui todo o tipo de coisas irrelevantes a menos que você configurar listas de exclusão muito complicado, o que me leva ao próximo ponto.

B) Em GIT I encontrar o .gitignore muito simples e fácil de gerenciar, ler e compreender. No entanto, o espaço de trabalho ignorar / excluir listas configuráveis ??no Perforce parece pesado e desnecessariamente complexa. Eu não tenho sido capaz de obter quaisquer exclusões com wildcards trabalhando. Eu gostaria de fazer algo parecido

-//Server/mainline/.../target/...   //Svend_Hansen_Server/.../target/...

Para excluir todas as pastas de destino dentro de todos os projetos dentro Server / linha principal. No entanto, isso não parece trabalho como eu teria esperado, e eu acabei adicionando uma linha para cada projeto como:

-//Server/mainline/projectA/target/...  //Svend_Hansen_Server/projectA/target/...
-//Server/mainline/projectB/target/...  //Svend_Hansen_Server/projectB/target/...
...

e linhas semelhantes para as pastas de lixo, .classpath e arquivos .projet e muito mais.

C) Em Perforce existem os changelists bastante úteis. No entanto, supor que eu fazer um grupo de alterações, vê-los todos e colocá-los em uma lista de alterações, para o trabalho, em seguida, em outra coisa antes de enviar essa lista de alterações. Se eu mais tarde fazer uma alteração em um dos arquivos incluídos na primeira lista de alterações, esse arquivo ainda estará em que changelist, e eu não posso apenas depois submeter o changelist assumindo que ele contém apenas as mudanças que eu originalmente adicionado (embora serão os mesmos arquivos). Em GIT, se você adicionar um arquivo e lhes fazer outras alterações, não foram adicionadas essas mudanças (e ainda iria mostrar em um git diff e você não seria capaz de cometer o arquivo sem antes adicionar onovas mudanças também. Claro, isso não é útil da mesma maneira a lista de alterações pode ser como você só tem um conjunto de arquivos adicionados, mas em GIT você pode apenas confirmar as alterações, como que na verdade não empurrá-los. Você poderia lhes trabalhar em outras mudanças antes de empurrá-los, mas você não seria capaz de empurrar qualquer outra coisa que você adicionar mais tarde, sem empurrar os antigos mudanças também.

Eu não tenho nenhuma experiência com Git, mas eu tenho com Mercurial que também é um VCS distribuídos. Depende do projeto realmente, mas no nosso caso um VCS distribuídos adequado o projeto como basicamente eliminado frequente quebrado constrói.

Eu acho que depende do projeto realmente, como alguns são mais adequados para um VCS cliente-servidor, e outros towads um distribuída.

Aqui está o que eu não gosto sobre git:

Em primeiro lugar, eu acho que a idéia distribuídos voa em face da realidade. Todo mundo que está realmente usando git é fazê-lo de forma centralizada, mesmo Linus Torvalds. Se o kernel foi gerido de forma distribuída, isso significaria que eu não poderia realmente baixar os fontes do kernel "oficiais" - não haveria um - eu teria que decidir se eu quero versão Linus', ou versão de Joe, ou a versão de Bill. Isso, obviamente, seria ridículo, e é por isso que existe uma definição oficial que controla Linus usando um fluxo de trabalho centralizado.

Se você aceitar que você quer uma definição centralizada das suas coisas, então torna-se claro que as funções de servidor e cliente são completamente diferentes, então o dogma de que os softwares cliente e servidor deve ser o mesmo torna-se puramente limitante. O dogma de que o cliente eo servidor dados deve ser o mesmo torna-se patentemente ridículo, especialmente em uma base de código que tem quinze anos de história que ninguém se preocupa com mas todo mundo teria de clone.

O que nós realmente queremos fazer com todo esse material antigo é bung-lo em um armário e esquecer que ele está lá, assim como qualquer VCS normal faz. O fato de que lanços git tudo de volta e para trás através da rede todos os dias é muito perigoso, porque nags você podá-la. Que a poda envolve uma série de decisões tediosas e pode dar errado. Então, as pessoas provavelmente irá manter toda uma série de repos instantâneo de vários pontos na história, mas não era isso que o controle de origem foi no primeiro lugar? Este problema não existia até que alguém inventou o modelo distribuído.

Git incentiva as pessoas a reescrever a história, e o acima é provavelmente uma razão para isso. Cada VCS normal, faz reescrever a história impossível para todos, mas os administradores, e garante que os administradores não têm razão para considerá-lo. Corrija-me se eu estiver errado, mas tanto quanto eu sei, git fornece nenhuma maneira de conceder aos usuários normais acesso de gravação, mas proibi-los de reescrever a história. Isso significa que qualquer desenvolvedor com um rancor (ou que ainda estava lutando com a curva de aprendizagem) pode lixo toda a base de código. Como é que vamos apertar esse? Bem, ou você faz backups regulares de toda a história, ou seja, você manter o histórico quadrado, ou proibir o acesso de escrita para todos, exceto alguns pobre coitado que iria receber todos os diffs por e-mail e fundi-los com a mão.

Vamos dar um exemplo de um projeto bem financiado, grande e ver como git está trabalhando para eles: Android. uma vez que eu decidi ter um jogo com o próprio sistema android. Eu descobri que eu deveria usar um monte de scripts chamados repo para chegar a sua git. Alguns de repo é executado no cliente e alguns no servidor, mas ambos, pela sua própria existência, estão ilustrando o fato de que git é incompleta em qualquer capacidade. O que aconteceu é que eu era incapaz de puxar as fontes por cerca de uma semana e, em seguida, deu-se por completo. Eu teria que puxar um verdadeiramente grande quantidade de dados a partir de vários repositórios diferentes, mas o servidor foi completamente sobrecarregado com pessoas como eu. Repo foi o tempo limite e não foi capaz de retomar a partir de onde se tinha esgotado. Se git é tão distribuível, você teria pensado que eles teriam feito algum tipo de coisa peer-to-peer para aliviar a carga sobre aquele servidor. Git é distribuível, mas não é um servidor. Git + repo é um servidor, mas repo não é cos distribuíveis é apenas uma coleção ad-hoc de hacks.

Uma ilustração semelhante de inadequação do git é gitolite (e seu antepassado que, aparentemente, não funcionou tão bem.) Gitolite descreve seu trabalho como facilitando a implantação de um servidor git. Mais uma vez, a própria existência dessa coisa prova que git não é um servidor, não mais do que um cliente. Além do mais, ele nunca vai ser, porque se ele cresceu em ou ele estaria traindo seus princípios fundadores.

Mesmo se você acreditava na coisa distribuído, git ainda seria uma bagunça. O que, por instance, é um ramo? Eles dizem que você faz implicitamente um ramo cada vez que você clonar um repositório, mas isso não pode ser a mesma coisa que uma filial em um único repositório. Então, isso é, pelo menos, duas coisas diferentes a ser referido como ramos. Mas então, você também pode retroceder em um repo e apenas começar a editar. É que, como o segundo tipo de ramo, ou algo diferente de novo? Talvez isso depende do tipo de repo que você tem - oh sim - aparentemente o repo não é um conceito muito claro também. Há os normais e os nus. Você não pode empurrar para um normal porque a parte nua pode ficar fora de sincronia com a sua árvore de origem. Mas você não pode cvsimport para um bare cos eles não pensar nisso. Então você tem que cvsimport para um normal, clone que, para um nu que desenvolvedores de bater, e cvsexport que a um cvs exemplar, que ainda tem que ser verificada em cvs trabalho. Quem pode ser incomodado? Onde é que todas estas complicações vem? A partir da idéia em si distribuído. I abandonou gitolite no final, porque ele estava impondo ainda mais destas restrições em mim.

Git diz que ramificação deve ser leve, mas muitas empresas já têm um sério problema de desonestos ramo assim que eu ter pensado que a ramificação deve ser uma decisão importante com policiamento rigoroso. Este é o lugar onde forçosamente realmente brilha ...

Em forçosamente você raramente precisa ramos, porque você pode fazer malabarismos changesets de uma forma muito ágil. Por exemplo, o fluxo de trabalho habitual é que você sincronizar com a última versão do conhecido bom na linha principal, em seguida, escrever o seu recurso. Sempre que você tentar modificar um arquivo, o diff desse arquivo é adicionado à sua "changeset default". Ao tentar fazer check-in o conjunto de alterações, ele automaticamente tenta mesclar as notícias de linha principal em seu changeset (efetivamente rebasing-lo) e depois comete. Esse fluxo de trabalho é aplicada, mesmo sem você precisar de compreendê-lo. Mainline recolhe, assim, uma história de mudanças que você pode facilmente cereja escolher seu caminho através de mais tarde. Por exemplo, suponha que você queira reverter uma antiga, digamos, a um antes do penúltimo. Você sincronizar com o momento antes da mudança de ofensa, marcar os arquivos afetados como parte do conjunto de alterações, sincronização para o momento depois e mesclar com "sempre minha". (Havia algo muito interessante lá: a sincronização não significa ter a mesma coisa - se um arquivo é editável (ou seja, um conjunto de alterações ativos) não será derrotado pela sincronização, mas marcado como devido para resolver.) Agora você tem uma lista de alterações que desfaz a ofender um. Mesclar no noticiário posterior e você tem uma lista de alterações que você pode plop no topo da linha principal para ter o efeito desejado. Em nenhum momento nós reescrever qualquer história.

Agora, supondo a meio desse processo, alguém corre até você e diz-lhe para largar tudo e corrigir alguns erros. Você acabou de dar o seu changelist padrão um nome (um número na verdade), em seguida, "suspender"-lo, corrigir o erro na lista de alterações padrão agora vazio, cometê-lo, e retomar o changelist nomeado. É típico de ter várias changelists suspensas em um momento em que você tentar coisas diferentes. É fácil e privado. Você o que você realmente quer de um regime ramo sem a tentação de procrastinar ou frango de fundir a linha principal.

Suponho que seria teoricamente possível fazer algo semelhante no git, mas git torna praticamente qualquer coisa possível, em vez de afirmar um fluxo de trabalho que aprovam. O modelo centralizado é um monte de simplificações válidos em relação ao modelo distribuído que é uma generalização inválido. É tão demasiado global que basicamente espera que você implementar o controle de origem em cima dela, como repo faz.

A outra coisa é a replicação. Em git, tudo é possível então você tem que descobrir por si mesmo. Em forçosamente, você obtém um cache efetivamente apátridas. A única configuração que precisa de saber é onde o mestre é, e os clientes podem apontar para o mestre ou o cache em seu discoretion. Isso é um trabalho cinco minutos e não pode dar errado.

Você também tem gatilhos e formas personalizáveis ??para afirmar revisões de código, referências Bugzilla etc, e, claro, você tem ramificações para quando você realmente precisa deles. Não é ClearCase, mas é perto, e é absolutamente fácil de configurar e manter.

Em suma, eu acho que se você sabe que está indo para o trabalho de uma forma centralizada, o que todo mundo faz, assim como você pode usar uma ferramenta que foi projetado com isso em mente. Git é superestimada por causa de Linus' sagacidade temível juntamente com povos tendência a seguir uns aos outros ao redor como ovelhas, mas seus principais razão de ser na verdade não levantar-se para o senso comum, e seguindo-o, laços git suas próprias mãos com os dois grandes dogmas que (a) o software e (b) os dados têm de ser o mesmo em ambos cliente e servidor, e que será sempre torná-lo complicado e coxos no trabalho centralizado.

Usando GIT como substituto para o gerenciamento de linha de código ruim é comum. Muitas das desvantagens do Perforce são um resultado de estratégias de ramificação ruins. O mesmo para qualquer outra ferramenta centralizada. Se você tem que criar uma tonelada de ramos que você está fazendo algo errado. Por que os desenvolvedores precisam para criar tantos ramos?

Além disso, por que está funcionando desconectado de qualquer maneira tão importante? Só assim alguém pode trabalhar em um trem? Isso é sobre o único lugar nos dias de hoje você não pode obter uma conexão sem fio. E até mesmo a maioria dos trens têm WiFi decente.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow