Por que todos usam o Git de maneira centralizada?


289

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.


31
Eu me sinto exatamente da mesma maneira, e não entendo isso.
Snoop

57
Pessoalmente, não conheço nenhum caso de uso para vários controles remotos, além de garfos para criar PRs no controle remoto principal. A coisa distribuída ainda é útil porque significa que eu tenho um histórico completo na minha máquina sem precisar conversar com a rede e posso trabalhar offline se realmente quiser, e é muito mais fácil migrar de um host de repositório online para outro. O que exatamente você tem em mente quando se refere a um "fluxo de trabalho distribuído"?
Ixrec 09/04

43
Estou bastante certo de que os Torvalds pretendem, desde o início, ter um repositório do Kernel Linux "fonte de verdade".
Steven Burnap 9/16

67
Por fim, o próprio software é centralizado. Os clientes não compram filiais ou controles remotos, eles compram um produto final, montado e construído. Sempre precisa haver algum caminho central a seguir.
9136 Brandon

37
Para mim, a "descentralização" do git é uma das características menos importantes que a recomendam. A capacidade de realizar confirmações e reversões frequentes localmente, sem afetar ninguém, ou técnicas poderosas como rebasing, é onde o git realmente brilha no meu fluxo de trabalho. É possível (de fato provável) que tudo isso seja possível descentralizado, mas o "D" no DVCS não é tão importante por si só.
Jay

Respostas:


257

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.


15
As mesclagens SVN também afetam apenas os desenvolvedores envolvidos com alterações conflitantes. Um commit entra no repositório, nenhuma mesclagem conflitante pode entrar no repositório até que os conflitos sejam resolvidos (você também pode confirmar em paralelo com um ramo / caminho separado, mas que atualmente não entra em conflito agora?)
Ben Voigt

30
Acho que a principal diferença, quando existe um servidor central, é que o GIT permite versões locais contínuas enquanto a rede está inativa e o SVN não (alguns outros sistemas de controle de versão são ainda piores e interrompe todo o trabalho quando a rede está inacessível , porque eles não permitem alterar um arquivo até você fazer o check-out).
Ben Voigt

17
@BenVoigt Oh, é trabalho parar bem. Lembre-se de que você deve svn upestar em dia com o repo antes de poder fazer o check-in. Quando outras pessoas continuarem o check-in enquanto você estiver tentando resolver conflitos de mesclagem e fornecer outro conjunto de conflitos de mesclagem ... você interrompa isso ou você perde o que resta de sua sanidade.
Michael Hampton

21
Não, as pessoas podem continuar se comprometendo com o ramo do qual você está mesclando as alterações, sem interromper o fluxo de trabalho.
Ben Voigt

29
Ben está certo. Um repositório SVN gerenciado corretamente e usado por uma equipe que foi devidamente instruída em como desenvolver software, nunca deve efetivamente ter conflitos de mesclagem no tronco. Você só as pegará quando alguém fizer algo errado e precisar ser demitido (: P). inb4 é mais fácil quando você não precisa educar as pessoas a usar suas ferramentas. Sim, bem, há muito mais para ensinar sobre o Git do que sobre o SVN!
Lightness Races in Orbit

118

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.


2
Boa resposta geral, mas tenho certeza de que o Git estava em uso generalizado antes da Integração Contínua; nossa equipe usa CI, a propósito, obrigado por verificar: D.
gardenhead

5
@ Gardenhead: você não entendeu: o mesmo argumento vale se a integração for criada manualmente. "CI" é apenas uma automatização para um processo muito mais antigo que o Git.
Doc Brown

25
"qualquer um pode ver meu código de tentativa" - e eles também podem extrair seu código de tentativa, fundi-lo com o código de tentativa e executar os testes. Isso é um problema nos VCS centralizados, pois requer ramificações e alterações na One True Copy. Distribuído, basta configurar controles remotos extras e começar a mesclar, aplicar patches e escolher cereja. Você acompanha o que fez, mas ninguém mais tem que ver quais travessuras você está fazendo, a menos que opte por publicá-las. Em geral, eu recomendo ninguém deve declarar DVCS inútil até que tenha realmente usado SVN para um grande projeto ...
Steve Jessop

9
Porque não existe "uma compilação verdadeira" do kernel do linux. Como todo mundo constrói por conta própria, o repo de Linus não é mais canônico que o de qualquer outra pessoa. Se você está vendendo um produto que não funciona tão bem.
Miles Budnek

2
@Superbest: muito (se não todo) o design do git foi baseado no Bitkeeper. O Git foi criado depois que a controvérsia do linux-bitkeeper implodiu.
Whatsisname

40

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 .


7
Eles são tecnicamente equivalentes, não socialmente equivalentes.
precisa saber é o seguinte

3
Enviar correções por e-mail é relativamente simples, caso alguém esteja considerando isso, basta usar o git format-patch e depois o git send-email . Fiz isso quando não quis mexer nos controles de acesso do Github e foi muito direto, todo mundo tem e-mail depois de tudo.
Rudolf Olah

1
"necessariamente deve ter um histórico completo [...] localmente para fazer qualquer coisa" - não é verdade; DSCMs modernos suportam repos parcial ("checkouts rasos" em termos bzr, "clones rasos" em termos git).
Charles Duffy

27

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.


1
A questão de como é difícil criar uma ramificação em um CVCS tradicional é totalmente política: eu trabalho com um repositório SVN upstream (naturalmente por meio de um clone git-svn!) E tenho todo o direito de criar ramificações que eu quer, mesmo que seja um projeto bastante grande. Não tenho permissão para tocar em vários ramos de integração designados, muito menos no tronco, sem falar primeiro com meus superiores. Outras empresas podem ter outras políticas que podem ser mais restritivas, mas certamente não precisam.
cmaster

7
Você está certo, não sei como é fácil. Eu gostaria de estar presente nos dias de domínio do SVN para apreciar até onde chegamos. Como um desenvolvedor de software muito jovem, encontro esse mesmo padrão repetindo com frequência: os desenvolvedores mais experientes me dizem que a maneira antiga de fazer algo era ruim e essa nova maneira / tecnologia é muito mais fácil. Mas eu apenas tenho que acreditar na palavra deles; Eu nunca posso realmente apreciar as vantagens. Eu sempre achei essa dissonância difícil de superar.
precisa saber é o seguinte

1
@gardenhead, você sempre pode criar seu próprio repositório SVN e tentar quebrá-lo;) (e perceber o quanto é mais difícil do que criar um repositório git e cloná-lo ...) - Outro recurso importante que eu notei (pelo menos em ambientes corporativos, especialmente) é que o compartilhamento de arquivos é um pouco estranho ou é feito de tal maneira que envolve repositórios (porque o antivírus trava em uma unidade de rede, por exemplo).
Wayne Werner

4
@ Gardenhead: bem, considere-se com sorte por não estar preso a um projeto legado, com desenvolvedores de software antigos que estão dizendo a você que a maneira antiga de fazer as coisas está bem ... às vezes você não pode ajudar, mas sente que elas estão apenas feliz que eles não precisam aprender novas tecnologias!
usar o seguinte código

1
Aparentemente, os projetos @gardenhead estão sendo lançados a uma velocidade bastante insana. A capacidade de continuar aprendendo é necessária se você quiser encontrar um emprego incrível.
Wayne Werner

19

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.


3
Sou membro do Mile High (Software) Club - comprometi o código a 35.000 pés. Claro, os aviões têm Wi - Fi agora , mas esse nem sempre foi o caso. E é bom saber que, pelo menos, se travarmos, existe a possibilidade de minha equipe manter meu código intacto.
Wayne Werner

@WayneWerner isso é verdade. Eu estava pensando em fornecer algumas situações mais genéricas onde não era possível estar (quase) sempre conectado. Por exemplo, em um avião, barco no mar, estação espacial, lugares remotos na África, etc.
Tersosauros

18

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.


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


4
Essa é a resposta certa, também do ponto de vista histórico. O kernel Linux possui vários repositórios de fontes há muito tempo (chamados de "árvores" pelos desenvolvedores, como "árvore de Linus" ou "árvore de Andrew"). O Linux queria algo para suportar esse tipo de desenvolvimento distribuído quando desenvolveu o git.
sleske

@Luaan Depois de pensar nisso por um tempo, percebi que você estava certo. Mudei um pouco a redação - isso captura a distinção um pouco melhor?
fofo

@fluffy Parece bom para mim;)
Luaan

9

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 :

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.

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


SVN não ganhou svn initem algum momento?
immibis

5

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.


1
Concordo que a flexibilidade do Git precisa ser atenuada na maioria dos casos de uso. No meu último trabalho, não tínhamos diretrizes sobre como usar o git, e havia constantes conflitos e falhas devido a isso. Na minha nova empresa, usamos o modelo Git Flow, que torna o desenvolvimento muito mais simplificado e sem estresse.
precisa saber é o seguinte

1
Não é "flexibilidade teórica" ​​permitir não-árvores. Restrinja-se a "somente árvores" e você nunca poderá mesclar suas alterações, tornando todo o seu VCS um tanto inútil.
Curinga

2
@Wildcard: Mesclar não é um problema com as árvores, por que seria esse o caso? Você não pode mesclar entre nós aleatórios, é claro, apenas entre pai / filho.
MSalters

1
Eu não estava claro o suficiente, evidentemente. Eu estava me referindo a uma árvore de commits, não a uma árvore do sistema de arquivos. Por definição, um commit de mesclagem possui mais de um pai e, portanto, seu gráfico de histórico não é mais uma árvore, mas um DAG.
Curinga

2
@Wildcard: MSalters disse que os repositórios geralmente são conectados como árvores, e não os commits. Ele está dizendo que os repositórios geralmente têm apenas um controle remoto "upstream" para o qual enviam (ou emitem solicitações pull). Não tenho estatísticas sobre se isso é verdade ou não, mas é uma afirmação completamente separada de qualquer relação com quantos pais um commit de mesclagem tem.
21716 Steve Joplin

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


3

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.


"Eu desconfio de daemons rodando no meu próprio computador ou no laptop fornecido pela empresa". - porque, além de qualquer outra coisa, executar um serviço no meu laptop significa que o serviço não está disponível quando eu fecho a tampa! O DynDNS pode ajudar em vários locais (até certo ponto, você ainda pode estar preso atrás de um NAT), mas não ajuda a desligar sua placa de rede ... #
1760 Steve

Existem várias maneiras de tornar um repositório git visível sem executar nenhum daemon especial; Ele pode ser acessado através de praticamente qualquer compartilhamento de arquivos (smb, sshfs, etc.), e também pode ser disponibilizado como uma simples loja HTTP.
fofo

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


Se você estiver indo para votar, você poderia deixar um comentário sobre o porquê?
Theodore Norvell

Não que eu me importe com os votos negativos. Eu só quero saber se a resposta está errada de alguma forma.
Theodore Norvell

1

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.


-2

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

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.