Uma explicação passo a passo de alguns dos recursos básicos do git-anexo, usando a linha de comando. Se você não quiser usar a linha de comando, consulte o início rápido .

O que segue é apenas um fluxo de trabalho possível para o uso do git-anexo, mas o acompanhamento ensinará os conceitos básicos desde o início.

criando um repositório adicionando arquivos adicionando um controle remoto renomeando arquivos obtendo conteúdo do arquivo sincronizando transferência de arquivos: quando as coisas dão errado removendo arquivos remover arquivos: quando as coisas dão errado modificando arquivos anexados usando controles remotos ssh usando controles remotos especiais movendo o conteúdo do arquivo entre repositórios quieto por favor: Quando o git-anexo parece pular arquivos usando tags e ramificações dados não utilizados fsck: verificando seus dados fsck: quando as coisas dão errado backups gerenciamento automático de conteúdo Mais criando um repositório Isso é muito direto.

$ mkdir ~/annex

$ cd ~/annex

$ git init

$ git annex init

adicionando arquivos

$ cd ~/annex

$ cp /tmp/big_file .

$ cp /tmp/debian.iso .

$ git annex add .

add big_file (checksum...) ok add debian.iso (checksum...) ok

$ git commit -a -m added

Quando você adiciona um arquivo ao anexo e o confirma, apenas um link simbólico para o conteúdo é comprometido com o git. O conteúdo em si é armazenado em .git/annex/objects/

adicionando um controle remoto Como qualquer outro repositório git, os repositórios git-anexos possuem controles remotos. Vamos começar adicionando uma unidade USB como controle remoto.

$ sudo mount /media/usb

$ cd /media/usb

$ git clone ~/annex

$ cd annex

$ git annex init "portable USB drive"

$ git remote add laptop ~/annex

$ cd ~/annex

$ git remote add usbdrive /media/usb/annex

Essa é toda a configuração padrão do repositório git distribuído ad-hoc.

A única parte específica do git-anexo é fornecer uma descrição do novo repositório criado na unidade USB. Isso é opcional, mas fornecer uma descrição ao repositório ajuda quando o git-annex falar sobre isso mais tarde.

Observe que os dois repositórios são configurados como controles remotos um do outro. Isso permite obter arquivos anexados do outro. Você vai querer fazer isso mesmo se estiver usando o git de uma maneira mais centralizada.

renomeando arquivos $ cd ~/annex

$ git mv big_file my_cool_big_file

$ mkdir iso

$ git mv debian.iso iso/

$ git commit -m moved

Você pode usar qualquer operação normal do git para mover arquivos, ou até mesmo fazer cópias ou excluí-los.

Observe que, como os arquivos anexados são representados por links simbólicos, o link simbólico será interrompido quando o arquivo for movido para um subdiretório. Mas, o git-anexo corrigirá isso para você quando você confirmar - ele possui um gancho de pré-confirmação que procura e corrige links simbólicos quebrados.

obtendo conteúdo do arquivo Um repositório nem sempre tem todo o conteúdo do arquivo anexado disponível. Quando você precisar do conteúdo de um arquivo, poderá usar "git annex get" para disponibilizá-lo.

Podemos usar isso para copiar tudo no anexo do laptop para a unidade USB.

$ cd /media/usb/annex

$ git annex sync laptop

$ git annex get .

get my_cool_big_file (from laptop...) ok get iso/debian.iso (from laptop...) ok sincronizando Observe que no exemplo anterior , git annex syncfoi usado. Isso permite que o git-anexo saiba o que mudou em outros repositórios, como o laptop, para que ele saiba sobre os arquivos presentes lá e possa obtê-los.

Vejamos o que o comando sync faz com mais detalhes:

$ cd /media/usb/annex

$ git annex sync

commit nothing to commit (working directory clean) ok pull laptop ok push laptop ok Depois de executar a sincronização, o repositório git será atualizado com todas as alterações feitas em seus controles remotos, e quaisquer alterações no repositório git serão enviadas para seus controles remotos, onde uma sincronização as obterá. Isso é especialmente útil ao usar o git de maneira distribuída, sem um repositório básico . Veja sincronização para detalhes.

Por padrão, git annex syncapenas sincroniza os metadados dos seus arquivos armazenados no git. Ele não sincroniza o conteúdo dos arquivos gerenciados pelo git-anexo. Para fazer isso, você pode usargit annex sync --content

transferência de arquivos: quando as coisas dão errado Depois de um tempo, você terá vários anexos, com diferentes conteúdos de arquivos. Você não precisa tentar manter tudo isso em ordem; O git-anexo faz o rastreamento de localização para você. Se você solicitar um arquivo e a unidade ou o servidor de arquivos não estiver acessível, você saberá o que é necessário para obtê-lo:

$ git annex get video/hackity_hack_and_kaxxt.mov

get video/hackity_hack_and_kaxxt.mov (not available) Unable to access these remotes: usbdrive, server Try making some of these repositories available: 5863d8c0-d9a9-11df-adb2-af51e6559a49 -- my home file server 58d84e8a-d9ae-11df-a1aa-ab9aa8c00826 -- portable USB drive ca20064c-dbb5-11df-b2fe-002170d25c55 -- backup SATA drive failed

$ sudo mount /media/usb

$ git annex get video/hackity_hack_and_kaxxt.mov

get video/hackity_hack_and_kaxxt.mov (from usbdrive...) ok removendo arquivos Quando você está usando o git-anexo, pode criar git rmum arquivo como faria normalmente com o git. Assim como no git, isso remove o arquivo da sua árvore de trabalho, mas não remove o conteúdo do arquivo do repositório git. Se você verificar o arquivo novamente ou reverter a remoção, poderá recuperá-lo.

O Git-anexo adiciona a capacidade de remover o conteúdo de um arquivo do seu repositório local para economizar espaço. Isso é chamado "descartando" o arquivo.

Você sempre pode soltar arquivos com segurança. O Git-anexo verifica se algum outro repositório ainda possui o arquivo antes de removê-lo.

$ git annex drop iso/debian.iso

drop iso/Debian_5.0.iso ok Uma vez descartado, o arquivo ainda aparecerá na sua árvore de trabalho como um link simbólico quebrado. Você pode usar git annex getcomo de costume para obter esse arquivo de volta ao seu repositório local.

remover arquivos: quando as coisas dão errado Antes de soltar um arquivo, o git-anexo deseja poder ver outros controles remotos e verificar se eles ainda têm um arquivo. Afinal, poderia ter sido retirado deles também. Se os controles remotos não estiverem montados / disponíveis, você verá algo assim.

$ git annex drop important_file other.iso

drop important_file (unsafe) Could only verify the existence of 0 out of 1 necessary copies Unable to access these remotes: usbdrive Try making some of these repositories available:

58d84e8a-d9ae-11df-a1aa-ab9aa8c00826 -- portable USB drive ca20064c-dbb5-11df-b2fe-002170d25c55 -- backup SATA drive (Use --force to override this check, or adjust numcopies.) failed drop other.iso (unsafe) Could only verify the existence of 0 out of 1 necessary copies No other repository is known to contain the file. (Use --force to override this check, or adjust numcopies.) failed Aqui você pode - forçar a queda, important_filese confiar no seu backup. Mas other.isoparece que nunca foi copiado para nenhum outro lugar; portanto, se você quiser se apegar a algo, precisará transferi-lo para outro repositório antes de soltá-lo.

modificando arquivos anexados Normalmente, o conteúdo dos arquivos no anexo é impedido de ser modificado.

Isso é uma coisa boa, porque pode ser a única cópia, você não gostaria de perdê-la com um erro desajeitado.

$ echo oops > my_cool_big_file

bash: my_cool_big_file: Permission denied Para modificar um arquivo, ele deve primeiro ser desbloqueado.

$ git annex unlock my_cool_big_file

unlock my_cool_big_file (copying...) ok Isso substitui o link simbólico que normalmente aponta para seu conteúdo por uma cópia do conteúdo. Você pode modificar o arquivo como qualquer arquivo normal. Porque é um arquivo regular.

(Se você decidir que não precisa modificar o arquivo, afinal, ou deseja descartar modificações, basta usar git annex lock.)

Quando você confirma um arquivo desbloqueado, tudo o que é comprometido com o git é um ponteiro para o conteúdo. O conteúdo do arquivo é armazenado pelo git-anexo.

$ echo "now smaller, but even cooler" > my_cool_big_file

$ git commit my_cool_big_file -m "changed an annexed file"

add my_cool_big_file ok [master 64cda67] changed an annexed file 1 files changed, 1 insertions(+), 1 deletions(-) Para obter mais detalhes sobre como trabalhar com arquivos desbloqueados versus arquivos bloqueados regulares, consulte Arquivos desbloqueados .

usando controles remotos ssh Até agora nesta explicação passo a passo, o git-anexo foi usado com um repositório remoto em uma unidade USB. Mas também pode ser usado com um git remote verdadeiramente remoto, um host acessado pelo ssh.

Digamos que você tenha uma área de trabalho na mesma rede que o seu laptop e queira clonar o anexo do laptop:

desktop$ git clone ssh://mylaptop/home/me/annex ~/annex desktop$ cd ~/annex desktop$ git annex init "my desktop" Agora você pode obter arquivos e eles serão transferidos (usando rsyncvia ssh):

desktop$ git annex get my_cool_big_file get my_cool_big_file (getting UUID for origin...) (from origin...) SHA256-s86050597--6ae2688bc533437766a48aa19f2c06be14d1bab9c70b468af445d4f07b65f41e 100% 2159 2.1KB/s 00:00 ok Quando você solta arquivos, o git-anexo ssh no controle remoto e verifique se o conteúdo do arquivo ainda está lá antes de removê-lo localmente:

desktop$ git annex drop my_cool_big_file drop my_cool_big_file (checking origin..) ok Observe que normalmente o git-anexo prefere usar controles remotos não ssh, como uma unidade USB, antes dos controles remotos ssh. Eles são considerados mais rápidos / baratos para acessar, se disponíveis. Há uma configuração de custo em anexo que você pode configurar .git/configpara ajustar quais repositórios ele prefere. Veja a página de manual para detalhes.

Além disso, observe que você precisa de acesso completo ao shell para que isso funcione - o git-anexo precisa ser capaz de executar ssh e executar comandos. Ou pelo menos, seu shell precisa poder executar o comando git-annex-shell .

Para obter detalhes sobre a configuração de controles remotos ssh, consulte o tutorial do repositório centralizado do git .

usando controles remotos especiais Vimos acima que o git-anexo pode ser usado para armazenar arquivos em controles remotos git regulares, acessados ​​via ssh ou em uma unidade removível. Mas o git-anexo também pode armazenar arquivos no Amazon S3, Glacier, em um servidor rsync, no WebDAV, ou até mesmo extrair arquivos da Web e do bittorrent. Isso e muito mais é possível graças a controles remotos especiais .

Estes não são repositórios git normais; de fato, o repositório git não é armazenado em um controle remoto especial. Mas o git-anexo pode armazenar o conteúdo dos arquivos em controles remotos especiais e operá-los da mesma maneira que faria em qualquer outro controle remoto. Bônus: os arquivos armazenados em controles remotos especiais podem ser facilmente criptografados !

Tudo o que você precisa para começar a usar um controle remoto especial é inicializá-lo. Isso é feito usando o git annex initremotecomando, que precisa receber parâmetros diferentes, dependendo do tipo de controle remoto especial.

Alguns controles remotos especiais também precisam de coisas como senhas para serem definidas nas variáveis ​​de ambiente. Não se preocupe - ele será solicitado se você deixar alguma coisa de fora. Portanto, sinta-se à vontade para criar qualquer tipo de controle remoto especial em vez do controle remoto S3 usado neste exemplo.

$ export AWS_ACCESS_KEY_ID="somethingotherthanthis"

$ export AWS_SECRET_ACCESS_KEY="s3kr1t"

$ git annex initremote mys3 type=S3 chunk=1MiB encryption=shared

initremote mys3 (shared encryption) (checking bucket) (creating bucket in US) ok Agora você pode armazenar arquivos no controle remoto especial recém-inicializado.

$ git annex copy my_cool_big_file --to mys3

copy my_cool_big_file (to mys3...) ok Depois de inicializar um controle remoto especial em um repositório, você pode ativar o mesmo controle remoto especial em outros clones do repositório. Se o controle remoto do mys3 acima foi inicializado no seu laptop, você também deve habilitá-lo na sua área de trabalho.

Para fazer isso, primeiro obtenha o git-annex em sincronia (para que ele saiba sobre o controle remoto especial que foi adicionado no outro repositório) e, em seguida, use git annex enableremote.

desktop$ git annex sync desktop$ export AWS_ACCESS_KEY_ID="somethingotherthanthis" desktop$ export AWS_SECRET_ACCESS_KEY="s3kr1t" desktop$ git annex enableremote mys3 enableremote mys3 (checking bucket) ok E agora você pode baixar arquivos do controle remoto especial:

desktop$ git annex get my_cool_big_file --from mys3 get my_cool_big_file (from mys3...) ok Isso apenas arranhou a superfície do que pode ser feito com controles remotos especiais .

movendo o conteúdo do arquivo entre repositórios Frequentemente, você desejará mover algum conteúdo do arquivo de um repositório para outro. Por exemplo, o disco do seu laptop está ficando cheio; hora de mover alguns arquivos para um disco externo antes de mover outro arquivo de um servidor de arquivos para o laptop. Fazer isso manualmente (usando git annex gete git annex drop) é possível, mas um pouco de dor. git annex move torna muito fácil.

$ git annex move my_cool_big_file --to usbdrive

move my_cool_big_file (to usbdrive...) ok

$ git annex move video/hackity_hack_and_kaxxt.mov --from fileserver

move video/hackity_hack_and_kaxxt.mov (from fileserver...) SHA256-s86050597--6ae2688bc533437766a48aa19f2c06be14d1bab9c70b468af445d4f07b65f41e 100% 82MB 199.1KB/s 07:02 ok quieto por favor: Quando o git-anexo parece pular arquivos Um comportamento do git-anexo às vezes é confuso no começo, mas acaba sendo útil quando você o conhece.

$ git annex drop *

$ Por que o git-annex parecia não fazer nada, apesar de ser solicitado a soltar todos os arquivos? Porque ele verificou todos, e nenhum deles está presente.

A maioria dos comandos git-annex se comportam dessa maneira quando são capazes de verificar rapidamente se nada precisa ser feito sobre um arquivo.

A execução de um comando git-anexo sem especificar nenhum nome de arquivo fará com que o git-anexo procure arquivos no diretório atual e seus subdiretórios. Assim, podemos adicionar todos os novos arquivos ao anexo facilmente:

$ echo hi > subdir/subsubdir/newfile

$ git annex add

add subdir/subsubdir/newfile ok Ao fazer esse tipo de coisa, não é mostrado nada para arquivos nos quais não é necessário agir, pois evita inundar você com a saída. Você vê apenas os arquivos em que precisa atuar.

Lembre-se: se o git-anexo parece não fazer nada quando você pede, não está sendo preguiçoso - verificou-se que nada precisa ser feito para chegar ao estado solicitado!

usando tags e ramificações Como o git, o git-anexo fica preso a todas as versões antigas de um arquivo (por padrão), para que você possa criar tags e ramificações e verificá-las mais tarde para ver os arquivos antigos.

$ git tag 1.0

$ rm -f my_cool_big_file

$ git commit -m deleted

$ git checkout 1.0

$ cat my_cool_big_file

yay! old version still here Obviamente, quando você git checkoutramifica uma versão antiga, algumas versões antigas de arquivos podem não estar disponíveis localmente e podem ser armazenadas em outro repositório. Você pode usá git annex get-los para obtê-los como de costume.

dados não utilizados É possível que os dados se acumulem no anexo para os quais nenhum arquivo em nenhuma ramificação aponta mais. Uma maneira de isso acontecer é se você tiver git rmum arquivo sem chamar primeiro git annex drop. E, quando você modifica um arquivo anexo, o conteúdo antigo do arquivo permanece no anexo. Outra maneira é ao migrar entre back - end de valor-chave .

Podem ser dados históricos que você deseja preservar, portanto, o git-anexo usa como padrão preservá-lo. Portanto, de tempos em tempos, convém verificar esses dados:

$ git annex unused

unused . (checking for unused data...) Some annexed data is no longer used by any files in the repository.

NUMBER KEY 1 SHA256-s86050597--6ae2688bc533437766a48aa19f2c06be14d1bab9c70b468af445d4f07b65f41e 2 SHA1-s14--f1358ec1873d57350e3dc62054dc232bc93c2bd1 (To see where data was previously used, try: git log --stat -S'KEY') (To remove unwanted data: git-annex dropunused NUMBER) ok Após a execução git annex unused, você pode seguir as instruções para examinar o histórico dos arquivos que usaram os dados e, se decidir que não precisa mais desses dados, poderá removê-los facilmente do seu repositório local.

$ git annex dropunused 1

dropunused 1 ok Dica: para descartar muitos dados não utilizados, use um comando como este:

$ git annex dropunused 1-1000

Em vez de remover os dados, você pode enviá-los para outros repositórios:

$ git annex copy --unused --to backup

$ git annex move --unused --to archive

fsck: verificando seus dados Você pode usar o subcomando fsck para verificar problemas nos seus dados. O que pode ser verificado depende do backend de valor-chave usado para os dados. Por exemplo, quando você usa o back-end SHA1, o fsck verifica se as somas de verificação dos seus arquivos estão boas. O Fsck também verifica se a configuração de copias é satisfeita para todos os arquivos.

$ git annex fsck

fsck some_file (checksum...) ok fsck my_cool_big_file (checksum...) ok ... Você também pode especificar os arquivos para verificar. Isso é particularmente útil se você estiver usando sha1 e não quiser gastar muito tempo somando tudo.

$ git annex fsck my_cool_big_file

fsck my_cool_big_file (checksum...) ok Se você tiver um repositório grande, convém verificá-lo em etapas menores. Você pode iniciar e continuar uma verificação abortada ou com tempo limitado.

$ git annex fsck -S --time-limit=1m

fsck some_file (checksum...) ok fsck my_cool_big_file (checksum...) ok

Time limit (1m) reached!

$ git annex fsck -m

fsck my_other_big_file (checksum...) ok ... Use -Sou --incrementalpara iniciar a verificação incremental. Use -m ou --morepara continuar a verificação iniciada e continuar de onde parou. Observe que o salvamento do progresso fscké realizado após cada 1000 arquivos ou 5 minutos ou quando --time-limitocorre. Pode haver arquivos que serão verificados novamente quando git-annexexistir de forma anormal, por exemplo. Ctrl + C e a verificação é reiniciada.

fsck: quando as coisas dão errado

O Fsck nunca exclui dados possivelmente ruins; em vez disso, será movido .git/annex/bad/para você se recuperar. Aqui está uma amostra do que o fsck pode dizer sobre um anexo muito bagunçado:

$ git annex fsck

fsck my_cool_big_file (checksum...) git-annex: Bad file content; moved to .git/annex/bad/SHA1:7da006579dd64330eb2456001fd01948430572f2 git-annex: ** No known copies exist of my_cool_big_file failed fsck important_file git-annex: Only 1 of 2 copies exist. Run git annex get somewhere else to back it up. failed git-annex: 2 failed backups O git-anexo pode ser configurado para exigir que exista mais de uma cópia de um arquivo, como um backup simples para seus dados. Isso é controlado pela configuração de numcopies, cujo padrão é 1 cópia. Vamos mudar isso para exigir 2 cópias e enviar uma cópia de cada arquivo para uma unidade USB.

$ git annex numcopies 2

$ git annex copy . --to usbdrive

Agora, quando tentamos git annex dropum arquivo, ele verifica se conhece outros 2 repositórios que possuem uma cópia antes de remover seu conteúdo do repositório atual.

A configuração de copias usada acima é o padrão global. Você também pode variar o número de cópias necessárias, dependendo do nome do arquivo. Portanto, se você quiser 3 cópias de todos os seus arquivos flac, mas apenas 1 cópia do oggs:

$ echo "*.ogg annex.numcopies=1" >> .gitattributes

$ echo "*.flac annex.numcopies=3" >> .gitattributes

Ou então, você pode criar um diretório para coisas importantes e configurá-lo para fazer backup de tudo o que estiver nele:

$ mkdir important_stuff

$ echo "* annex.numcopies=3" > important_stuff/.gitattributes

Para obter mais detalhes sobre a configuração de numcopies, consulte cópias .

gerenciamento automático de conteúdo Depois de ter vários repositórios e, talvez, ter configurado cópias de números, qualquer arquivo pode ter muito mais cópias do que o necessário, ou talvez menos do que você gostaria. Como gerenciar isso?

O subcomando whereis pode ser usado para ver quantas cópias de um arquivo são conhecidas, mas você precisa decidir o que obter ou soltar. Neste exemplo, talvez não haja cópias suficientes do primeiro arquivo e muitas do segundo arquivo.

$ cd /media/usbdrive

$ git annex whereis

whereis my_cool_big_file (1 copy)

0c443de8-e644-11df-acbf-f7cd7ca6210d -- laptop whereis other_file (3 copies) 0c443de8-e644-11df-acbf-f7cd7ca6210d -- laptop 62b39bbe-4149-11e0-af01-bb89245a1e61 -- usb drive [here] 7570b02e-15e9-11e0-adf0-9f3f94cb2eaa -- backup drive O que seria útil são algumas versões automatizadas de obter e soltar, que só obtêm um arquivo se ainda não houver cópias suficientes ou apenas descartam um arquivo se houver muitas cópias. Bem, eles existem, basta usar a opção --auto.

$ git annex get --auto --numcopies=2

get my_cool_big_file (from laptop...) ok

$ git annex drop --auto --numcopies=2

drop other_file ok Com dois comandos rápidos, o git-anexo foi capaz de decidir por você como trabalhar para ter duas cópias dos seus arquivos.

$ git annex whereis

whereis my_cool_big_file (2 copies)

0c443de8-e644-11df-acbf-f7cd7ca6210d -- laptop 62b39bbe-4149-11e0-af01-bb89245a1e61 -- usb drive [here] whereis other_file (2 copies) 0c443de8-e644-11df-acbf-f7cd7ca6210d -- laptop 7570b02e-15e9-11e0-adf0-9f3f94cb2eaa -- backup drive A opção --auto também pode ser usada com o comando copy; novamente, isso permite ao git-anexo decidir se realmente deseja copiar o conteúdo.

O exemplo acima mostra como usar --auto para gerenciar conteúdo com base no número de cópias. Também é possível configurar, por repositório, qual conteúdo é desejado. Então --auto também leva isso em consideração, veja o conteúdo preferido para obter detalhes.

Mais Então termina o passo a passo. Até agora você deve poder usar o git-anexo.

Quero mais? Veja dicas para obter mais recursos e conselhos.

Links: design / assistente / blog / dia 264, segundo estágio do Windows, devblog completo / dia 360 resultados da pesquisa de usuário de 2015 / comentário 1 5f30c583cd20c33e2bcd386f674d6f3b fórum de controle de versão distribuída / Ajuda na minha base de dados / comentário 1 a35b35c7927640f21d47c3df4f91dabb / Pergunta apenas: git -exex ? / comment 3 0c0dad1ffa11f2f8708906d310a189db forum / O que aconteceu com o passo a passo? forum / git-annex em dois sistemas de arquivos / comment 1 53167648b8b70b41d19ca662a5f3687e fórum / migração para git-annex e rsync como ele funciona na barra lateral ... Última edição