Por que todo mundo usa o Git de maneira centralizada?

282

Eu usei o Git em minhas duas últimas empresas para controle de versão. Parece que pelo que ouvi dizer, cerca de 90% das empresas usam o Git em vez de outros sistemas de controle de versão.

Um dos maiores pontos de venda do Git é que ele é descentralizado, ou seja, todos os repositórios são iguais; não há repositório central / fonte de verdade. Este foi um recurso Linus Torvalds defendido.

Mas parece que todas as empresas usaram o Git de maneira centralizada, muito parecido com o SVN ou o CVS. Há sempre um repositório central em um servidor (geralmente no GitHub) que as pessoas puxam e empurram para. Eu nunca vi ou ouvi falar (em minha experiência reconhecidamente limitada) de pessoas usando o Git da maneira verdadeiramente descentralizada em que ele foi planejado, ou seja, empurrando e puxando para outros repositórios colegas como bem entendessem.

Minhas perguntas são:

  1. Por que as pessoas não usam um fluxo de trabalho distribuído para o Git na prática?
  2. A capacidade de trabalhar de maneira distribuída é importante para o controle de versões modernas, ou soa legal?

Editar

Percebi que não encontrei o tom correto na minha pergunta original. Parecia que eu estava perguntando por que alguém trabalharia de maneira centralizada quando um sistema de controle de versão distribuído (DVCS) era tão obviamente superior. Na verdade, o que eu quis dizer foi, eu não vejo nenhum benefício para DVCS em todos os . No entanto, muitas vezes ouço pessoas pregando sua superioridade, enquanto o mundo real parece concordar com o meu ponto de vista.

    
por gardenhead 09.04.2016 / 17:40
fonte

14 respostas

252

Ahh, mas na verdade você está usando o git de maneira descentralizada!

Vamos comparar o predecessor do git em mindshare, svn. Subversion tinha apenas um "repo", uma fonte de verdade. Quando você fez um commit, foi para um único repo central, que todos os outros desenvolvedores também estavam comprometendo.

Esse tipo de coisa funcionou, mas levou a vários problemas, sendo o maior deles o conflito de mesclagem temido . Estes acabaram por ser em qualquer lugar de irritante para pesadelo para resolver. E com uma fonte de verdade, eles tinham o péssimo hábito de levar o trabalho de todos a um ponto insuportável até que fossem resolvidos. Conflitos de mesclagem certamente existem com o git, mas eles não são eventos de parada de trabalho e são muito mais fáceis e rápidos de resolver; eles geralmente afetam apenas os desenvolvedores envolvidos com as mudanças conflitantes, em vez de todos.

Depois, há todo o ponto único de falha e os problemas de atendimento que isso traz. Se o seu repositório svn central morre de alguma forma, você está todo estragado até que ele possa ser restaurado a partir do backup, e se não houver backups, você estará duplamente ferrado. Mas se o repositório git "central" morrer, você pode restaurar a partir do backup, ou até mesmo de uma das outras cópias do repositório que estão no servidor de CI, estações de trabalho dos desenvolvedores etc. Você pode fazer isso precisamente porque elas são distribuídas. e cada desenvolvedor tem uma cópia de primeira classe do repositório.

Por outro lado, como o seu git repo é um repo de primeira classe, quando você comete, seus commits vão para o repositório local. Se você quiser compartilhá-los com outras pessoas ou com a fonte central da verdade, você deve explicitamente fazer isso com um push para um controle remoto. Outros desenvolvedores podem baixar essas mudanças quando for conveniente para elas, em vez de ter que verificar o svn constantemente para ver se alguém fez algo que vai estragar tudo.

O fato de que, ao invés de empurrar diretamente para outros desenvolvedores, você envia mudanças para eles indiretamente através de outro repositório remoto, não importa muito. A parte importante da nossa perspectiva é que a sua cópia local do repositório é uma recompra por direito próprio. Em svn, a fonte central da verdade é reforçada pelo design do sistema. No git, o sistema nem tem esse conceito; se existe uma fonte de verdade, isso é decidido externamente.

    
por 10.04.2016 / 01:24
fonte
119

Quando o seu servidor de compilação (você está usando o CI, certo?) cria uma compilação, de onde ele é extraído? Claro, uma compilação de integração que você poderia argumentar não precisa de "um repositório verdadeiro", mas certamente uma compilação de distribuição (ou seja, o que você dá ao cliente) faz.

Em outras palavras: fragmentação. Se você designar um repositório como "o" repositório e nomear guardiões que examinam solicitações de solicitação, você terá uma maneira fácil de atender à solicitação de "me fornecer uma versão de software" ou "Sou novo no time, onde está o código?"

A força do DVCS não é tanto o aspecto peer-to-peer dele, mas o fato de ser hierárquico . Eu modifico meu espaço de trabalho, depois me comprometo com o local. Quando eu tiver um recurso completo, mescle meus commits e os envie para o meu controle remoto. Então, qualquer um pode ver meu código provisório, fornecer feedback, etc. antes de eu criar uma solicitação pull e um administrador do projeto a mescla no repositório One True.

Com o CVCS tradicional, você quer se comprometer ou não. Isso é bom para alguns fluxos de trabalho (eu uso os dois tipos de VCS para projetos diferentes), mas cai de cara para um projeto público ou OSS. A chave é que o DVCS tem várias etapas, que são mais trabalhosas, mas fornecem uma maneira melhor de integrar código de estranhos através de um processo integrado que permite uma melhor visibilidade do que está sendo verificado. Usá-lo de maneira centralizada significa que você ainda pode tem esse padrão ouro do estado atual do projeto, ao mesmo tempo em que fornece um mecanismo de compartilhamento de código melhor.

    
por 09.04.2016 / 18:17
fonte
39

Eu não sei como você define "todos", mas minha equipe tem "um repositório central em um servidor" e também ocasionalmente retiramos dos repositórios de outros colegas sem passar por esse repo central. Quando fazemos isso, ainda passamos por um servidor, porque optamos por não enviar correções por e-mail sobre o local, mas não pelo repositório central. Isso geralmente acontece quando um grupo está colaborando em um determinado recurso e quer se manter atualizado, mas ainda não tem interesse em publicar o recurso para todos. Naturalmente, como não somos senhores-trabalhadores secretos, essas situações não duram muito, mas o DVCS oferece a flexibilidade de fazer o que for mais conveniente. Podemos publicar um ramo de recursos ou não de acordo com o gosto.

Mas mais de 90% do tempo, com certeza, passamos pelo repo central. Quando não me preocupo com nenhuma mudança em particular ou com o trabalho de um colega em particular, é mais conveniente e melhor, para extrair "todas as alterações dos meus colegas que foram verificadas no repositório central", em vez de puxar separadamente as alterações de cada N colegas. O DVCS não está tentando impedir que o "pull from main repo" seja o fluxo de trabalho mais comum, ele está tentando evitar que seja o único fluxo de trabalho disponível.

"Distribuído" significa que todos os repositórios são tecnicamente equivalentes no que diz respeito ao software git , mas isso não significa que todos tenham a mesma importância no que se refere aos desenvolvedores e fluxos de trabalho. Quando lançamos para clientes ou para servidores de produção, o repo que usamos para fazer isso tem um significado diferente de um repositório usado apenas por um desenvolvedor em seu laptop.

Se "verdadeiramente descentralizado" significa "não há repos especiais", então eu não acho que seja isso o que Linus quer dizer, já que de fato ele faz mantém acordos especiais que > são mais importantes no grande esquema das coisas, do que um clone aleatório do Linux que eu fiz ontem e planejo usar apenas para desenvolver um pequeno patch e depois deletá-lo assim que ele aceitar o patch. git não privilegia o seu repo sobre o meu, mas o Linus faz privilegiá-lo. Seu "é o estado atual do Linux", o meu não é. Então, naturalmente, as mudanças tendem a passar por Linus. A força do DVCS sobre o VCS centralizado não é que não deva haver um centro de fato, é que as mudanças não precisam passar por nenhum centro porque (se houver conflitos) qualquer um pode mesclar qualquer coisa.

Sistemas DVCS também são forçados , porque eles são descentralizados, para fornecer certos recursos convenientes baseados no fato de que você necessariamente deve ter um histórico completo (ou seja, um repo) localmente para fazer qualquer coisa. Mas se você pensar nisso, não há razão fundamental para que você não possa configurar um VCS centralizado com um cache local que mantenha todo o histórico de operações somente leitura com a permissão desatualizada (acho que o Perforce tem uma opção para esse modo, mas eu nunca usei o Perforce). Ou, em princípio, você poderia configurar git com seu diretório .git/ em um sistema de arquivos montado remotamente para emular o "recurso" do SVN que ele não funciona quando você não tem uma conexão de rede. Com efeito, o DVCS força o encanamento a ser mais robusto do que você pode obter em um VCS centralizado. Este é um efeito colateral (muito bem-vindo) e ajudou a motivar o design do DVCS, mas essa distribuição de responsabilidade no nível técnico não é o mesmo que descentralizar totalmente toda a responsabilidade humana .

    
por 10.04.2016 / 01:57
fonte
27
O interessante sobre a natureza do DVCS é que, se outras pessoas o estiverem usando de maneira distribuída, você provavelmente não saberia a menos que ele esteja interagindo diretamente com você. A única coisa que você pode dizer definitivamente é que você e seus colegas de equipe diretos não usam o git dessa maneira. Isso não requer uma política para toda a empresa. Então, vou perguntar a você, por que você não usa o git de maneira descentralizada?

Para abordar sua edição, talvez você precise de alguma experiência trabalhando com um controle de versão centralizado real para apreciar as diferenças, porque embora possam parecer sutis, elas são difundidas. Estas são todas as coisas que minha equipe faz no trabalho e que não pudemos fazer quando tivemos o VCS centralizado:

  • Tenha uma lista muito pequena de desenvolvedores principais com acesso de commit ao repositório "central" para cada microsserviço. Todos os outros podem trabalhar com garfos e enviá-los por meio de solicitações pull.
  • É possível comprometer muito com mais frequência, geralmente várias vezes por hora, em vez de uma ou duas vezes por dia.
  • É possível criar ramificações por qualquer motivo para coordenar temporariamente com colegas de trabalho, empurrá-las e puxá-las várias vezes por dia e, em seguida, comprimi-las quando estiver pronto para compartilhar com um grupo maior. Você tem alguma idéia de como é difícil obter permissão para criar um ramo temporário para algo assim em um CVCS tradicional?

Correndo o risco de soar velho por dizer isso, você realmente não sabe como é fácil.

    
por 09.04.2016 / 23:40
fonte
19

Eu acho que sua pergunta vem de uma mentalidade (compreensível) sempre conectada . i.e. O servidor central 'verdade' ci é sempre (ou quase sempre) disponível. Embora isso seja verdade na maioria dos ambientes, trabalhei em pelo menos um que estava longe disso.

Um projeto de Simulação Militar em que minha equipe trabalhou vários anos atrás. Todos o código (estamos falando de uma base de código de > US $ 1 bilhão) tiveram que (por lei / acordo internacional, os homens de terno escuro vêm se você não o fizer) estar em máquinas fisicamente isoladas de qualquer conexão com a Internet . Isso significava que a situação normal de cada um de nós era de 2 PCs, um para escrever / executar / testar o código, o outro para as coisas do Google, verificar e-mail e coisas do tipo. E havia uma rede local dentro da equipe dessas máquinas, obviamente, não de forma alguma conectada à Internet.

A "fonte central da verdade" era uma máquina em uma base do exército, em uma sala sem janelas subterrânea, toda de concreto (prédio reforçado, yada-yada). Essa máquina também não tinha conexão com a Internet.

Periodicamente, seria o trabalho de alguém transportar (fisicamente) uma unidade com o repositório git (contendo todas as nossas alterações de código) para a base do exército - que ficava a centenas de quilômetros de distância, então, você pode imaginar.

Além disso, em muito sistemas grandes onde você tem lotes de equipes. Em geral, cada um deles tem seu próprio repositório "central", que então retorna ao repo central "central" real (nível divino). Eu conheço pelo menos um outro contratado que fez o mesmo disco rígido com seu código também.

Além disso, se você considerar algo na escala do kernel do Linux ... Desenvolvedores não apenas enviam um pedido de pull para o próprio Linus. É essencialmente uma hierarquia de recompra - cada uma das quais era / é "central" para alguém / alguma equipe.

A natureza desconectada do git significa que ele pode ser usado em ambientes onde as ferramentas de controle de fonte do modelo conectado ( ie SVN, por exemplo) não puderam ser usadas - ou não poderia ser usado tão facilmente.

    
por 10.04.2016 / 21:04
fonte
18

Por fim, você está criando um produto. Este produto representa seu código em um único ponto no tempo. Dado isso, seu código deve se aglutinar em algum lugar . O ponto natural é um servidor ci ou servidor central a partir do qual o produto é construído, e faz sentido que este ponto central seja um repositório git.

    
por 10.04.2016 / 00:20
fonte
14

O aspecto distribuído de um DVCS aparece no desenvolvimento de código aberto o tempo todo, na forma de bifurcação. Por exemplo, alguns dos projetos para os quais contribuí foram abandonados pelo autor original e agora têm um monte de garfos onde os mantenedores às vezes puxam recursos específicos uns dos outros. Mesmo em geral, os projetos de OSS recebem contribuições externas por meio de solicitação pull, em vez de conceder acesso aleatório às pessoas para o repositório de verdade.

Este não é um caso de uso muito comum quando se constrói um produto concreto com um lançamento oficial específico, mas no mundo F / OSS é a norma, não a exceção.

    
por 10.04.2016 / 05:04
fonte
9

Why does everyone use git in a centralized manner?

Nós nunca nos encontramos, como é que você diz a todos? ;)

Em segundo lugar, há mais outros recursos que você encontra no Git, mas não no CVS ou no SVN. Talvez seja só você assumindo que esse deve ser o único recurso para todos .

Certamente, muitas pessoas podem usá-lo centralizado como o CVS ou o SVN. Mas não se esqueça do outro recurso que inerentemente vem com um VCS distribuído: todas as cópias são mais ou menos "completas" (todas as ramificações e o histórico completo está disponível) e todas as ramificações podem ser verificadas sem se conectar a um servidor. p>

Na minha opinião, esta é outra característica que não deve ser esquecida.

Embora você não consiga fazer isso com o CVS e o SVN fora da caixa, o Git pode ser usado de forma centralizada, como os anteriores, sem problemas.

Assim, posso confirmar minhas alterações, talvez acabar com as confirmações de trabalho em andamento, e depois buscar e refazer meu trabalho no ramo principal de desenvolvimento.

Outras funcionalidades que saem da caixa com o Git:

  • assinam criptograficamente
  • rebasing (reordenar e squash commits; editar commits, não apenas a mensagem)
  • escolha de cereja
  • dividindo a história
  • ramificações locais e alterações de stashing (chamadas de "shelving" na Wikipedia)

Veja também estas três tabelas em Wikipedia - Comparação do software de controle de versão :

Então, novamente, talvez a maneira descentralizada não seja aquele recurso que faz com que as pessoas o usem.

  1. Why don't people use a distributed workflow for Git in practice?

Qualquer pessoa contribuindo ou hospedando um projeto maior no Bitbucked, no GitHub, etc., fará exatamente isso. Os mantenedores mantêm o repositório "principal", um colaborador clona, confirma e envia um pedido pull.

Nas empresas, mesmo com pequenos projetos ou equipes, um fluxo de trabalho distribuído é uma opção quando eles terceirizam módulos e não querem que externos modifiquem o (s) ramo (s) sagrado (s) de desenvolvimento sem ter suas alterações revisadas antes.

  1. Is the ability work in a distributed manner even important to modern version control, ...

Como sempre: depende dos requisitos.

Use um VCS descentralizado se algum ponto se aplicar:

  • deseja confirmar ou navegar no histórico off-line (ou seja, terminar o submódulo na cabana na montanha durante as férias)
  • fornecer repositórios centrais, mas deseja manter o repositório "true" separado para revisar as alterações (por exemplo, para grandes projetos ou equipes distribuídas)
  • deseja fornecer (uma cópia de) todo o histórico e filiais ocasionalmente, evitando o acesso direto ao repositório central (semelhante ao segundo)
  • quer algo de versão sem ter que armazenar isso remotamente ou configurar um repositório dedicado (especialmente com o Git apenas git init . que seria o suficiente para estar pronto para algo de versão)

Existem mais alguns, mas quatro devem ser suficientes.

... or does it just sound nice?

Claro que parece bom - para iniciantes.

    
por 10.04.2016 / 15:35
fonte
5

A flexibilidade é uma maldição e também uma bênção. E como o Git é extremamente flexível, é quase sempre longe muito flexível para a situação típica. Especificamente, a maioria dos projetos do Git não são Linux.

Como resultado, a escolha inteligente é remover parte dessa flexibilidade teórica ao implementar o Git. Em teoria, repositórios podem formar qualquer gráfico, na prática, a escolha usual é uma árvore. Podemos ver os claros benefícios usando a teoria dos grafos: em uma árvore de repositórios, quaisquer dois repositórios compartilham exatamente um ancestral. Em um gráfico aleatório, a ideia de um ancestral nem existe!

Seu git client, no entanto, quase certamente, assume como padrão o modelo "ancestral único". E os gráficos nos quais os nós têm um único ancestral (com exceção de um nó raiz) são exatamente árvores. Portanto, o próprio cliente git é padronizado para o modelo de árvore e, portanto, para os repositórios centralizados.

    
por 11.04.2016 / 11:12
fonte
4

A lógica de negócios recompensa um servidor centralizado. Para quase todos os cenários de negócios realistas, um servidor centralizado é um recurso fundamental do fluxo de trabalho.

Só porque você tem a capacidade de fazer DVCS não significa que seu fluxo de trabalho principal tenha que ser DVCS. Quando eu uso o git no trabalho, nós o usamos de forma centralizada, exceto por aqueles estranhos casos estranhos em que o bit distribuído era essencial para manter as coisas andando.

O lado distribuído das coisas é complicado. Normalmente você quer manter as coisas fáceis e fáceis. No entanto, usando o git você garante que você tenha acesso ao lado distribuído para lidar com as situações difíceis que podem surgir no caminho.

    
por 12.04.2016 / 05:21
fonte
3

Para um colega de trabalho pegar um repositório do git na minha máquina, eu preciso ter um daemon git sendo executado no nível da raiz como uma tarefa em segundo plano. Eu sou muito desconfiado de daemons em execução no meu próprio computador, ou no meu laptop fornecido pela empresa. A solução mais fácil é "NÃO"! Para um colega de trabalho puxar de um repositório git na minha máquina, significa que meu endereço de internet precisa ser corrigido. Eu viajo, trabalho em casa e ocasionalmente trabalho no meu escritório.

Por outro lado, a VPN para o site corporativo e o envio de uma ramificação para o repositório central leva menos de um minuto. Eu nem preciso fazer VPN se estiver no escritório. Meus colegas de trabalho podem facilmente sair desse ramo.

Por outro lado, meu git repo local é um repositório completo. Eu posso comprometer o novo trabalho, criar um novo ramo para o trabalho experimental e reverter o trabalho quando fizer uma confusão, mesmo quando estiver trabalhando em um avião voando a 30.000 pés no meio do nada. Tente fazer isso com um sistema de controle de versão centralizado.

    
por 11.04.2016 / 17:38
fonte
2

Complexidade:

Com um repositório central, um fluxo de trabalho típico pode ser

branch off from the central master branch
change the code
test
possibly go back to changing the code
commit
merge any new changes from the central master branch
test
possibly go back to changing the code
merge changes into the central master branch and push

A complexidade em relação ao número de desenvolvedores em O (1).

Se, em vez disso, cada desenvolvedor tiver sua própria ramificação mestre, será para o desenvolvedor 0:

branch off from master branch 0
merge from master branch 1
...
merge from master branch N-1
change the code
test
possibly go back to changing the code
commit
merge any changes from master branch 0
merge any changes from master branch 1
...
merge any changes from master branch N-1
test
possibly go back to changing the code
merge changes into master branch 0

A abordagem peer-to-peer é O (N).

Consistência:

Agora considere se existe um conflito de mesclagem entre o branch master de Alice e o branch master de Bob. Cada um dos desenvolvedores de N poderia resolver o conflito de maneira diferente. Resultado: caos. Existem maneiras de alcançar consistência eventual, mas até que isso aconteça, todos os tipos de tempo de desenvolvedor podem ser desperdiçados.

    
por 13.04.2016 / 19:17
fonte
1

Simples:

Empresas são organizações centralizadas, com fluxo de trabalho centralizado.

Todo programador tem um chefe e ele tem seu chefe, etc. até o CTO. CTO é a melhor fonte de verdade técnica. Seja qual for a ferramenta usada pela empresa, ela deve refletir essa cadeia de comando. Uma empresa é como um exército - você não pode deixar os soldados escaparem de um general.

O GIT oferece recursos que são úteis para as empresas (por exemplo, pedidos de pull para revisão de código) e que por si só os fazem mudar para o GIT. A parte descentralizada é simplesmente uma característica que eles não precisam - então eles a ignoram.

Para responder à sua pergunta: A parte distribuída é realmente superior em ambiente distribuído, por exemplo, código aberto. Os resultados variam dependendo de quem está falando. Linus Torvalds não é exatamente o seu rato cubículo, é por isso que os diferentes recursos do GIT são importantes para ele do que para sua empresa centrada no github.

    
por 14.04.2016 / 16:56
fonte
-2

Talvez seja porque o processamento da folha de pagamento é centralizado, então temos que manter uma pessoa central feliz se quisermos receber o pagamento.

Talvez seja porque estamos criando um produto, por isso precisamos de uma cópia mestra do software para os clientes.

Talvez seja porque é muito mais fácil para um programador ir a um lugar para obter as alterações de todos, em vez de precisar se conectar a várias máquinas diferentes.

Talvez seja porque o banco de dados de bugs está centralizado, e deve ser mantido em sincronia com o código .

Ser centralizado é ótimo, até que haja um problema ...

O Git sendo um sistema distribuído permite que um novo centro seja criado a baixo custo a partir de qualquer repositório atualizado (apenas exponha o repositório à rede). O Git também permite que um backup desatualizado seja atualizado a partir dos repositórios nas máquinas do desenvolvedor, facilitando a recuperação do centro.

Ser capaz de mesclar etc em uma cópia local de um repositório quando a rede está inativa é ótimo, mas não precisa de um sistema distribuído; só precisa de um sistema que mantenha uma cópia local de todos os dados. Da mesma forma com o check-in do código com o vôo, etc.

No final do dia, há pouco custo para ser distribuído e alguns benefícios. A maior parte do custo de ser distribuído está na área necessária se você quiser um ótimo rastreamento de ramificações etc. Se você fosse projetar um sistema para uso na maioria das empresas, você não o projetaria para ser distribuído, como controle centralizado do código-fonte. é claramente o principal “caso de uso”.

    
por 12.04.2016 / 11:03
fonte