Por que todo mundo usa o Git de maneira centralizada?

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.

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 .

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.

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 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.

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.

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 :

• Funcionalidades

• Comandos básicos

• Comandos avançados

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.

2. 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.

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.

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.

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.

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.

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.

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”.