Existe uma maneira simples de fazer backup de um repositório Git inteiro, incluindo todas as ramificações e tags?

Que tal fazer um clone disso?

git clone --mirror other/repo.git

Todo repositório é um backup do seu controle remoto.

git bundle

Eu gosto desse método, pois resulta em apenas um arquivo, mais fácil de copiar.
Veja ProGit: pequeno pacote de alegria .
Consulte também " Como posso enviar um repositório git para alguém por e-mail? ", Onde o comando

git bundle create /tmp/foo-all --all

é detalhado:

git bundleempacotará apenas referências que são mostradas pelo git show-ref : isso inclui cabeças, tags e cabeças remotas.
É muito importante que a base usada seja mantida pelo destino.
É bom errar por precaução, fazendo com que o arquivo do pacote contenha objetos que já estão no destino, pois eles são ignorados ao descompactar no destino.

Para usar esse pacote, você pode cloná-lo, especificando uma pasta inexistente (fora de qualquer repositório git):

git clone /tmp/foo-all newFolder

Expandindo algumas outras respostas, é isso que eu faço:

Configure o repositório: git clone --mirror user@server:/url-to-repo.git

Então, quando você deseja atualizar o backup: git remote updatedo local do clone.

Isso faz o backup de todas as ramificações e tags, incluindo as novas que são adicionadas posteriormente, embora seja interessante notar que as ramificações excluídas não são excluídas do clone (o que para um backup pode ser uma coisa boa).

Isso é atômico e, portanto, não tem os problemas que uma cópia simples teria.

Consulte http://www.garron.me/en/bits/backup-git-bare-repo.html

Expandindo as ótimas respostas de KingCrunch e VonC

Eu combinei os dois:

git clone --mirror git@some.origin/reponame reponame.git
cd reponame.git
git bundle create reponame.bundle --all

Depois disso, você tem um arquivo chamado reponame.bundleque pode ser facilmente copiado. Você pode criar um novo repositório git normal a partir dele git clone reponame.bundle reponame.

Observe que git bundleapenas cópias confirmadas levam a alguma referência (ramificação ou tag) no repositório. Portanto, as confirmações de emaranhamento não são armazenadas no pacote.

Tudo está contido no .gitdiretório Faça o backup do seu projeto como faria com qualquer arquivo.

use git bundle ou clone

copiar o diretório git não é uma boa solução, pois não é atômico. Se você tiver um repositório grande que leva muito tempo para copiar e alguém envia para o repositório, isso afetará o backup. A clonagem ou criação de um pacote configurável não terá esse problema.

Você pode fazer backup do repositório git com git-copy no tamanho mínimo de armazenamento.

git copy /path/to/project /backup/project.repo.backup

Em seguida, você pode restaurar seu projeto com git clone

git clone /backup/project.repo.backup project

A resposta correta IMO é git clone --mirror . Isso fará um backup completo do seu repositório.

O espelho de clone do Git clonará todo o repositório, notas, cabeças, refs, etc. e é normalmente usado para copiar um repositório inteiro para um novo servidor git. Isso abrirá todos os ramos e tudo, todo o repositório.

git clone --mirror git@example.com/your-repo.git

• Normalmente, a clonagem de um repositório não inclui todas as ramificações, apenas o Mestre.

• Copiar a pasta de repo apenas "copiará" as ramificações que foram puxadas ... então, por padrão, isso é apenas ramificação mestre ou outras ramificações que você efetuou check-out anteriormente.

• O comando Git bundle também não é o que você deseja: "O comando bundle empacotará tudo o que normalmente seria enviado por fio com um comando git push em um arquivo binário que você pode enviar por e-mail para alguém ou colocar em uma unidade flash, e então desmembrar em outro repositório ". (De Qual é a diferença entre git clone --mirror e git clone --bare )

Esse encadeamento foi muito útil para obter algumas idéias de como os backups dos repositórios git poderiam ser feitos. Acho que ainda faltam algumas dicas, informações ou conclusões para encontrar o "caminho correto" (tm) para si mesmo. Portanto, compartilho meus pensamentos aqui para ajudar outras pessoas e colocá-las em discussões para melhorá-las. Obrigado.

Então, começando com a pergunta original:

• O objetivo é chegar o mais próximo possível de um backup "completo" de um repositório git.

Depois, enriquecendo-o com os desejos típicos e especificando algumas predefinições:

• O backup através de uma "cópia a quente" é o preferido para evitar o tempo de inatividade do serviço.
• As falhas do git serão contornadas por comandos adicionais.
• Um script deve fazer o backup para combinar as várias etapas de um único backup e evitar erros humanos (erros de digitação, etc.).
• Além disso, um script deve fazer a restauração para adaptar o dump à máquina de destino, por exemplo, mesmo a configuração da máquina original pode ter sido alterada desde o backup.
• O Environment é um servidor git em uma máquina Linux com um sistema de arquivos que suporta hardlinks.

1. O que é um backup de repositório git "completo"?

O ponto de vista difere do que é um backup "100%". Aqui estão dois típicos.

Nº 1 do ponto de vista do desenvolvedor

• Conteúdo
• Referências

O git é uma ferramenta de desenvolvedor e suporta esse ponto de vista via git clone --mirrore git bundle --all.

# 2 Ponto de vista do administrador

• Arquivos de conteúdo
  • Caso especial "packfile": o git combina e compacta objetos em arquivos de pacote durante a coleta de lixo (veja git gc)
• configuração git
  • consulte https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain
  • docs: man git-config, man gitignore
  • .git / config
  • .git / description (para ganchos e ferramentas, por exemplo, gancho pós-recebimento de e-mail, gitolite, GitWeb, etc.)
  • .git / hooks /
  • .git / info / (arquivo de exclusão do repositório etc.)
• Opcional: configuração do sistema operacional (permissões do sistema de arquivos etc.)

O git é uma ferramenta de desenvolvedor e deixa isso para o administrador. O backup da configuração do git e da configuração do sistema operacional deve ser visto como separado do backup do conteúdo.

2. Técnicas

• "Cópia a frio"
  • Pare o serviço para ter acesso exclusivo aos seus arquivos. Tempo de inatividade!
• "Cópia a quente"
  • O serviço fornece um estado fixo para fins de backup. As mudanças em andamento não afetam esse estado.

3. Outros tópicos para pensar

A maioria deles é genérica para backups.

• Existe espaço suficiente para armazenar os backups completos? Quantas gerações serão armazenadas?
• É necessária uma abordagem incremental? Quantas gerações serão armazenadas e quando criar um backup completo novamente?
• Como verificar se um backup não está corrompido após a criação ou ao longo do tempo?
• O sistema de arquivos suporta hardlinks?
• Colocar o backup em um único arquivo ou usar a estrutura de diretórios?

4. O que o git fornece para fazer backup de conteúdo

• git gc --auto

  • docs: man git-gc
  • Limpa e compacta um repositório.

• git bundle --all

  • docs: man git-bundle, man git-rev-list
  • Atomic = "Cópia a quente"
  • Pacotes são arquivos de despejo e podem ser usados ​​diretamente com o git (verificar, clonar etc.).
  • Suporta extração incremental.
  • Verificável via git bundle verify.

• git clone --mirror

  • docs: man git-clone, man git-fsck, qual é a diferença entre git clone --mirror e git clone --bare
  • Atomic = "Cópia a quente"
  • Os espelhos são repositórios reais do git.
  • A intenção principal deste comando é construir um espelho ativo completo, que busca atualizações periodicamente no repositório original.
  • Suporta hardlinks para espelhos no mesmo sistema de arquivos para evitar desperdiçar espaço.
  • Verificável via git fsck.
  • Os espelhos podem ser usados ​​como base para um script de backup completo de arquivos.

5. Cópia a frio

Um backup de cópia a frio sempre pode fazer um backup completo de arquivos: negar todos os acessos aos repositórios git, fazer backup e permitir acessos novamente.

• Possíveis Questões
  • Pode não ser fácil - ou até possível - negar todos os acessos, por exemplo, acesso compartilhado via sistema de arquivos.
  • Mesmo se o repositório estiver em uma máquina somente cliente com um único usuário, o usuário ainda poderá confirmar algo durante uma execução de backup automatizada :(
  • O tempo de inatividade pode não ser aceitável no servidor e fazer um backup de vários repositórios enormes pode levar muito tempo.
• Ideias para Mitigação:
  • Evite o acesso direto ao repositório via sistema de arquivos em geral, mesmo se os clientes estiverem na mesma máquina.
  • Para acesso SSH / HTTP, use gerenciadores de autorização git (por exemplo, gitolite) para gerenciar dinamicamente o acesso ou modificar arquivos de autenticação de maneira com script.
  • Os repositórios de backup são individualizados para reduzir o tempo de inatividade de cada repositório. Negue um repositório, faça backup e permita acesso novamente e continue com o próximo repositório.
  • Planeje o cronograma de manutenção para evitar transtornos aos desenvolvedores.
  • Faça backup somente quando o repositório for alterado. Talvez seja muito difícil de implementar, por exemplo, lista de objetos, além de ter arquivos de pacotes em mente, somas de verificação de configurações e ganchos, etc.

6. Cópia a quente

Os backups de arquivos não podem ser feitos com repositórios ativos devido ao risco de dados corrompidos por confirmações contínuas. Uma cópia a quente fornece um estado fixo de um repositório ativo para fins de backup. As confirmações contínuas não afetam essa cópia. Conforme listado acima, as funcionalidades de clone e pacote configurável do git suportam isso, mas para um backup "100% admin" várias coisas precisam ser feitas por meio de comandos adicionais.

Backup de cópia a quente "100% admin"

• Opção 1: use git bundle --allpara criar arquivos de despejo completo / incremental de conteúdo e copiar / fazer backup dos arquivos de configuração separadamente.
• Opção 2: use git clone --mirror, manipule e copie a configuração separadamente e faça o backup completo dos arquivos do espelho.
  • Notas:
  • Um espelho é um novo repositório, preenchido com o modelo git atual na criação.
  • Limpe os arquivos e diretórios de configuração e copie os arquivos de configuração do repositório de origem original.
  • O script de backup também pode aplicar a configuração do SO, como permissões de arquivo no espelho.
  • Use um sistema de arquivos que suporte hardlinks e crie o espelho no mesmo sistema de arquivos do repositório de origem para ganhar velocidade e reduzir o consumo de espaço durante o backup.

7. Restaurar

• Verifique e adote a configuração git para atingir a máquina e a mais recente filosofia de "maneira de fazer".
• Verifique e adote a configuração do sistema operacional para atingir a máquina e a mais recente filosofia de "maneira de fazer".

cd /path/to/backupdir/
git clone /path/to/repo
cd /path/to/repo
git remote add backup /path/to/backupdir
git push --set-upstream backup master

isso cria um backup e faz a configuração, para que você possa executar um git push para atualizar seu backup, o que provavelmente é o que você deseja fazer. Apenas certifique-se de que / path / to / backupdir e / path / to / repo sejam pelo menos diferentes discos rígidos, caso contrário, não faz muito sentido fazer isso.

Aqui estão duas opções:

1. Você pode pegar diretamente um tar do diretório git repo, pois ele tem todo o conteúdo do repositório no servidor. Há uma pequena possibilidade de que alguém possa estar trabalhando no repo enquanto faz backup.

2. O comando a seguir fornecerá o clone simples de repo (exatamente como no servidor), e você poderá obter um tar do local em que você clonou sem nenhum problema.

   git clone --bare {your backup local repo} {new location where you want to clone}
   

Se estiver no Github, navegue até o bitbucket e use o método "import repository" para importar seu repositório do github como um repositório particular.

Se estiver no bitbucket, faça o contrário.

É um backup completo, mas permanece na nuvem, que é o meu método ideal.

Até onde eu sei, você pode simplesmente fazer uma cópia do diretório em que seu repositório está, é isso!

cp -r project project-backup