Gerenciamento de controle de versão de grandes projetos

A maneira como isso é feito é que cada desenvolvedor deve mesclar as alterações antes de confirmar um arquivo. Eu nunca usei o Mercurial, então eu não sei os comandos ou o processo exato, mas em qualquer ferramenta séria de gerenciamento de configuração você será avisado se tentar fazer o check-in "por cima" de outra pessoa. Quando você receber esse aviso, você deverá mesclar as outras alterações na sua cópia com check-out, verificar a compilação e os testes, etc. e, em seguida, fazer check-in.

Este é um problema muito comum, e a fusão dessa maneira pode ser uma PITA real, mas é a vida. A abordagem alternativa de bloquear todos os arquivos com check-out evita esse problema, mas tem a séria desvantagem de bloquear todos os outros enquanto você trabalha em um arquivo, o que, por sua vez, leva as pessoas a editar versões descontroladas. >     

Não tenho certeza se o Mercurial é diferente, mas o git simplesmente não permite * que você envie para um destino que tenha divergido da sua filial (por exemplo, no seu caso, se o Bob empurrar primeiro , então o servidor divergiu do ramo de Carl). Carl deve derrubar as mudanças de Bob, comprometê-las e depois empurrar.

* bem, se você usar a opção --force. Mas se você tem que usar isso, você deve saber o porquê.

Com o mercurial, você só pode ter várias cabeças no repositório upstream se Carl forçar seu push. O que deve acontecer é que depois que Bob e Carl fizerem a fusão das mudanças de Alice, Bob, que deve empurrar primeiro, deve ser Ok, mas Carl receberá uma mensagem dizendo que seu empurrão criaria novas cabeças remotas e que seu empurrão seria cancelado. / p>

A solução, é claro, é para Carl puxar as mudanças do Bobs, juntá-las e depois empurrar de volta essa fusão também, para que você acabe com todos os três conjuntos de mudanças.

A freqüência com que você vê esse tipo de problema dependerá do tamanho do seu repositório e da frequência com que os desenvolvedores trabalham nas mesmas coisas simultaneamente. Também depende se os desenvolvedores têm o hábito de forçar os push (ou configurar suas ferramentas para fazê-lo automaticamente). Se este for o caso, eu recomendaria strongmente contra ele.

Se você vê pessoas trabalhando no mesmo código com muita frequência, talvez você deva verificar se seu aplicativo tem excesso de acoplamento (digamos, um super-singleton que precisa ser editado sempre que alguém mudar alguma coisa em qualquer outro lugar no código) ou se você precisa dividir seu repositório em um grupo de sub-repositórios.

Algo está errado com sua configuração do Mercurial (ou não sei como esse sistema deve funcionar). Não deveria permitir o surgimento de "duas cabeças". Deve ser Alice - & nbsp; Bob - & Carl - Alice & Alice - & nbsp; Carl & Bob; Foi assim que funcionou no Subversion em ambas as equipes em que trabalhei, e sempre conseguimos resolver os conflitos. A mesclagem contínua ajuda muito. Tentar mesclar o trabalho de dois meses de vários desenvolvedores em um ramo diferente geralmente dói.

Não é tão ruim quanto você pensa que seria na prática.

Na teoria , se duas pessoas estivessem trabalhando no mesmo arquivo nas mesmas linhas , então é um problema que precisa de intervenção manual.

No entanto, na prática , essa situação é muito rara. É mais provável que eles estejam trabalhando no mesmo arquivo, mas em locais diferentes. Se os dois (ou três, ou quatro) desenvolvedores estão trabalhando em seções diferentes do arquivo, a mesclagem automática é geralmente inteligente o suficiente para descobrir isso.

Há ocasiões em que modifiquei uma linha de código e um colega de trabalho modificou a linha mesmo para que, quando eu puxar o mais recente do controle de origem, eu precise mesclar manualmente. Mas isso é raro e geralmente só acontece se eu fizer uma alteração grande que toque um grande número de linhas de qualquer maneira (por exemplo, se eu tiver modificado algumas APIs usadas por muitos clientes).

Seu cenário - três pessoas - um arquivo - é um sintoma de arquitetura deficiente e gerenciamento inadequado.

Este não é um problema de ferramenta.

Eu não sei se o mercurial suporta isso, mas em uma pequena equipe coesa, o fluxo de trabalho centralizado pode ser o melhor. Neste fluxo de trabalho, os desenvolvedores precisam atualizar / extrair o servidor central antes de poderem enviar um novo commit.

Em projetos maiores ou distribuídos, recomendo o fluxo de trabalho do gatekeeper :

• Os desenvolvedores não se mesclam. O gatekeeper mescla as ramificações do desenvolvedor em um ramo designado como o ramo oficial.
• Os desenvolvedores trabalham em ramos de recursos e, quando um recurso é feito, eles propõem ao gatekeeper a mesclagem.
• O gatekeeper tem uma boa compreensão geral do projeto. Se a fusão de uma ramificação resultar em conflitos, ele pode precisar da ajuda do desenvolvedor para resolvê-los, mas talvez não, já que os conflitos devem ser causados por uma proposta de mesclagem que ele recentemente aprovou.
• O gatekeeper também é responsável pela qualidade do código e pelas práticas recomendadas em todo o projeto. Ele rejeita propostas de mesclagem que tenham algum problema, o desenvolvedor original deve executar as correções necessárias e reenviar sua ramificação.
• Ser um gatekeeper é uma atividade em tempo integral.
• À medida que o projeto cresce, pode haver mais gatekeepers, formando uma hierarquia.