É possível hospedar um repository Git usando o Dropbox, para compartilhar o código?

Eu percebo que existem questões semelhantes , mas a minha pergunta é um pouco diferente: eu estou querendo saber se compartilhar um repository nu através de uma pasta Dropbox sincronizada em vários computadores funcionaria para compartilhar código via Git?

Em outras palavras: o compartilhamento de um repository do Git através do Dropbox é o mesmo que compartilhá-lo de um local centralizado, por exemplo, via SSH ou HTTP?

O repo é atualizado na unidade local de cada pessoa? Isso é o mesmo que compartilhar um repository Git através de uma unidade de rede compartilhada?

Nota: Esta não é uma questão empírica: parece funcionar bem. Eu estou perguntando se a maneira como um repository do Git é estruturado é compatível com essa forma de compartilhamento.

EDIT Para esclarecer / repetir, estou falando de manter o repository Git no Dropbox como um repository simples . Não estou falando em manter os arquivos reais que estão sob controle de origem no Dropbox.

Tenho certeza de que isso não é seguro. Há um monte de partes móveis em um repository Git, e o Dropbox poderia facilmente destruir um deles. Por exemplo, você pode acabar com dicas de ramificação incorretas (master, etc.) no diretório refs ou seu armazenamento de objects pode parar de funcionar se o arquivo objects/info/packs tiver o conteúdo incorreto. Os repositorys Git são bastante simples e robustos, mas não são apenas armazenamento inquebrável.

Acessar repositorys remotos por meio de SSH, git ou HTTP, ou mesmo localmente em um sistema de arquivos de rede, é seguro porque o repository é acessado somente por meio de um processo git , que garante que tudo seja colocado na ordem correta. Mas o Dropbox não faz qualquer tipo de garantia sobre pedidos, então você pode perder dados.

Basta usar um servidor Git (ou qualquer servidor SSH) – se você não tiver um, GitHub , Bitbucket ou GitLab vêm à mente. Isso vai lhe poupar muitos problemas, e não é mais difícil de usar do que um repository local compartilhado através do Dropbox (você só tem URLs SSH em vez de caminhos locais).

Não vejo razão para perder dados – a estrutura do repository do Git é robusta e, no próprio repository, os arquivos com o mesmo nome sempre terão o mesmo conteúdo (isso não se aplica aos nomes das ramificações).

Não vai ser eficiente, no entanto. O protocolo de transferência do Git significa que normalmente só transferirá uma mudança uma vez. Com o Dropbox, se duas pessoas empacotam repositorys ligeiramente diferentes, os pacotes gerados podem conter dados comuns significativos sem serem idênticos, então o DropBox sincronizaria ambos os pacotes, o que é ineficiente.

Você também pode descobrir que, embora os dados estejam todos lá, você acabará com alterações não rastreadas devido a duas cópias com a mesma filial atualizada ao mesmo tempo. Isso pode ser trabalhado, garantindo que você empurre para diferentes ramos de cada cópia, mas seria uma dor.

O que acontece se dois usuários estão desconectados, fazem algum trabalho, enviam para sua cópia local do repository descoberto e depois ficam on-line? Neste caso, quando o Dropbox tentar sincronizar você terá problemas – os arquivos do pacote e as dicas de ramificação serão diferentes e o Dropbox não poderá consertar isso. Esse é o único problema que eu pude ver. Eu acho que a mesma coisa poderia acontecer mesmo se ambos os usuários estivessem conectados, se estivessem empurrando seus repositorys locais ao mesmo tempo.

Eu tive problemas ao usar o Dropbox com o Git e com o Mercurial. Arquivos de repository frequentemente são corrompidos, presumivelmente porque a synchronization do Dropbox não é perfeita, especialmente quando mudanças são feitas em vários lugares. Além disso, o Dropbox funciona em segundo plano, por isso é realmente fácil tentar acidentalmente usar o repository (ou reinicializar sua máquina) enquanto ele estiver no meio de uma operação de synchronization.

Eu amo o Dropbox, mas não é um bom substituto para uma unidade compartilhada ou um repository Git remoto “real”.

Eu costumava fazer isso com o MobileMe, mas os computadores ficavam fora de sincronia. Cada computador teria um repository diferente do da nuvem e, como não há conceito de “mesclagem” no MobileMe (e eu presumo que o DropBox também, certo?), Eu acabaria tendo que escolher uma versão para manter e perder algumas edições ou copiar as edições e reaplicá-las. A vida ficou muito mais fácil desde que eu mudei para um repository central do Git.

Se está funcionando para você até agora, bom. Eu imagino que você vai ter muita dor se dois devs empurrar para seus repositorys locais nus ao mesmo tempo, no entanto. Como o DropBox vai saber o que é certo?

Se eu lhe disser que há casos em que o Dropbox errou meu Git, eu responderia sua pergunta por contradição? Pelo menos na minha experiência, isso aconteceu mais de 5 vezes e há muitas pessoas tendo a mesma experiência por aí.

Mas hoje em dia eu não acredito que o Dropbox seja realmente essencial com o Git, na verdade. Na verdade, você pode definir ramificações remotas (Github, Gitorious, Bitbucket), que podem replace o compartilhamento do Dropbox e os resources de histórico de revisão (não é tudo sobre o Dropbox?) E oferecer ainda mais.

Um problema com o DropBox tem a ver com como eles lidam com backups históricos. Embora você possa reverter um arquivo individual (nos últimos 30 dias ou para sempre, se você tiver o PackRat), não será possível recuperar diretórios inteiros. Isso significa que, se o seu repository for danificado por algum motivo, o incrível serviço de ter um backup histórico é essencialmente inútil, já que você teria que clicar em milhares de arquivos para trazê-los de volta para uma versão anterior.

E depois há os problemas com as condições de corrida, se preferir, mencionados pela maioria das outras respostas.

Acabei de hospedar meu repository no github.com como um repository privado. Sim, você tem que pagar por um plano Micro (US $ 7 / plano), mas você tem a segurança sabendo que você tem um backup do seu código externamente.

    Intereting Posts