Usando Git e Dropbox juntos de forma eficaz?

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

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

A instalação é algo como isto:

~/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í, basta clonar ~/Dropbox/git/project.gitque você associou à sua conta do Dropbox (ou compartilhou este diretório com as pessoas), você pode executar todas as operações normais do Git e elas serão sincronizadas automaticamente com todas as suas outras máquinas.

Eu escrevi uma postagem no blog, No controle de versão , ( link antigo ^desativado ) sobre o meu raciocínio e como eu configuro meu ambiente, é baseado na minha experiência em desenvolvimento Ruby on Rails , mas pode ser aplicado a qualquer coisa, na verdade.

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

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

A causa principal desses problemas é que o cliente da área de trabalho do Dropbox foi projetado para sincronizar arquivos, não repositórios Git. Sem tratamento especial para repositórios Git, ele não mantém as mesmas garantias que o Git. As operações no repositório remoto não são mais atômicas e as operações simultâneas ou o azar infeliz com a sincronização podem resultar em um repositório corrompido.

Os controles remotos tradicionais do Git executam código no lado do servidor para que isso funcione 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 de usar com pastas compartilhadas, para que possa ser usado para colaboração (sim, repositórios privados ilimitados com colaboradores ilimitados!).

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

Essa resposta é baseada na experiência da Mercurial , não no Git, mas essa experiência diz que usar o Dropbox dessa maneira está solicitando repositórios corrompidos, se houver uma chance de você estar atualizando o mesmo repositório baseado no Dropbox de máquinas diferentes em vários momentos (Mac, Unix, Windows no meu caso).

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 possui sua própria noção de caracteres de final de linha e como os caracteres maiúsculos / minúsculos são tratados nos nomes dos arquivos. Dropbox e Git / Mercurial lidam com isso de maneira um pouco diferente (não me lembro das diferenças exatas). Se o Dropbox atualizar o repositório por trás do repositório quebrado, presto e quebrado do Git / Mercurial. Isso acontece de maneira imediata e invisível, então você nem sabe que seu repositório está quebrado até tentar recuperar algo dele.

Depois de desenterrar uma bagunça fazendo as coisas dessa maneira, tenho usado a seguinte receita com grande sucesso e sem sinais de problemas. Simplesmente mova seu repositório 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 repositório. Ambos são gratuitos, portanto, isso não agrega nada aos custos, e cada ferramenta agora se destaca dos seus pontos fortes.

A execução do Git / Mercurial em cima do Dropbox não adiciona nada, exceto riscos. Não faça isso.

Com relação às equipes pequenas que usam o Dropbox:

Se cada desenvolvedor tiver seu próprio repositório 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, poderá solicitar que um desenvolvedor gerencie todos os recursos a partir de seu próprio repositório.

Eu não queria colocar todos os meus projetos em um repositório Git, nem queria executar esse código para cada projeto, então criei um script Bash que automatizará o processo. Você pode usá-lo em um ou vários diretórios - para que ele possa executar o código nesta postagem para você ou em vários projetos ao mesmo tempo.

#!/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<<HELP
projects_to_git.sh -- Takes a project folder and creates a Git repository for it on Dropbox

USAGE:
    ./projects_to_git.sh file1 file2 ..

EXAMPLES:
    ./projects_to_git.sh path/to/MyProjectDir
        Creates a git project called MyProjectDir on Dropbox

    ./projects_to_git.sh path/to/workspace/*
        Creates a git project on Dropbox for every folder contained within the workspace directory, where the project name matches the folder name

HELP
    exit 0
fi

# We have enough parameters, so let's actually do this thing.

START_DIR=$(pwd)

# Make sure we have a connection to Dropbox
cd ~
if [ -s 'Dropbox' ] ; then
    echo "Found Dropbox directory."
    cd Dropbox
    if [ -s 'git' ] ; then
        echo "    Dropbox Git directory found."
    else
        echo "    Dropbox Git directory created."
        mkdir git
    fi
else
    echo "You do not have a Dropbox folder at ~/Dropbox! Install Dropbox. Aborting..."
    exit 0
fi

# Process all directories matching the passed parameters.
echo "Starting processing for all files..."
for PROJ in $*
do
    if [ -d $PROJ ] ; then
        PROJNAME=$(basename $PROJ)
        echo "  Processing $PROJNAME..."

        # Enable Git with this project.
        cd $PROJ
        if [ -s '.git' ] ; then
            echo "    $PROJNAME is already a Git repository, ignoring..."
        else
            echo "    Initializing Git for $PROJNAME..."
            git init -q
            git add .
            git commit -m "Initial creation of project." -q

            # Make the origin Dropbox.

            cd ~/Dropbox/git
            if [ -s $PROJNAME ] ; then
                echo "    Warning! $PROJNAME already exists in Git! Ignoring..."
            else
                echo "    Putting $PROJNAME project on Dropbox..."
                mkdir $PROJNAME
                cd $PROJNAME
                git init -q --bare
            fi

            # Link the project to the origin
            echo "    Copying local $PROJNAME to Dropbox..."
            cd $PROJ
            git remote add origin "~/Dropbox/git/$PROJNAME"
            git push -q origin master
            git branch --set-upstream master origin/master
        fi
    fi
done

echo "Done processing all files."
cd $START_DIR

Eu não acho que usar o Git e o Dropbox seja o caminho a seguir ... Pense nos recursos de ambos:

Git:

• Permite que você tenha um repositório central
• Permite que você tenha seu próprio repositório com suas próprias alterações
• Permite enviar e receber alterações do repositório central
• Permite que várias pessoas alterem os mesmos arquivos e as mescla ou solicita que você as mescle, se não puder fazê-lo
• Possui clientes da Web e da área de trabalho para permitir acesso ao repositório central

Dropbox:

• Mantém tudo em um repositório central
• Permite que você tenha suas próprias versões dos arquivos no servidor
• Força você a enviar e receber alterações do repositório 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, o que é problemático (e definitivamente sua maior desvantagem)
• Possui clientes da Web e da área de trabalho para permitir o acesso ao repositório central.

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

Agora é 2015 e, há três dias, uma nova ferramenta baseada na API do Dropbox v2 foi criada para usar com segurança o git no Dropbox. Funciona contra a API em vez de usar o cliente da área de trabalho e manipula corretamente vários pushs simultâneos para um repositório hospedado em uma pasta compartilhada.

Uma vez configurado, permite configurar um git remote exatamente como qualquer outro git remote.

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 interessante é que o Dropbox NÃO sincroniza todo o contêiner TrueCrypt se você modificar uma pequena parte do seu código. O tempo de sincronização é aproximadamente proporcional à quantidade de alterações. Mesmo criptografada, a combinação de TrueCrypt + Dropbox faz excelente uso da cifra de bloco + da sincronização no nível do 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 repositório .

Cuidado: No entanto, você deve ter muito cuidado para 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 check-in de versões diferentes para o contêiner. Portanto, é prático apenas para uma única pessoa usá-lo para backups, não para uma equipe.

Configuração:

• Criar um contêiner Truecrypt (vários Gigabytes estão corretos)
• Nas preferências do Truecrypt, desmarque preserve modification timestamp*.
• Crie um repositório conforme mencionado acima por Dan ( https://stackoverflow.com/a/1961515/781695 )

Uso:

• Sair do Dropbox
• Monte o contêiner, faça suas alterações, desmonte
• Executar dropbox

PS Desmarque a preserve modification timestampcaixa de seleção informa que o arquivo foi modificado e deve ser sincronizado. Observe que a montagem do contêiner modifica o carimbo de data e hora, mesmo se você não alterar nenhum arquivo nele. Se você não quer que isso aconteça, basta montar o volume comoread-only

Adoro a resposta de Dan McNevin! Também estou usando o Git e o Dropbox juntos agora, e estou usando vários aliases no meu .bash_profile para que meu fluxo de trabalho fique assim:

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

Estes são meus apelidos:

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 repositório vazio no Dropbox) em uma pasta de compartilhamento .

Um pequeno grupo de desenvolvedores pode extrair desse repositório sincronizado e criar um clone local. Depois que a unidade de trabalho estiver concluída, voltamos à origem.

Uma coisa que me falta é uma boa maneira de enviar um email com as informações do conjunto de alterações assim que ocorre um envio para a origem. Estamos usando o Google Wave para acompanhar manualmente as alterações.

Eu tenho usado o Mercurial da maneira recomendada e solicitamos que você seja cauteloso, especialmente se alguma das máquinas diferir. Os fóruns do Dropbox estão cheios de queixas de problemas misteriosos de nomes de arquivos que aparecem espontaneamente. O Hg (e presumo que o Git) não notará ou reclamará durante os check-ins de rotina e você ouvirá apenas sobre a corrupção quando se queixar de um repositório corrompido ao tentar usá-lo de verdade. Más notícias. Gostaria de poder ser mais específico sobre o problema e suas soluções alternativas; Eu ainda estou tentando me livrar dessa bagunça.

Há também um projeto de código aberto (uma coleção de scripts de plataforma cruzada [Linux, Mac, Win]) que faz todos os detalhes minuciosos do gerenciamento de repositório com alguns comandos (3-4).

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ências completas de comandos e tutoriais.

Eu guardo meus repositórios que não são do Github no Dropbox. Uma ressalva que encontrei foi a sincronização após uma reinstalação. O Dropbox baixa primeiro os arquivos menores antes de passar para os maiores. Não é um problema se você começar à noite e voltar depois do fim de semana :-)

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

Agora, em 2014, uso o Git e o Dropbox há cerca de um ano e meio sem problemas. Alguns pontos, porém:

• Todas as minhas máquinas que usam o Dropbox estão no Windows, versões diferentes (7 a 8) + 1 mac.
• Como não compartilho o repositório com outra pessoa, sou o único a modificá-lo.
• git push envia para um repositório remoto, para que, se algum dia for corrompido, eu possa recuperá-lo facilmente.
• Tive que criar aliases no C:\Userscom mklink /D link targetporque algumas bibliotecas foram apontados para locais absolutos.

Gosto da resposta mais votada por Dan McNevin. Acabei fazendo a sequência de 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 repositório git ~/Dropbox/git/sob o nome especificado e enviará todo o conteúdo do diretório atual para a ramificação principal de origem recém-criada. Se mais de um nome de projeto for fornecido, o argumento do nome do 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 filial remota. Os padrões de diretório e arquivo .gitignore são especificados no script.

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 repositório compartilhado, em vez de usar um serviço focado em git como github, bitbucket, etc.

Mas, como a pergunta original não especifica o que realmente significa usar "Git e Dropbox juntos" efetivamente, vamos trabalhar em outra abordagem: "Usando o Dropbox para sincronizar apenas a árvore de trabalho".

O tutorial tem estas etapas:

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

2. desincronize o .gitdiretório no Dropbox. Se estiver usando o aplicativo Dropbox: vá para Preferências, Sincronização e "escolha pastas para sincronizar", onde o .gitdiretório precisa ser desmarcado. Isso removerá o .gitdiretório

3. executado git initno diretório do projeto

Também funciona se o .gitjá existir, apenas execute a etapa 2. O Dropbox manterá uma cópia dos arquivos git no site.

A etapa 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 entre os dispositivos.

• No caso Dropbox parafusos alguma coisa durante a sincronização entre dispositivos, git statuse git diffserá útil 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 da resposta de @ Dan e as preocupações de @clu em outra resposta .

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

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

• Um problema em potencial é ter o Dropbox (desnecessariamente?) Sincronizando potencialmente muitos arquivos quando se verifica diferentes ramificações.

• Se dois ou mais dispositivos sincronizados do Dropbox tiverem ramificações diferentes, as alterações não confirmadas nos dois dispositivos poderão ser perdidas,

Uma maneira de contornar esses problemas é usar git worktreepara manter as caixas registradoras em diretórios separados.

Para meus 2 centavos, o Dropbox só faz sentido para uso pessoal, onde você não quer se preocupar em obter um host de repo central. Para qualquer desenvolvimento profissional, você provavelmente criará mais problemas do que resolverá, como já foi mencionado várias vezes no tópico, o Dropbox não foi projetado para este caso de uso. Dito isso, um método perfeitamente seguro para despejar repositórios no Dropbox sem plugins ou ferramentas de terceiros é usar pacotes. Tenho os seguintes aliases .gitconfigpara 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 <file> <remote name>\"; 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

Eu enfrentei um problema semelhante e criei um pequeno script para o mesmo. A idéia é usar o Dropbox com 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 de disco em nuvem semelhantes, como o SpiderOak com Git.

O objetivo é evitar a sincronização no meio dessas modificações de arquivos, pois ele pode carregar um estado parcial e depois fazer o download novamente, corrompendo completamente o seu estado git.

Para evitar esse problema, eu fiz:

1. Agrupe meu índice git em um arquivo usando git bundle create my_repo.git --all.
2. Defina um atraso para o monitoramento do arquivo, 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. Também ajuda bastante na modificação de arquivos no disco da nuvem on-the-fly (como em aplicativos de anotações para salvar instantaneamente).

Não é perfeito, pois não há garantia de que não irá atrapalhar o estado git novamente, mas ajuda e, no momento, não obtive nenhum problema.

No MacOS, você também pode simplesmente interromper o Dropbox, fazer suas alterações e reiniciar o Dropbox. Estou usando a seguinte combinação e estou muito feliz com ela:

Nos dois (o diretório local do projeto gerenciado pelo git e o repositório remoto do git localizado no Dropbox), execute o seguinte comando para desativar o empacotamento automático (que é o principal problema com a sincronização do dropbox)

git config --global gc.auto 0

De tempos em tempos, comprima os repositórios com o dropbox desativado. Por exemplo, faço o seguinte no meu bash-build-script sempre que faço novos lançamentos dos meus aplicativos.

osascript -e "tell application \"Dropbox\" to quit"

# Compress local
git gc --prune=now; git repack -a -d

# Compress remote
REPOS_DIR_REMOTE=`git remote get-url --push origin`
cd "${REPOS_DIR_REMOTE}"
git gc --prune=now; git repack -a -d

osascript -e "tell application \"Dropbox\" to launch"
osascript -e "display notification with title \"Compress Done\""