Por que todos usam o Git de maneira centralizada?

Eu usei o Git nas minhas duas últimas empresas para controle de versão. Pelo que ouvi, parece que cerca de 90% das empresas usam o Git em 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 / fonte central de verdade. Essa foi uma característica que Linus Torvalds defendeu.

Mas parece que todas as empresas usavam o Git de maneira centralizada, assim como uma pessoa usaria SVN ou CVS. Sempre existe um repositório central em um servidor (geralmente no GitHub) para o qual as pessoas acessam e pressionam. Eu nunca vi ou ouvi falar (na minha experiência reconhecidamente limitada) de pessoas que usam o Git da maneira verdadeiramente descentralizada na qual ele foi planejado, ou seja, empurrando e puxando para outros repositórios de colegas como bem entenderem.

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 é ainda importante para o controle de versão moderno ou apenas soa legal?

Editar

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

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

Vamos comparar o antecessor do git no mindshare, svn. O Subversion tinha apenas um "repo", uma fonte de verdade. Quando você fez um commit, foi para um único repositório central, com o qual todos os outros desenvolvedores também estavam comprometidos.

Isso meio que funcionou, mas levou a vários problemas, o maior deles foi o temido conflito de mesclagem . Acabaram sendo irritantes para pesadelos e resolvidos. E com uma fonte de verdade, eles tinham o hábito desagradável de interromper o trabalho de todos até que fossem resolvidos. Conflitos de mesclagem certamente existem com o git, mas eles não são eventos de interrupção do 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, e não todos.

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

Por outro lado, como seu repositório git é um repositório de primeira classe por si só, quando você confirma, seus commits vão para o repositório local. Se você deseja compartilhá-los com outras pessoas ou com a fonte central da verdade, você deve fazer isso explicitamente pressionando um controle remoto. Outros desenvolvedores podem baixar essas alterações quando for conveniente para eles, em vez de verificar o svn constantemente para ver se alguém fez algo que irá estragar tudo.

O fato de que, em vez de enviar diretamente para outros desenvolvedores, você envia alterações indiretamente por meio de outro repositório remoto, não importa muito. A parte importante da nossa perspectiva é que sua cópia local do repositório é um repositório por si só. No svn, a fonte central da verdade é imposta pelo design do sistema. No git, o sistema nem sequer tem esse conceito; se existe uma fonte de verdade, ela é decidida externamente.

Quando o servidor de construção (você está usando o IC, certo?) Cria uma construção, de onde ele extrai? Certamente, uma construção de integração que você poderia argumentar não precisa de "um repo verdadeiro", mas certamente uma construção de distribuição (isto é, o que você oferece ao cliente).

Em outras palavras: fragmentação. Se você designar um repositório como "o repositório" e nomear guardiões que examinam solicitações pull, você tem uma maneira fácil de atender à solicitação de "me forneça uma compilação de software" ou "sou novo na equipe, onde está o código?"

A força do DVCS não é tanto o aspecto ponto a ponto, mas o fato de ser hierárquico . Modifico meu espaço de trabalho e depois me comprometo com o local. Depois que um recurso é concluído, mesclo meus commits e os empurro para o controle remoto. Qualquer pessoa pode ver meu código de tentativa, fornecer feedback etc. etc. antes de criar uma solicitação de recebimento e um administrador do projeto o mesclar no repo One True.

Com o CVCS tradicional, você compromete 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 por meio de um processo interno que permite uma melhor visibilidade do que está sendo verificado. O uso de uma maneira centralizada significa que você ainda pode tenha esse padrão-ouro do estado atual do projeto e, ao mesmo tempo, forneça um melhor mecanismo de compartilhamento de código.

Eu não sei como você define "todos", mas a minha equipa tem "um repositório central em um servidor" e também de vez em quando nós puxamos de repos de outros colegas, sem passar através desse 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 recurso específico e deseja manter-se atualizado, mas ainda não tem interesse em publicar o recurso para todos. Naturalmente, como não somos trabalhadores que trabalham em silos, essas situações não duram muito, mas o DVCS fornece a flexibilidade para fazer o que for mais conveniente. Podemos publicar um ramo de recurso ou não de acordo com o gosto.

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

"Distribuído" significa que todas as operações compromissadas são tecnicamente equivalentes no que diz respeito ao gitsoftware, mas não se segue que todas tenham igual significado no que diz respeito aos desenvolvedores e aos nossos fluxos de trabalho. Quando lançamos para clientes ou servidores de produção, o repositório que usamos para 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 isso é o que Linus significa campeão, uma vez que na verdade ele não manter repos especiais que são mais importante no grande esquema das coisas, do que é algum clone aleatório do Linux que eu fiz ontem e planejo usar apenas para desenvolver um pequeno patch e excluí-lo quando ele aceitar o patch. gitnão privilegia seu repo sobre o meu, mas Linus o privilegia. O dele "é o estado atual do Linux", o meu não. Então, naturalmente, as mudanças tendempara passar por Linus. A força do DVCS sobre o VCS centralizado não é que não deve haver um centro de fato, é que as mudanças não precisam passar por nenhum centro porque (conflitos permitem) qualquer um pode mesclar qualquer coisa.

Os sistemas DVCS também são forçados , por serem descentralizados, a fornecer certos recursos convenientes com base no fato de que você necessariamente deve ter um histórico completo (por exemplo, um repositório) localmente para fazer qualquer coisa. Mas se você pensar bem, não há razão fundamental para não configurar um VCS centralizado com um cache local que mantenha todo o histórico de operações somente leitura com validade desatualizada (acho que o Perforce tem uma opção para esse modo, mas nunca usei o Perforce). Ou, em princípio, você pode configurar gitcom o seu.git/diretório em um sistema de arquivos montado remotamente para emular o "recurso" do SVN que não funciona quando você não possui 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. Esse é 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 .

O interessante sobre a natureza do DVCS é que se outras pessoas o estiverem usando de maneira distribuída, você provavelmente não saberá, a menos que estejam 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, perguntarei a você, por que você não usa o git de maneira descentralizada?

Para lidar com 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, são difundidas. Essas são as coisas que minha equipe realmente faz no trabalho que não podíamos fazer quando tínhamos centralizado o VCS:

• Tenha uma lista muito pequena de desenvolvedores principais com acesso de confirmação ao repositório "central" de cada microsserviço. Todos os outros podem trabalhar com garfos e enviar por meio de solicitações pull.
• Pode comprometer-se com muito mais frequência, geralmente várias vezes por hora versus uma ou duas vezes por dia.
• Pode criar ramificações, por qualquer motivo, para coordenar temporariamente com os colegas de trabalho, pressioná-lo e retirá-lo várias vezes por dia, depois esmagá-lo quando estiver pronto para compartilhar com um grupo maior. Você tem alguma idéia de quão difícil é obter permissão para criar uma ramificação temporária para algo assim em um CVCS tradicional?

Correndo o risco de parecer 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 . ou seja, o servidor ci 'verdade' central está 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. Todo o código (estamos falando de uma base de código de US $ 1 bilhão) tinha que (por lei / acordo internacional, homens de terno escuro aparecerem, se não o fizer) estar em máquinas fisicamente isoladas de qualquer conexão à Internet . Isso significava que a situação usual de cada um de nós tinha dois PCs, um para escrever / executar / testar o código, o outro para o Google, verificar e-mails e outros. E havia uma rede local dentro da equipe dessas máquinas, obviamente 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 de blocos de concreto (edifício 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 várias centenas de quilômetros de distância, então, você pode imaginar.

Além disso, em sistemas muito grandes, onde você tem muitas equipes. Geralmente, cada um deles tem seu próprio repositório "central", que depois volta ao repositório central "central" real (nível de deus). Conheço pelo menos mais um contratado que fez o mesmo traço de repositório git de disco rígido com o código deles também.

Além disso, se você considerar algo na escala do kernel Linux ... Os desenvolvedores não apenas enviam uma solicitação de recebimento ao próprio Linus. É essencialmente uma hierarquia de repositórios - cada um dos quais foi / é "central" para alguém / alguma equipe.

A natureza desconectado de git significa que ele pode ser usado em ambientes onde conectado modelo ferramentas de controlo de origem ( isto é, SVN, para um) não poderia ser usado - ou não pode ser utilizado com a mesma facilidade.

Por fim, você está construindo um produto. Este produto representa seu código em um único momento. Dado isso, seu código deve se unir em algum lugar . O ponto natural é um servidor ci ou servidor central a partir do qual o produto é construído, e faz sentido que esse 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 em que contribuo foram abandonados pelo autor original e agora têm um monte de garfos onde os mantenedores às vezes selecionam recursos específicos um do outro. Mesmo em geral, os projetos de OSS recebem contribuições externas por meio de solicitação pull, em vez de conceder a pessoas aleatórias o acesso ao repositório de informações verdadeiras.

Este não é um caso de uso muito comum ao criar um produto concreto com um release oficial específico, mas no mundo do F / OSS é a norma, não a exceção.

Por que todos usam o git de maneira centralizada?

Nós nunca nos conhecemos, como é que você diz todo mundo? ;)

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

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

Na minha opinião, este é outro recurso que não deve ser esquecido.

Enquanto você não é capaz de fazer isso com o CVS e o SVN prontos para uso, o Git pode ser usado centralizado como os anteriores sem problemas.

Portanto, sou capaz de confirmar minhas alterações, talvez apertar as confirmações do trabalho em andamento e buscar e refazer o meu trabalho no ramo de desenvolvimento principal.

Outros recursos que saem da caixa com o Git:

• assinar criptograficamente confirma
• rebasing (reordenar e squash confirma; editar confirma, não apenas a mensagem)
• apanhar cerejas
• dividindo a história
• filiais locais e mudanças ocultas (chamadas "prateleiras" na Wikipedia)

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

• Recursos

• Comandos básicos

• Comandos avançados

Então, novamente, talvez a maneira descentralizada não seja o único recurso que faz as pessoas usá-la.

1. Por que as pessoas não usam um fluxo de trabalho distribuído para o Git na prática?

Qualquer pessoa que contribua ou hospede um projeto maior no Bitbucked, GitHub etc. fará exatamente isso. Os mantenedores mantêm o repositório "principal", um contribuidor clona, ​​confirma e envia uma solicitação de recebimento.

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 desejam que os externos modifiquem o (s) ramo (s) de desenvolvimento sagrado sem que suas alterações sejam revisadas antes.

2. A capacidade de trabalhar de maneira distribuída é importante para o controle de versão moderno, ...

Como sempre: depende dos requisitos.

Use um VCS descentralizado se algum ponto se aplicar:

• deseja confirmar ou navegar offline pelo histórico (por exemplo, terminar o submódulo na cabana na montanha durante as férias)
• forneça repositórios centrais, mas deseja manter "o verdadeiro" repositório separado para revisar as alterações (por exemplo, para grandes projetos ou equipes distribuídas)
• deseja fornecer (uma cópia) toda a história e ramificações ocasionalmente, impedindo o acesso direto ao repositório central (semelhante ao segundo)
• deseja fazer a versão de algo sem ter que armazenar remotamente ou configurar um repositório dedicado (especialmente no Git, um mero elemento git init .seria suficiente para estar pronto para a versão de algo)

Existem mais alguns, mas quatro devem ser suficientes.

... ou soa legal?

Claro que parece bom - para iniciantes.

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

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

Seu cliente git, no entanto, quase certamente usa como padrão o modelo "ancestral único". E gráficos nos quais os nós têm um único ancestral (exceto um nó raiz) são exatamente árvores. Portanto, seu próprio cliente git assume como padrão o modelo de árvore e, portanto, 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 executar o DVCS, não significa que seu fluxo de trabalho principal tenha que ser DVCS. Quando uso o git no trabalho, usamos de maneira centralizada, exceto nos casos estranhos em que o bit distribuído era essencial para manter as coisas em movimento.

O lado distribuído das coisas é complicado. Normalmente, você deseja 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 complicadas que podem surgir no caminho.

Para um colega de trabalho extrair de um repositório git na minha máquina, eu preciso ter um daemon git executando no nível raiz como uma tarefa em segundo plano. Estou muito desconfiado de daemons rodando no meu próprio computador ou no laptop fornecido pela empresa. A solução mais fácil é "NÃO"! Para um colega de trabalho retirar de um repositório Git na minha máquina também significa que meu endereço de Internet precisa ser corrigido. 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 filial ao 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 repositório git local é um repositório completo. Posso comprometer um novo trabalho, criar uma nova ramificação para o trabalho experimental e reverter o trabalho quando faço uma bagunça, mesmo quando estou 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 com relação ao número de desenvolvedores em O (1).

Se, em vez disso, cada desenvolvedor tiver sua própria ramificação principal, ele se tornará, 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 ponto a ponto é O (N).

Consistência:

Agora considere se existe um conflito de mesclagem entre o ramo mestre de Alice e o ramo mestre de Bob. Cada um dos N desenvolvedores poderia resolver o conflito de maneira diferente. Resultado: caos. Existem maneiras de obter consistência eventual, mas até que isso aconteça, todo tipo de tempo do desenvolvedor pode ser desperdiçado.

Simples:

As 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. O CTO é a melhor fonte de verdade técnica. Qualquer que seja a ferramenta utilizada pela empresa, ela deve refletir essa cadeia de comando. Uma empresa é como um exército - você não pode deixar que os particulares votem em um general.

O GIT oferece recursos que são úteis para as empresas (por exemplo, solicitações pull para revisão de código) e que, por si só, as fazem mudar para o GIT. A parte descentralizada é simplesmente um recurso que eles não precisam - então eles o ignoram.

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

Talvez seja porque o processamento da folha de pagamento é centralizado, por isso precisamos manter uma pessoa central feliz se quisermos receber o pagamento.

Talvez seja porque estamos criando um produto, por isso precisamos de uma cópia principal 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 ter que se conectar a muitas máquinas diferentes.

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

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

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á inoperante é excelente, mas não precisa de um sistema distribuído; ele 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 distribuição e alguns benefícios. A maior parte do custo de distribuição está na área necessária, se você deseja um ótimo rastreamento de filiais, etc. é claramente o principal "caso de uso".