Usando git / mercurial em projetos com refactoring contínua?

votos
20

Eu estou tentando entender se eu realmente tenho qualquer caso para usar git / mercurial.

Os projetos que trabalham são projetos Java e C #, normalmente com 5-20 pessoas que trabalham para um objectivo comum (o release). A maioria dos desenvolvedores são desenvolvedores profissionais que refatorar código de todos os tempos . Então, onde o kernel Linux típico tem um grande número de alterações relativamente independentes em arquivos separados, temos um fluxo constante de alterações de refatoração - muitas vezes bater um monte de arquivos e um monte de código. Ninguém está com medo de alterar o código aqui.

Agora, com a subversão que resolver este por ficar muito perto de SVN HEAD. Alguns de nós ainda automatizaram svn up é o gatilho na transmissão jabber do servidor de compilação. A maioria de nós também aprendemos (ou aprender muito rapidamente) como planejar nosso trabalho para ficar perto de SVN HEAD. Se você está fazendo uma grande refatoração que incrementalmente dobrar a árvore fonte em uma nova direção em vez de ir para longe por muito tempo. Às vezes você apenas planejar a operação de refatoração e começar nas áreas menos sustentou. Depois de alguns anos de trabalho desta forma, torna-se uma segunda natureza. A maioria de nós simplesmente nunca deixar a zona de conforto de estar a menos de 2 horas de distância da cabeça SVN. A construção e svn cabeça automatizado é o projeto pulso e nós gostamos.

Claro que se ramificam cada lançamento, mas o número de backmerges da liberação-ramo de volta ao tronco diminuir para baixo rapidamente o suficiente para ser insignificante (temos cobertura de teste decente). Correndo por dias / semanas com ramos particulares da fonte soa como algo que queremos ativamente para desencorajar, e isso simplesmente não acontece com muita freqüência.

Ambos git eo modo de som mercurial fresco, git um pouco mais porque eu sou mais um tipo McGyver do que um tipo de James Bond. Mas quando se trata de construir um caso para efectivamente a mudar, parece que Linus e eu estamos vivendo em dois planetas diferentes. Na maioria das vezes nós queremos nossas equipes para manter o foco na cabeça.

Como pode GIT fazer o meu controle de versão melhor? Como GIT iria deixar-me a melhorar o meu processo? Eu sou um dinossauro subversão?

Publicado 10/12/2008 em 10:43
fonte usuário
Em outras línguas...                            


6 respostas

votos
19

Em termos de mentalidade, às vezes há um benefício em ser capaz de criar um soft-ramo, executar todas as mudanças no ramo macio, testar o resultado das mudanças no ramo macio, e, em seguida, quando o soft-ramo é "completa ", reintegrá-lo com o ramo principal localmente, testar novamente, e então propagá-la.

Este, em alguns casos é melhor do que a cabeça apressado, porque você não tem a interrupção constante da existência de outros código de depuração sujar o seu código para adicionar não-erros de manusear.

Também significa que você pode cometer mais vezes, dando uma história mais abrangente, porque commits não instantaneamente transformar-se problemas em todos os lugares criando.

Além disso, quando reconciliando consigo o soft-ramo com a linha principal compartilhada, você começa a ver uma bela completa mudança-set, mostrando-lhe ambos todas as suas mudanças coletivas, e todas as suas mudanças coletivas, que abre a porta para agradáveis ​​oportunidades de revisão de código.

Além disso, a partir de uma perspectiva de teste, se você tiver mais suaves-ramos, você pode executar os testes sobre os ramos macios antes de fundir-los de volta para o ramo principal, e têm um padrão pelo qual, um ramo não ficar colada de volta para o principal ramo até que ele tem

  1. Testes passaram por conta própria
  2. Testes passaram após ramos principais mudanças foram reconciliados para o soft-branch

Assim, dando-lhe uma garantia extra de qualidade do código, em que o seu ramo principal colaboração é extra completamente limpa, porque o código de falha não é permitida a aparecer nele.

(Que também limita a resolução de problemas de domínio, porque você só tem que testar suas próprias mudanças para a maior parte, e quando você está 'feito', só então você tem que se preocupar com o que todo mundo fez, e o que eles fizeram também deve ser passado em testes, o que significa que quando algo não falhar, você só tem que olhar para o que você fez para resolver o problema)

Mas eu gostaria de continiously atualizar da cabeça repo central, em meu softbranch? Esta é realmente a essência do meu problema

A beleza do sistema da filial é que você pode puxar "o que tem sido considerada estável pelos outros" em sua cópia local, conforme necessário.

"Update contínua" torna-se desnecessário, porque você não tem os mesmos problemas que se manifestam.

a  b   center
         |
         |
         /      Key:   / - | \   = Flow
/----<---|             < >       = Flow Directions
|  /--<--/             *         = Commit 
*  |     |             T         = Test
|  *     |             M         = Merging with "Current" state of common branch
*  |     |             C         = Tests Complete and Current state is "sane"
|  *     |
T  |     |
|  T     |
|  C     |
|  |/-<--/
*  M     |
|  T     |
*  C     |
|  \--->-\
*  /---<-/
T  |     |
C  *     |
|/-----<-/
M  |     |
T  *     |
|  T     |
*  C     |
|  |/-<--/
*  M     |
T  T     |
C  \-->--\
|/---<---/
M        |
T        |
C        |
\---->---\
         |

Além disso, por causa de como o sistema funciona, mais tarde, isso também poderia ocorrer:

a  b   center
|  |     |
T  |     |
C  *     |
|/</     |
M  |     |
|  *     |
T        |
C        |
|/----<--/
M        |
T        |
C        |
\-->-----\
         |

Todo o conceito de serem uma "cabeça" em tal cenário desaparece. Ele há dezenas de cabeças, que aquele que você vê é propenso a perspectiva.

Eu também poderia acrescentar, que estes ramos lógicas, embora apresentado como separada aqui, consegue viabilizar representar tanto locais de verificação geral individual, ou meros diferentes ramos macios em uma máquina singular. a & b poderia ser de fato um único desenvolvedor.

Em essência, "Continuamente atualizando meu softbranch de mainbranch", é conceitualmente sem sentido. Porque, na verdade, não haverá mudanças não representados na mainbranch ainda, e quando você vai saber que eles foram empurrados ou não? SVN Dá-lhe essa falsa ilusão de um estado de código "singular", quando na realidade, o usuário instante um abre um arquivo em seu editor de texto, eles têm de fato criou um soft-ramo vida muito curta, uma mudança que está ocorrendo, que ninguém conhece, e por essa ilusão de ser sustentado da maneira que você acha que funciona, na prática, o usuário tem a cometer depois de cada personagem, que é dificilmente prático. Então, na realidade, as pessoas se acostumar com o fato de que diferentes locais ficar "fora de sincronia" com o outro, e aprender maneiras de resolvê-lo para que ele não é mais um problema.

Além disso, o "constantemente atualizando minha árvore com todos mudanças elses" tem um problema central, na medida em que, você tem demasiadas distrações, você está constantemente a ser bombardeados com tudo todo mundo está fazendo, e se eles estão fazendo uma série de 1 linha compromete a testar algo que não posso teste em sua própria máquina, então você tem um pesadelo com o arquivo sempre mudando, e os usuários vejam as mudanças aparentemente aleatórios não pode dar sentido a eles.

Ao permitir corridas mais longas entre commits, e depois ver o resultado líquido em lotes e vendo apenas o resultado líquido de seus pares muda tudo de uma vez, você pode ver imediatamente o código foi alterado desde que você check-out e uma visão coesa do que significa para o seu código, assim você pode simplesmente escrever seu próprio código e acabar logo com isso.

Se você tem alguma dúvida

Comece com algo simples e não transição peru frio, alguns dos conceitos em DSCMs pode ser um pouco assustador (eu vi trágico fracasso por muitos a entender o conceito de soft-galhos empilhados verticalmente), mova uma pequena não- parte essencial da base de código para Git / Mercurial e brincar com ele por um tempo, experiência com os benefícios e que ele pode fazer. Não há prova melhor do que vivê-la a si mesmo, e todos os meus adoráveis ​​explicações não são susceptíveis de comunicar o que você precisa entender e só pode ser aprendida por tentar isso, e falhando algumas vezes (porque o fracasso é uma parte fundamental da aprendizagem)

Respondeu 10/12/2008 em 11:59
fonte usuário

votos
11

A forma como sua equipe usa Subversion significa que há um bastante esforço merge acontecendo. Quase toda vez que um membro da equipe atualizações para a linha principal mais recente que eles estão se fundindo sua cópia de trabalho com a mais recente linha principal, mesmo que eles não cometem suas próprias alterações nesta fase. A sobrecarga fusão tende a ser um produto de cometer taxa e o número de membros da equipa, e uma vez que comprometem taxa é uma função do número de membros da equipa, a sua sobrecarga de gerenciamento de código fonte é O (N ^ 2).

No modelo Mercurial / Git, este esforço fusão vai ser repartido entre a equipe. Se você puxar rotineiramente changesets de todos, então muitas vezes você vai descobrir que outros já fizeram quase todo o trabalho merge que você pode ter tido a ver. E, nos casos em que uma fusão tem quebrado algo, muitas vezes as pessoas vão já ter corrigido isso. Conciliar um par de ramos só tem que ser feito uma vez, e uma vez que a taxa de geração de novos ramos é proporcional ao número de membros da equipa, a sobrecarga de gerenciamento de código fonte é O (N).

Eu esperaria 20 desenvolvedores trabalhando perto da cabeça em um ramo é susceptível de envolver uma quantidade razoável de fusão de trabalho (lidar com conflitos e lidar com regressões devido ao desenvolvimento independente), então eu ficaria surpreso se você tentou Mercurial / git e não encontrou uma vitória útil produtividade. Você acha que você poderia gerenciar 100 desenvolvedores com o seu progresso atual? Eu estimaria o número de desenvolvedores do kernel do Linux em 4000, e ainda assim obter um monte de coisas feito ea sobrecarga de gerenciamento total de código-fonte devem ser aceitável.

Enquanto o seu sistema de gerenciamento de código fonte faixas parentesco comum, fusões são frequentemente automática. Cada merge tem uma chance de tanto ser um conflito textual ou quebrar a construção e testes devido à interação entre as mudanças; a menos funde você tem que fazer menos tempo você vai ter que gastar lidar com qualquer tipo de problema.

Consequentemente realmente uma grande vitória é que os usuários Mercurial / Git já não temem ramos. Antes BitKeeper (a ferramenta que realmente introduziu esta forma de trabalhar, tanto quanto eu sei), ramos de longa duração eram bombas-relógio tiquetaqueando, ocasionalmente, explodindo e tendo uma semana para se recuperar. Agora, podemos ramificar sem hesitação, com a confiança de que seremos capazes de fundir mais tarde. Em uma equipe saudável, outros podem ver os seus ramos em andamento e fundi-los para o deles e comprometer seus esforços mais tarde, se eles acham que vale a pena. Em um modelo centralizado, se cada desenvolvedor tinha 3 ou 4 ramos ativo, e eu estou corrigindo em dizer que é O (n ^ 2), então você apenas aumentou a sua sobrecarga de gerenciamento de código fonte por um fator de 3ish ^ 2, ou seja, uma ordem de magnitude, que é provavelmente o suficiente para realmente machucar geral de saúde, riqueza e felicidade.

Respondeu 10/12/2008 em 14:00
fonte usuário

votos
2

Acho mercurial é grande. Especialmente com TortoiseHg .

Uma das coisas que eu acho mais útil é a capacidade de compartilhar um desenvolvimento recurso com apenas um núcleo.

Vamos dizer que toda a equipe é de 20 pessoas, mas você só quer testar e desenvolver uma característica com uma equipe de 3-4 pessoas antes de se comprometer em repositório principal. Em seguida, com Mercurial, você só pode sincronizar código entre o codificador 3-4 até que você esteja satisfeito antes de se comprometer com o repositório principal.

Ou você pode até mesmo ser seu próprio time, por exemplo. quando você quiser testar seu código em plataformas múltiplas antes de cometer a repositório principal.

Respondeu 10/12/2008 em 12:10
fonte usuário

votos
2

Deu-lhe um voto para o bom humor no crack svn / dinossauro.

É possível usar o Git de uma forma muito semelhante você usa subversão assim nada seria perdido lá e quando, com o tempo, você e sua equipe iria encontrar alguns usos para bifurcação eficiente, ramificação, ou quaisquer outras características específicas Git bacana, eles poderiam ser implementado de uma forma ponderada e responsável.

Respondeu 10/12/2008 em 11:56
fonte usuário

votos
2

Por um lado, se nada mais, você pode usar GIT desligada, para que as pessoas podem continuar a trabalhar sob controle de origem mesmo durante a viagem ou em casa. Se qualquer um dos casos pode aplicar você pode definitivamente beneficiar GIT.

Respondeu 10/12/2008 em 10:55
fonte usuário

votos
1

o que você descreveu no SVN, pode ser feito usando git / mercurial

Respondeu 10/12/2008 em 13:31
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more