Usando Git e Dropbox juntos efetivamente?

Como eu uso o Git e o Dropbox juntos de forma eficaz?

   

Eu acho que o Git no Dropbox é ótimo. Eu uso isso o tempo todo. Eu tenho vários computadores (dois em casa e um no trabalho) que uso o Dropbox como um repository central. Como eu não quero hospedá-lo em um serviço público, e não tenho access a um servidor para o qual eu sempre possa ssh, o Dropbox cuida disso sincronizando (muito rapidamente) em segundo plano.

A instalação é algo assim:

~/project $ git init ~/project $ git add . ~/project $ git commit -m "first commit" ~/project $ cd ~/Dropbox/git ~/Dropbox/git $ git init --bare project.git ~/Dropbox/git $ cd ~/project ~/project $ git remote add origin ~/Dropbox/git/project.git ~/project $ git push -u origin master 

A partir daí, você pode simplesmente clonar ~/Dropbox/git/project.git que você associou à sua conta do Dropbox (ou compartilhou este diretório com as pessoas), você pode fazer todas as operações normais do Git e elas serão sincronizadas com todas as suas outras máquinas automaticamente.

Eu escrevi um post no blog, On Version Control , ( link antigo morto ) no meu raciocínio e como eu configurei o meu ambiente, é baseado na minha experiência de desenvolvimento Ruby on Rails , mas pode ser aplicado a qualquer coisa, na verdade.

A maneira certa de fazer isso é usar o git-remote-dropbox: https://github.com/anishathalye/git-remote-dropbox

Criar seu próprio repository nu no Dropbox causa muitos problemas. Anish (o criador da biblioteca) explica melhor :

A causa raiz desses problemas é que o cliente de desktop Dropbox foi projetado para sincronizar arquivos, não repositorys Git. Sem tratamento especial para repositorys Git, ele não mantém as mesmas garantias que o Git. Operações no repository remoto não são mais atômicas, e operações simultâneas ou synchronization de azar com synchronization podem resultar em um repository corrompido.

O Git tradicional envia um código de execução no lado do servidor para fazer isso funcionar corretamente, mas não podemos fazer isso.

Solução: é possível resolver isso corretamente. É possível usar o Git com o Dropbox e ter as mesmas garantias de segurança e consistência que um controle remoto tradicional do Git, mesmo quando há vários usuários e operações simultâneas!

Para um usuário, é tão simples quanto usar o git-remote-dropbox, um auxiliar remoto do Git que atua como uma ponte bidirecional transparente entre o Git e o Dropbox e mantém todas as garantias de um controle remoto tradicional do Git. É até seguro usar pastas compartilhadas, por isso pode ser usado para colaboração (e repos privados ilimitados com colaboradores ilimitados!).

Com o auxiliar remoto, é possível usar o Dropbox como um controle remoto do Git e continuar usando todos os comandos regulares do Git, como git clone, git pull e git push, e tudo funcionará como esperado.

Esta resposta é baseada na experiência do Mercurial , não no Git, mas esta experiência diz que usar o Dropbox desta forma é pedir repositorys corruptos se houver uma chance de você estar atualizando o mesmo repository baseado em Dropbox de máquinas diferentes em vários momentos (Mac, Unix, Windows no meu caso).

Eu não tenho uma lista completa das coisas que podem dar errado, mas aqui está um exemplo específico que me mordeu. Cada máquina tem sua própria noção de caracteres de final de linha e como os caracteres maiúsculos / minúsculos são manipulados nos nomes de arquivos. O Dropbox e o Git / Mercurial lidam com isso de forma ligeiramente diferente (não me lembro das diferenças exatas). Se o Dropbox atualiza o repository atrás do repository anterior, pronto, quebrado do Git / Mercurial. Isso acontece imediatamente e de forma invisível, então você nem sabe que seu repository está quebrado até que você tente recuperar alguma coisa dele.

Depois de cavar uma bagunça fazendo as coisas dessa maneira, eu tenho usado a seguinte receita com grande sucesso e sem nenhum sinal de problemas. Basta mover o seu repository para fora do Dropbox. Use o Dropbox para todo o resto; documentação, arquivos JAR , qualquer coisa que você queira. E use o GitHub (Git) ou o Bitbucket (Mercurial) para gerenciar o próprio repository. Ambos são gratuitos, o que não acrescenta nada aos custos, e cada ferramenta agora joga com seus pontos fortes.

Executar o Git / Mercurial no topo do Dropbox não acrescenta nada além de risco. Não faça isso.

Com relação a equipes pequenas usando o Dropbox:

Se cada desenvolvedor tiver seu próprio repository simples gravável no Dropbox, que é puxado apenas para outros desenvolvedores, isso facilita o compartilhamento de código sem risco de corrupção!

Então, se você quiser uma ‘linha principal’ centralizada, você pode fazer com que um desenvolvedor gerencie todos os empurrões para ela a partir de seu próprio repository.

Eu não queria colocar todos os meus projetos em um repository Git, nem queria entrar e rodar este código para cada projeto, então eu fiz um script Bash que irá automatizar o processo. Você pode usá-lo em um ou vários diretórios – para que ele possa fazer o código neste post para você ou pode fazê-lo em vários projetos de uma só vez.

 #!/bin/sh # Script by Eli Delventhal # Creates Git projects for file folders by making the origin Dropbox. You will need to install Dropbox for this to work. # Not enough parameters, show help. if [ $# -lt 1 ] ; then cat<  

Eu não acho que usar o Git e o Dropbox é o caminho a percorrer … Basta pensar sobre os resources de ambos:

Git:

  • Permite que você tenha um repository central
  • Permite que você tenha seu próprio repository com suas próprias alterações
  • Permite que você envie e receba alterações do repository central
  • Permite que várias pessoas alterem os mesmos arquivos e eles os mesclam ou pedem para mesclá-los se não puder
  • Tem clientes web e desktop para permitir access ao repository central

Dropbox:

  • Mantém tudo em um repository central
  • Permite que você tenha suas próprias versões dos arquivos no servidor
  • Obriga você a enviar e receber alterações do repository central
  • Se várias pessoas alterarem os mesmos arquivos, o primeiro arquivo confirmado será substituído por confirmações posteriores e não ocorrerá nenhuma mesclagem que seja problemática (e definitivamente sua maior desvantagem)
  • Tem clientes web e desktop para permitir access ao repository central.

E se você está preocupado em compartilhar alguns dos seus arquivos, por que não criptografá-los? E então você pode obter a maior vantagem do Dropbox para o Git, ou seja, ter arquivos públicos e privados …

Agora é 2015, e a partir de três dias atrás, uma nova ferramenta baseada na Dropbox API v2 foi criada para usar com segurança o git no Dropbox. Ele funciona na API, em vez de usar o cliente de desktop, e lida corretamente com vários pushes simultâneos em um repository hospedado em uma pasta compartilhada.

Uma vez configurado, ele permite configurar um controle remoto como qualquer outro controle remoto do git.

 git clone "dropbox::/path/to/repo" git remote add origin "dropbox::/path/to/repo" 

Eu uso o Mercurial (ou Git) + TrueCrypt + Dropbox para backups remotos criptografados .

O mais legal é que o Dropbox NÃO sincroniza todo o contêiner TrueCrypt se você modificar uma pequena parte do seu código. O tempo de synchronization é aproximadamente proporcional à quantidade de alterações. Mesmo que seja criptografado, a combinação de TrueCrypt + Dropbox faz um excelente uso de cifra de bloco + synchronization de nível de bloco.

Em segundo lugar, um contêiner criptografado monolítico não apenas adiciona segurança, mas também reduz as chances de corrupção do repository.

Cuidado: No entanto, você deve ter muito cuidado ao não ter o contêiner montado enquanto o Dropbox estiver em execução. Também pode ser difícil resolver conflitos se dois clientes diferentes fizerem o check-in de diferentes versões para o contêiner. Portanto, é prático apenas para uma única pessoa usá-lo para backups, não para uma equipe.

Configuração:

  • Crie um contêiner Truecrypt (vários Gigabytes estão bem)
  • Em Preferências do Truecrypt, desmarque preserve modification timestamp *.
  • Crie um repo como mencionado acima por Dan ( https://stackoverflow.com/a/1961515/781695 )

Uso:

  • Saia do Dropbox
  • Montar o container, empurrar suas alterações, desmontar
  • Executar dropbox

PS Desmarcar o preserve modification timestamp informa à checkbox de depósito que o arquivo foi modificado e deve ser sincronizado. Observe que a assembly do contêiner modifica o registro de data e hora, mesmo se você não alterar nenhum arquivo. Se você não quiser que isso aconteça, basta montar o volume como read-only

Eu tenho usado o Mercurial da maneira recomendada e recomendo que você seja cauteloso, especialmente se qualquer uma das máquinas for diferente. Os fóruns do Dropbox estão cheios de reclamações sobre problemas misteriosos com nomes de arquivos que aparecem espontaneamente. Hg (e eu presumo Git) não vai notar ou reclamar durante checkins de rotina e você só vai ouvir sobre a corrupção quando se queixa de um repository corrupto quando você tenta usá-lo para valer. Más notícias. Gostaria de poder ser mais específico sobre o problema e suas soluções alternativas; Eu ainda estou tentando sair dessa bagunça.

Eu amo a resposta de Dan McNevin! Estou usando o Git e o Dropbox juntos também agora, e estou usando vários aliases no meu .bash_profile, então meu stream de trabalho é assim:

 ~/project $ git init ~/project $ git add . ~/project $ gcam "first commit" ~/project $ git-dropbox 

Estes são meus aliases:

 alias gcam='git commit -a -m' alias gpom='git push origin master' alias gra='git remote add origin' alias git-dropbox='TMPGP=~/Dropbox/git/$(pwd | awk -F/ '\''{print $NF}'\'').git;mkdir -p $TMPGP && (cd $TMPGP; git init --bare) && gra $TMPGP && gpom' 

Usamos esse método (criando um repository vazio no Dropbox) em uma pasta compartilhada .

Um pequeno grupo de desenvolvedores pode extrair esse repository sincronizado e criar um clone local. Uma vez que a unidade de trabalho é feita, nós empurramos de volta para a origem.

Uma coisa que estou perdendo é uma boa maneira de enviar um e-mail com as informações do conjunto de mudanças, uma vez que um envio para origem ocorre. Estamos usando o Google Wave para acompanhar manualmente as alterações.

Há também um projeto de código aberto (uma coleção de scripts multiplataforma [Linux, Mac, Win]) que faz todos os detalhes básicos do gerenciamento de repository com um punhado (3-4) de comandos.

https://github.com/karalabe/gitbox/wiki

O uso da amostra é:

 $ gitbox create myapp Creating empty repository... Initializing new repository... Repository successfully created. $ gitbox clone myapp Cloning repository... Repository successfully cloned. 

Após o qual o uso normal do git:

 $ echo “Some change” > somefile.txt $ git add somefile.txt $ git commit –m “Created some file” $ git push 

Verifique o wiki do projeto e os manuais para obter referência completa de comandos e tutoriais.

Eu armazeno meu repository não-Github no Dropbox. Uma ressalva que eu encontrei foi a synchronization após a reinstalação. O Dropbox baixará os arquivos menores antes de passar para os maiores. Não é um problema se você começar a noite e voltar depois do fim de semana 🙂

Meu tópico – http://forums.dropbox.com/topic.php?id=29984&replies=6

Eu gosto da resposta votada por Dan McNevin. Acabei fazendo a sequência dos comandos git muitas vezes e decidi fazer um script. Então aqui está:

 #!/bin/bash # Usage usage() { echo "Usage: ${0} -m [ master-branch-directory ] -r [ remote-branch-directory ] [ project-name ]" exit 1 } # Defaults defaults() { masterdir="${HOME}/Dropbox/git" remotedir="${PWD}" gitignorefile="# OS generated files #\n\n.DS_Store\n.DS_Store?\n.Spotlight-V100\n.Trashes\nehthumbs.db\nThumbs.db" } # Check if no arguments if [ ${#} -eq 0 ] ; then echo "Error: No arguments specified" usage fi #Set defaults defaults # Parse arguments while [ ${#} -ge 1 ]; do case "${1}" in '-h' | '--help' ) usage ;; '-m' ) shift masterdir="${1}" ;; '-r' ) shift remotedir="${1}" ;; * ) projectname="${1##*/}" projectname="${projectname%.git}.git" ;; esac shift done # check if specified directories and project name exists if [ -z "${projectname}" ]; then echo "Error: Project name not specified" usage fi if [ ! -d "${remotedir}" ]; then echo "Error: Remote directory ${remotedir} does not exist" usage fi if [ ! -d "${masterdir}" ]; then echo "Error: Master directory ${masterdir} does not exist" usage fi #absolute paths remotedir="`( cd \"${remotedir}\" && pwd )`" masterdir="`( cd \"${masterdir}\" && pwd )`" #Make master git repository cd "${masterdir}" git init --bare "${projectname}" #make local repository and push to master cd "${remotedir}" echo -e "${gitignorefile}" > .gitignore # default .gitignore file git init git add . git commit -m "first commit" git remote add origin "${masterdir}/${projectname}" git push -u origin master #done echo "----- Locations -----" echo "Remote branch location: ${remotedir}" echo "Master branch location: ${masterdir}" echo "Project Name: ${projectname}" 

O script requer apenas um nome de projeto. Ele irá gerar um repository git em ~/Dropbox/git/ sob o nome especificado e enviará todo o conteúdo do diretório atual para a ramificação mestre de origem recém-criada. Se mais de um nome de projeto for fornecido, o argumento de nome de projeto mais à direita será usado.

Opcionalmente, o argumento do comando -r especifica a ramificação remota que enviará ao mestre de origem. A localização do mestre de origem do projeto também pode ser especificada com o argumento -m. Um arquivo .gitignore padrão também é colocado no diretório de ramificação remota. O diretório e os padrões do arquivo .gitignore são especificados no script.

Agora, em 2014, tenho usado o Git e o Dropbox há cerca de um ano e meio sem problemas. Alguns pontos embora:

  • Todas as minhas máquinas usando o Dropbox estão no Windows, versões diferentes (7 a 8) + 1 mac.
  • Eu não compartilho o repository com outra pessoa, então sou o único a modificá-lo.
  • git push envia para um repository remoto, de modo que se ele for corrompido, eu posso recuperá-lo facilmente.
  • Eu tive que criar aliases em C:\Users com mklink /D link target porque algumas bibliotecas foram apontadas para locais absolutos.

Eu enfrentei um problema semelhante e criei um pequeno script para o mesmo. A ideia é usar o Dropbox com o Git da maneira mais simples possível. Atualmente, implementei rapidamente o código Ruby , e em breve adicionarei mais.

O script está acessível em https://github.com/nuttylabs/box-git .

Sem usar ferramentas de integração de terceiros, eu poderia melhorar um pouco a condição e usar o DropBox e outros serviços similares de disco na nuvem, como o SpiderOak com o Git.

O objective é evitar a synchronization no meio das modificações desses arquivos, pois ele pode fazer upload de um estado parcial e, em seguida, fazer o download de volta, corrompendo completamente o estado do seu git.

Para evitar esse problema, eu fiz:

  1. Empacote meu índice git em um arquivo usando git bundle create my_repo.git --all .
  2. Defina um atraso para o monitoramento de arquivos, por exemplo, 5 minutos, em vez de instantâneo. Isso reduz as chances de o DropBox sincronizar um estado parcial no meio de uma alteração. Ele também ajuda muito ao modificar arquivos no disco em nuvem on-the-fly (como com aplicativos de annotations instantâneas de poupança).

Não é perfeito, pois não há garantia de que ele não vai atrapalhar o estado do git novamente, mas ajuda e, no momento, eu não recebi nenhum problema.

Outra abordagem:

Todas as respostas até agora, incluindo a resposta @Dan, que é a mais popular, abordam a ideia de usar o Dropbox para centralizar um repository compartilhado em vez de usar um serviço focado no git como o github, o bitbucket, etc.

Mas, como a pergunta original não especifica o que usar “Git e Dropbox juntos efetivamente” realmente significa, vamos trabalhar em outra abordagem: “Usando o Dropbox para sincronizar apenas o worktree”.

O how-to tem estas etapas:

  1. dentro do diretório do projeto, cria-se um diretório .git vazio (por exemplo, mkdir -p myproject/.git )

  2. des-sincronize o diretório .git no Dropbox. Se estiver usando o aplicativo Dropbox: vá para Preferências, Sincronizar e “escolha pastas para sincronizar”, onde o diretório .git precisa ser desmarcado. Isso removerá o diretório .git .

  3. execute git init no diretório do projeto

Ele também funciona se o .git já existir, e somente o passo 2. O Dropbox manterá uma cópia dos arquivos git no site.

O Passo 2 fará com que o Dropbox não sincronize a estrutura do sistema git, que é o resultado desejado para essa abordagem.

Por que alguém usaria essa abordagem?

  • As alterações ainda não enviadas terão um backup do Dropbox e serão sincronizadas em todos os dispositivos.

  • Caso o Dropbox atrapalhe a synchronization entre os dispositivos, o git status git diff e o git diff serão úteis para resolver as coisas.

  • Economiza espaço na conta do Dropbox (todo o histórico não será armazenado lá)

  • Evita as preocupações levantadas por @dubek e @Ates nos comentários sobre a resposta de @Dan e as preocupações de @clu em outra resposta .

A existência de um remoto em outro lugar (github, etc.) funcionará bem com essa abordagem.

Trabalhar em diferentes ramos traz alguns problemas que precisam ser atendidos:

  • Um problema em potencial é fazer com que o Dropbox (desnecessariamente?) Sincronize potencialmente muitos arquivos quando um deles faz check-out de diferentes ramificações.

  • Se dois ou mais dispositivos sincronizados do Dropbox tiverem ramificações diferentes verificadas, alterações não confirmadas em ambos os dispositivos podem ser perdidas,

Uma maneira de contornar esses problemas é usar o git worktree para manter os checkouts de filiais em diretórios separados.

Para os meus 2 centavos, o Dropbox só faz sentido para uso pessoal, onde você não quer se preocupar em obter um host de recompra central. Para qualquer desenvolvimento profissional, você provavelmente criará mais problemas do que os que você vai resolver, como já foi mencionado várias vezes no segmento, o Dropbox não foi projetado para este caso de uso. Dito isso, um método perfeitamente seguro para despejar repositorys no Dropbox sem qualquer plug-in ou ferramenta de terceiros é usar pacotes configuráveis. Eu tenho os seguintes apelidos no meu .gitconfig para salvar a digitação:

 [alias] bundle-push = "!cd \"${GIT_PREFIX:-.}\" && if path=\"$(git config remote.\"$1\".url)\" && [ \"${path:0:1}\" = / ]; then git bundle create \"$path\" --all && git fetch \"$1\"; else echo \"Not a bundle remote\"; exit 1; fi #" bundle-fetch = "!cd \"${GIT_PREFIX:-.}\" && if path=\"$(git config remote.\"$1\".url)\" && [ \"${path:0:1}\" = / ]; then git bundle verify \"$path\" && git fetch \"$1\"; else echo \"Not a bundle remote\"; exit 1; fi #" bundle-new = "!cd \"${GIT_PREFIX:-.}\" && if [ -z \"${1:-}\" -o -z \"${2:-}\" ]; then echo \"Usage: git bundle-new  \"; exit 1; elif [ -e \"$2\" ]; then echo \"File exist\"; exit 1; else git bundle create \"$2\" --all && git remote add -f \"$1\" \"$(realpath \"$2\")\"; fi #" 

Exemplo:

 # Create bundle remote (in local repo) $ git bundle-new dropbox ~/Dropbox/my-repo.bundle # Fetch updates from dropbox $ git bundle-fetch dropbox # NOTE: writes over previous bundle. Thus, roughly equivalent to push --force --prune --all $ git bundle-push