Como ter certeza que meu código de repo git é seguro?

Question

Se a nossa organização fosse para mudar de um VCS-servidor central como subversão de um VCS distribuídos como git, como posso ter certeza de que todo o meu código está a salvo de falha de hardware?

Com a-servidor central VCS Eu só preciso de backup do repositório de todos os dias. Se estivéssemos usando um DVCS, em seguida, haveria um monte de galhos de código em todas as máquinas de desenvolvedor, e se esse hardware vier a falhar (ou um dev estavam a perder o seu laptop ou tê-lo roubado), em seguida, nós não teríamos todos os backups .

Note que eu não considero isso uma boa opção para "fazer os desenvolvedores empurrar ramos para um servidor" - Isso é tedioso e os desenvolvedores vai acabar por não fazê-lo.

Existe uma maneira comum em torno este problema?

Alguns esclarecimentos:

Com um VCS-servidor nativamente-central, então, tudo tem que ser no servidor central, exceto alterações mais recentes do desenvolvedor. Assim, por exemplo, se um desenvolvedor decide ramo para fazer uma correção de bug que ramo está no servidor central e disponíveis para backup imediatamente.

Se estiver usando um DVCS, em seguida, o desenvolvedor pode fazer uma filial local (e de fato muitos ramos locais). Nenhum desses ramos estão no servidor central e disponíveis para backup até que o desenvolvedor pensa: "Oh sim, eu deveria empurrar isso para o servidor central".

Assim, a diferença que eu estou vendo (me corrija se eu estiver errado!): Características e correções Half-implementado provavelmente não está disponível para backup no servidor central, se estamos usando um DVCS, mas estão com um normal, VCS. Como faço para manter esse seguro código?

Answer 1

Eu acho que você vai descobrir que, na prática, os desenvolvedores preferem usar um repositório central de empurrar e puxar entre uns dos outros repositórios locais. Uma vez que você clonou um repositório central, enquanto trabalhava em quaisquer ramificações de controle, buscando e empurrando são comandos triviais. Adicionando meia dúzia de controles remotos para repositórios locais de todos os seus colegas é uma dor e esses repositórios não pode ser sempre acessível (desligado, em uma casa portátil tomadas, etc.).

Em algum momento, se todos vocês estão trabalhando no mesmo projeto, todas as necessidades de trabalho a ser integrado. Isso significa que você precisa um ramo de integração, onde todas as mudanças vêm juntos. Isto, naturalmente, precisa estar em algum lugar acessível por todos os desenvolvedores, ele não pertence, por exemplo, no laptop do principal desenvolvedor.

Uma vez que você configurar um repositório central, você pode usar a / fluxo de trabalho estilo svn cvs para check-in e atualização. cvs update torna-se git fetch e rebase se você tiver alterações locais ou puxar apenas git se não o fizer. cvs commit se torna git commit e git push.

Com esta configuração você está em uma posição similar com o sistema VCS totalmente centralizado. Uma vez que os desenvolvedores de apresentar as suas alterações (git push), o que eles precisam fazer para ser visível para o resto da equipe, eles estão no servidor central e será feito o backup.

O que preciso disciplina em ambos os casos está impedindo que os desenvolvedores mantendo longa executando mudanças para fora do repositório central. A maioria de nós provavelmente já trabalhou em uma situação em que um desenvolvedor está trabalhando em recurso 'x' que precisa de uma mudança fundamental em algum código do núcleo. A mudança fará com que todos os outros a necessidade de reconstruir completamente, mas o recurso não está pronto para o fluxo principal ainda assim ele continua o check-out até um ponto adequado no tempo.

A situação é muito semelhante em ambas as situações, embora existam algumas diferenças práticas. Usando git, porque você começa a executar commits locais e pode gerenciar a história local, a necessidade de empurrar para o repositório central não pode ser sentida tanto pelo desenvolvedor individual, com algo como cvs.

Por outro lado, o uso de commits locais pode ser usado como uma vantagem. Empurrando todos os commits locais para um lugar seguro no repositório central não deve ser muito difícil. filiais locais podem ser armazenados em um namespace tag de desenvolvedor específica.

Por exemplo, para Joe Bloggs, Um alias pode ser feita em seu repositório local para executar algo como o seguinte em resposta a (por exemplo) git mybackup.

git push origin +refs/heads/*:refs/jbloggs/*

Este é um único comando que pode ser usado em qualquer ponto (como o fim do dia) para se certificar de que todas as suas alterações locais são feito com segurança.

Isto ajuda com todos os tipos de desastres. máquina de Joe explode e ele pode usar outra máquina e buscar é salvo commits e continuar de onde parou. Joe está doente? Fred pode buscar ramos de Joe para a garra que 'deve ter' correção que ele fez ontem, mas não teve a oportunidade de testar contra o mestre.

Para voltar à pergunta inicial. Será que é necessário que haja uma diferença entre DVCS e VCS centralizado? Você diz que as funcionalidades implementadas meio e correções não vai acabar no repositório central no caso DVCS mas eu afirmaria que não precisa haver nenhuma diferença.

Já vi muitos casos em que uma caixa implementado por meio de recursos permanece numa desenvolvedores trabalhando ao usar VCS centralizado. Ele toma uma política que permite que recursos metade escrito para ser verificado na corrente principal ou uma decisão tem que ser feita para criar um ramo central.

Nos DVCS a mesma coisa pode acontecer, mas a mesma decisão deve ser tomada. Se há um trabalho importante, mas incompleta, ele precisa ser salvo centralmente. A vantagem de git é que a criação deste ramo central é quase trivial.

Answer 2

Eu acho que é uma falácia que o uso de um VCS distribuídos necessariamente significa que você deve usá-lo de uma forma completamente distribuído. É completamente válido para configurar um repositório git comum e dizer a todos que repositório é a oficial. Para fluxo de trabalho normal desenvolvimento, os desenvolvedores iria puxar as alterações do repositório comum e atualizar seus próprios repositórios. Apenas no caso de dois desenvolvedores colaborando ativamente em uma característica específica que pode precisar puxar muda diretamente uns com os outros.

Com mais de alguns desenvolvedores trabalhando em um projeto, seria seriamente tedioso ter que lembrar de puxar mudanças de todos os outros. O que você faria se você não ter um repositório central?

No trabalho temos uma solução de backup que faz o backup diretórios de trabalho de todo mundo diário e escreve todo o lote para um DVD semanal. Assim, embora tenhamos um repositório central, cada um indivíduo é apoiada também.

Answer 3

Não é incomum para usar um servidor "central" como uma autoridade em DVCS, que também fornece o lugar para fazer seus backups.

Answer 4

Eu acho que esta questão é um pouco bizarro. Supondo que você está usando um sistema de controle não distribuídos versão, como CVS, você terá um repositório no servidor central e trabalhos em curso sobre servidores dos desenvolvedores. Como você fazer backup do repositório? Como você fazer backup de trabalho dos desenvolvedores em andamento? A resposta a essas perguntas é exatamente o que você tem que fazer para lidar com a sua pergunta.

Usando controle de versão distribuído, repositórios em servidores dos desenvolvedores são apenas trabalho em andamento. Você quer apoiá-la? Em seguida, voltar-se! É tão simples como isso.

Nós temos um sistema de backup automatizado que pega todos os diretórios fora de nossas nossas máquinas que especifique, então eu adicionar quaisquer repositórios e cópias de trabalho em minha máquina a essa última, incluindo tanto Git e CVS repositórios.

A propósito, se você estiver usando o controle de versão distribuída em uma empresa lançar um produto, então você tem um repositório central. É o que você liberar a partir. Pode não estar em um servidor especial; pode ser no disco rígido de algum desenvolvedor. Mas o repositório você libera a partir é o repositório central. (Suponho que se você ainda não lançado, ainda, você pode não ter um, ainda.) Eu tipo de sensação que todos os projectos têm uma ou mais centrais repositórios. (E realmente se eles têm mais de um, é dois projetos e um deles é um garfo.) Isto vai para o código aberto também.

Mesmo se você não tem um repositório central, a solução é a mesma: back-up de trabalho em máquinas desenvolvedor. Você deveria estar fazendo isso de qualquer maneira. O fato de que o trabalho em andamento está em repositórios distribuídos em vez de CVS cópias de trabalho ou diretórios reta Nonversioned é imaterial.

Answer 5

Você poderia ter diretórios home desenvolvedor montar dispositivos remotos através da rede local. Então você só tem que se preocupar em fazer o cofre de armazenamento em rede. Ou talvez você poderia usar algo como DropBox para copiar o seu repo local, em outro lugar sem problemas.

Answer 6

Todos os desenvolvedores em sua equipe pode ter suas próprias filiais no servidor, bem como (pode ser por bilhete ou apenas por dev, etc). Dessa forma, eles não quebrar a construir no branch master mas ainda obtêm a empurrar o seu trabalho em progresso para o servidor que fica apoiada.

minha própria ferramenta git_remote_branch pode vir a calhar para esse tipo de fluxo de trabalho (Nota que requer rubi). Ele ajuda a manipular filiais remotas.

Como uma nota lateral, falando sobre a segurança repo, em seu servidor, você pode configurar um gancho post-commit que faz um clone git simples ou git push para outra máquina ... Você começa um up para backup de data após cada commit !

Answer 7

Nós usamos o rsync para fazer o backup dos desenvolvedores individuais .git diretórios em um diretório no servidor. Esta é a configuração usando scripts de invólucro em torno clone git, eo post-commit etc. ganchos.

Porque é feito nos ganchos pós-*, os desenvolvedores não precisam se lembrar de fazê-lo manualmente. E porque usamos o rsync com um tempo limite, se o servidor vai para baixo ou o usuário está trabalhando remotamente, eles ainda podem trabalho.