¿Usando Git y Dropbox juntos de manera efectiva?

1133

¿Cómo uso Git y Dropbox juntos de manera efectiva?

n1kh1lp
fuente
2
Ver también el tutorial de Bradley Wright .
Ron Romero
39
Si solo eres un equipo pequeño (hasta 5, creo), BitBucket proporciona alojamiento gratuito para repositorios privados. Irónicamente, tengo mi repositorio local en DropBox, en caso de que me mueva entre las computadoras cuando estoy trabajando en algo.
Mark Adamson
12
No estoy seguro de que su redundancia de versiones sea irónica, pero probablemente sea bastante útil
Silasdavis
2
Esta pregunta no está clara. ¿Qué significa usar estas herramientas juntas "efectivamente"? También es demasiado amplio y es probable que genere respuestas obstinadas.
3
Oye, ¿podrías considerar mi respuesta como la correcta? Stackoverflow.com/a/32215708/589667 . Esta biblioteca que menciono en mi respuesta es una herramienta oficial creada por los desarrolladores de Dropbox para ayudar a las personas a usar Git con Dropbox.
clu

Respuestas:

1401

Creo que Git en Dropbox es genial. Lo uso todo el tiempo. Tengo varias computadoras (dos en casa y una en el trabajo) que utilizo Dropbox como repositorio central. Como no quiero alojarlo en un servicio público y no tengo acceso a un servidor al que siempre pueda enviar mensajes, Dropbox se encarga de esto sincronizándolo (muy rápidamente) en segundo plano.

La configuración es algo como esto:

~/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 de ahí, puede simplemente clonar ~/Dropbox/git/project.gitque ha asociado con su cuenta de Dropbox (o ha compartido este directorio con personas), puede hacer todas las operaciones normales de Git y se sincronizarán con todas sus otras máquinas automáticamente.

Escribí una publicación de blog, En el Control de versiones , ( viejo enlace muerto ) sobre mi razonamiento y cómo configuré mi entorno, se basa en mi experiencia de desarrollo de Ruby on Rails , pero realmente se puede aplicar a cualquier cosa.

Dan McNevin
fuente
61
Me pregunto qué pasará si empujas al repositorio desnudo de Dropbox desde dos máquinas al mismo tiempo. Si causa una modificación en uno de los archivos internos de git, Dropbox te mostrará que hay un conflicto, pero ¿qué haces entonces? ¿Solo elige una de las versiones y luego vuelve a presionar desde ambas máquinas (una por una)?
dubek
162
@dubek: Probablemente terminarás corrompiendo el repositorio compartido. Este enfoque solo es adecuado para un equipo pequeño (dos en mi caso) donde la gente puede gritar sobre las paredes de sus cubículos: "¡Hey! ¡Nadie empuje! ¡Estoy empujando ahora!
Ates Goral
50
@Ates: al menos git está descentralizado, por lo que si logras corromper las cosas, puedes restaurarlo desde la copia local de alguien. Si tiene un gran equipo, es probable que haya suficiente efectivo para un repositorio alojado en alguna parte.
rdrey
75
Regresé a esta página más de cinco veces para usar esta secuencia exacta de comandos. Nunca los memorizaré, pero gracias por proporcionarlos.
Jeremy Mack
32
@ Jo: No es suficiente gueto.
Ates Goral
128

La forma correcta de hacerlo es usar git-remote-dropbox: https://github.com/anishathalye/git-remote-dropbox

Crear su propio repositorio desnudo en Dropbox causa muchos problemas. Anish (el creador de la biblioteca) lo explica mejor :

La causa raíz de estos problemas es que el cliente de escritorio de Dropbox está diseñado para sincronizar archivos, no repositorios de Git. Sin un manejo especial para los repositorios de Git, no mantiene las mismas garantías que Git. Las operaciones en el repositorio remoto ya no son atómicas, y las operaciones concurrentes o el tiempo desafortunado con sincronización pueden resultar en un repositorio dañado.

Los controles remotos Git tradicionales ejecutan código en el lado del servidor para que esto funcione correctamente, pero no podemos hacer eso.

Solución: es posible resolver esto correctamente. ¡Es posible usar Git con Dropbox y tener las mismas garantías de seguridad y consistencia que un control remoto tradicional de Git, incluso cuando hay múltiples usuarios y operaciones simultáneas!

Para un usuario, es tan simple como usar git-remote-dropbox, un ayudante remoto de Git que actúa como un puente bidireccional transparente entre Git y Dropbox y mantiene todas las garantías de un control remoto tradicional de Git. Incluso es seguro de usar con carpetas compartidas, por lo que se puede usar para la colaboración (yay repositorios privados ilimitados con colaboradores ilimitados!

Con el ayudante remoto, es posible usar Dropbox como un control remoto Git y continuar usando todos los comandos Git regulares como git clone, git pull y git push, y todo funcionará como se esperaba.

clu
fuente
8
Me alegra ver que alguien publicó sobre git-remote-dropbox en esta pregunta de StackOverflow. Me pregunto si hay alguna forma de acercar esta respuesta a la cima. El método recomendado por la respuesta aceptada actual es bastante peligroso y puede provocar la corrupción del repositorio.
fwenom
1
eso es realmente genial. Definitivamente le echaré un vistazo. pero cuando me muevo de un cuadro de desarrollo a otro, y quiero seguir trabajando en un repositorio sincronizado, este método solo funcionará si siempre comprometo mi trabajo cuando salgo de la máquina A, y quiero continuar donde lo dejé en máquina B. ¿tengo razón? si es así, esto no es ideal, ya que conduciría a una serie de compromisos "provisionales", lo que se podría argumentar que contaminará el historial de compromisos del repositorio. ¡Quizás no puedo tener mi pastel y comerlo también!
bhu Boue vidya
1
@bhuBouevidya No, eso no es cierto. No necesita comprometer su trabajo para que los cambios estén sincronizados. Mientras se guarden los archivos, los archivos se sincronizarán. Básicamente, si tiene un montón de archivos modificados en una máquina, las modificaciones se sincronizarán con la otra porque Dropbox solo se preocupa por lo que se ha guardado en el disco.
clu
2
@clu: Sí, debes comprometer tu trabajo y empujar. Todo lo que hace git-remote-dropbox es actuar como un ayudante remoto de git. Al igual que otros controles remotos, sus confirmaciones locales no se enviarán al control remoto hasta que se realice un envío. La forma de obtener archivos modificados localmente en el repositorio local para que puedan enviarse es mediante una confirmación. Dropbox no sabrá nada acerca de sus archivos que no están en el repositorio.
Hormigas
2
Es curioso si git-remote-dropbox es multiplataforma ... Veo que usa python, y sé que otras cosas de Python para Dropbox no son multiplataforma, por ejemplo, en OS X, las cosas de la línea de comandos no son compatibles.
Michael
89

Esta respuesta se basa en la experiencia de Mercurial , no en Git, pero esta experiencia dice que usar Dropbox de esta manera es pedir repositorios corruptos si existe la posibilidad de que actualices el mismo repositorio basado en Dropbox desde diferentes máquinas en varias ocasiones (Mac, Unix, Windows en mi caso).

No tengo una lista completa de las cosas que pueden salir mal, pero aquí hay un ejemplo específico que me mordió. Cada máquina tiene su propia noción de caracteres de final de línea y cómo se manejan los caracteres en mayúscula / minúscula en los nombres de archivo. Dropbox y Git / Mercurial manejan esto de manera ligeramente diferente (no recuerdo las diferencias exactas). Si Dropbox actualiza el repositorio detrás de Git / Mercurial, presto, repositorio roto. Esto sucede de forma inmediata e invisible, por lo que ni siquiera sabe que su repositorio está roto hasta que intenta recuperar algo de él.

Después de desenterrar un desastre haciendo las cosas de esta manera, he estado usando la siguiente receta con gran éxito y sin signos de problemas. Simplemente mueva su repositorio fuera de Dropbox. Usa Dropbox para todo lo demás; documentación, archivos JAR , cualquier cosa que desee. Y use GitHub (Git) o Bitbucket (Mercurial) para administrar el repositorio en sí. Ambos son gratuitos, por lo que esto no agrega nada a los costos, y cada herramienta ahora aprovecha sus puntos fuertes.

Ejecutar Git / Mercurial encima de Dropbox no agrega nada, excepto el riesgo. No lo hagas

Bradjcox
fuente
13
Siento que el repositorio git es lo suficientemente robusto como para no corromperse. Mi experiencia (más de un año de uso, principalmente para un solo usuario, multiplataforma, multiplataforma, múltiples desarrolladores) es que el repositorio de git no se corrompe fácilmente. En git, solo se agrega información al repositorio, los archivos existentes se dejan solos el 99.9% del tiempo (los archivos mutables son en su mayoría fáciles de inspeccionar manualmente). A veces he visto casos en los que se sobrescribió un puntero de rama, pero esto puede verse fácilmente (es decir, "rama (copia en conflicto de XXX)") y eliminarse (en realidad, no se necesita una reparación real).
Egon
1
@tc: Tienes razón, durante la recolección de basura, la información no accesible se elimina en git. Sin embargo, supongo que para la mayoría de los casos prácticos, esto no daña la robustez: solo se ve afectada la información inalcanzable de más de 2 semanas (que es tiempo suficiente para que DropBox se sincronice). Y en ese momento de tal conflicto, sospecho que la mayoría de la información estará disponible tanto en forma empaquetada como sin empaquetar.
Egon
Creo que el escenario de intercambio de código sin repositorio central (descrito en una respuesta a continuación) salvaría a uno de posibles corrupciones debido a las actualizaciones concurrentes al directorio en Dropbox. Si se necesita un repositorio central, se podría administrar por separado (y fuera de Dropbox); Dropbox mantendría repositorios de trabajo personales (lo cual también es conveniente porque podría actualizar / extraer de vez en cuando del repositorio fuente de otra persona en su equipo en el que basó su trabajo). (De hecho, estoy contemplando el uso de darcs en este entorno).
imz - Ivan Zakharyaschev
55
+1 Si no desea alojar sus repositorios en público, use Bitbucket , los repositorios privados son gratuitos para equipos de hasta 5 usuarios.
Christian Specht
Una cosa que he notado entre una máquina Windows y una máquina OSX es que los permisos de archivos pueden causar problemas de diferencias. Puede desactivar los permisos en Git usando: "git config core.fileMode false"
devdrc
16

Con respecto a los equipos pequeños que usan Dropbox:

Si cada desarrollador tiene su propio repositorio desnudo de escritura en Dropbox, que se extrae solo para otros desarrolladores, entonces esto facilita el intercambio de código sin riesgo de corrupción.

Luego, si desea una 'línea principal' centralizada, puede hacer que un desarrollador administre todos los impulsos desde su propio repositorio.

teh_senaus
fuente
1
¡Genial tanto! Además, para proteger la corrupción del repositorio de múltiples escrituras, ¡podría hacer MÚLTIPLES repositorios y sincronizar solo sus carpetas .git! ¡Todo lo que necesita en un momento es extraer del origen deseado! ¡Gran hombre P-to-P! ¡Entiendes la filosofía descentralizada de git!
Brian Haak
16

No quería poner todos mis proyectos en un solo repositorio de Git, ni quería entrar y ejecutar este código para cada proyecto, así que hice un script Bash que automatizará el proceso. Puede usarlo en uno o en varios directorios, por lo que puede hacer el código en esta publicación por usted o puede hacerlo en varios proyectos a la 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<<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
Eli
fuente
15

No creo que usar Git y Dropbox sea el camino a seguir ... Solo piense en las características de ambos:

Git:

  • Te permite tener un repositorio central
  • Le permite tener su propio repositorio con sus propios cambios.
  • Le permite enviar y recibir cambios desde el repositorio central
  • Permite que varias personas cambien los mismos archivos y los fusiona o le pide que los fusione si no puede hacerlo
  • Tiene clientes web y de escritorio para permitir el acceso al repositorio central

Dropbox:

  • Mantiene todo en un repositorio central
  • Le permite tener sus propias versiones de los archivos en el servidor
  • Obliga a enviar y recibir cambios desde el repositorio central
  • Si varias personas cambian los mismos archivos, el primer archivo confirmado se reemplaza con confirmaciones posteriores, y no se produce la fusión, lo cual es problemático (y definitivamente su mayor desventaja)
  • Tiene clientes web y de escritorio para permitir el acceso al repositorio central.

Y si le preocupa compartir algunos de sus archivos, ¿por qué no cifrarlos? Y luego podría obtener la mayor ventaja de Dropbox to Git, es decir, tener archivos públicos y privados ...

Coyote21
fuente
Dropbox es solo una buena opción para un repositorio central. Si se coloca en una carpeta compartida , incluso funciona para grupos.
mac
1
Sí, pero no tendrá las mismas funciones de fusión que en git, de hecho, si alguien está editando el mismo archivo que el suyo y él guarda el archivo después de usted, sus cambios se perderán, a menos que vaya a la interfaz web y descargue La versión anterior (su versión).
Coyote21
8
Esto está mal. Dropbox no elimina conflictos. Manipula el nombre de archivo de una edición y usa el otro para la continuidad. Puede fusionarlos manualmente si lo desea. Es un buen compromiso y no pierde datos. dropbox.com/help/36
Clueless
66
Sí, pero dado que se trata de código, cuanto menos tiempo pase fusionando archivos, más código puedo producir, y en una base de código normal puede haber cientos de conflictos a la vez, dependiendo de las dimensiones del proyecto, y sería una pesadilla combinar luego uno por uno, incluso con la ayuda de una herramienta de combinación como WinMerge (o algo similar).
Coyote21
15

Ahora es 2015, y desde hace tres días, se creó una nueva herramienta basada en Dropbox API v2 para usar git de forma segura en Dropbox. Funciona en contra de la API en lugar de usar el cliente de escritorio, y maneja correctamente múltiples empujes simultáneos a un repositorio alojado en una carpeta compartida.

Una vez configurado, permite configurar un control remoto git exactamente como cualquier otro control remoto git.

git clone "dropbox::/path/to/repo"
git remote add origin "dropbox::/path/to/repo"
merlin2011
fuente
2
Sería bueno si algún mod fusionara todas las preguntas de git-with-dropbox en stackexchange bajo un superthread que menciona primero las últimas cosas.
Blair Houghton
9

Uso Mercurial (o Git) + TrueCrypt + Dropbox para copias de seguridad remotas cifradas .

Lo mejor es que Dropbox NO sincroniza todo el contenedor TrueCrypt si modifica una pequeña porción de su código. El tiempo de sincronización es aproximadamente proporcional a la cantidad de cambios. Aunque está encriptado, la combinación de TrueCrypt + Dropbox hace un excelente uso de cifrado de bloque + sincronización de nivel de bloque.

En segundo lugar, un contenedor encriptado monolítico no solo agrega seguridad, sino que también reduce las posibilidades de corrupción del repositorio .

Precaución: Sin embargo, debe tener mucho cuidado de no tener el contenedor montado mientras se ejecuta Dropbox. También puede ser un problema resolver conflictos si 2 clientes diferentes registran versiones diferentes en el contenedor. Por lo tanto, es práctico solo para una sola persona que lo usa para copias de seguridad, no para un equipo.

Preparar:

  • Cree un contenedor Truecrypt (varios Gigabytes están bien)
  • En las preferencias de Truecrypt, desmarque preserve modification timestamp*.
  • Cree un repositorio como se menciona anteriormente por Dan ( https://stackoverflow.com/a/1961515/781695 )

Uso:

  • Salir de Dropbox
  • Monta el contenedor, empuja tus cambios, desmonta
  • Ejecutar Dropbox

PD Desmarcando el preserve modification timestampdropbox le dice que el archivo ha sido modificado y debe sincronizarse. Tenga en cuenta que el montaje del contenedor modifica la marca de tiempo incluso si no cambia ningún archivo en él. Si no desea que eso suceda, simplemente monte el volumen comoread-only

usuario
fuente
¿Sería muy diferente si se utilizara una imagen de archivo .dmg cifrada con macos , el tiempo de sincronización seguiría siendo proporcional a los cambios?
IBrum
@IBrum Lo siento, no lo he probado con un archivo .dmg
usuario
7

¡Me encanta la respuesta de Dan McNevin! Ahora también estoy usando Git y Dropbox juntos, y estoy usando varios alias en mi .bash_profile para que mi flujo de trabajo se vea así:

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

Estos son mis alias:

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'
Michiel de Mare
fuente
Probablemente no usaría lo último como un alias, sino un script de shell. De lo contrario, me gusta mucho. Crédito extra por uso de awk.
pauljohn32
6

Usamos este método (crear un repositorio desnudo en Dropbox) en una carpeta compartida .

Un pequeño grupo de desarrolladores puede extraer de ese repositorio sincronizado desnudo y crear un clon local. Una vez que la unidad de trabajo está hecha, regresamos al origen.

Una cosa que me falta es una buena forma de enviar un correo electrónico con la información del conjunto de cambios una vez que se produce un impulso al origen. Estamos utilizando Google Wave para realizar un seguimiento manual de los cambios.

dengel
fuente
81
Alguien está usando Google Wave?
Kristopher Johnson
6

He estado usando Mercurial de la manera recomendada e insto a que tenga cuidado, especialmente si alguna de las máquinas difiere. Los foros de Dropbox están llenos de quejas de problemas misteriosos de casos de nombre de archivo que aparecen espontáneamente. Hg (y supongo que Git) no se dará cuenta ni se quejará durante los controles de rutina y solo escuchará sobre la corrupción cuando se queja de un repositorio corrupto cuando intenta usarlo de verdad. Malas noticias. Ojalá pudiera ser más específico sobre el problema y sus soluciones; Todavía estoy tratando de sacarme de este lío yo mismo.

Brad Cox
fuente
Tuve el mismo problema con mercurial
Tomba
git verifica mucho más la corrupción que otros por diseño. Entonces, al menos, sabrá cuándo sucede eso y podrá corregir el problema.
Anders
6

También hay un proyecto de código abierto (una colección de scripts multiplataforma [Linux, Mac, Win]) que hace todos los detalles esenciales de la gestión del repositorio con un puñado (3-4) de comandos.

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

El uso de la muestra es:

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

$ gitbox clone myapp
Cloning repository...
Repository successfully cloned.

Después de lo cual el uso normal de git:

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

Consulte el wiki del proyecto y los manuales para obtener referencias completas de comandos y tutoriales.

Péter Szilágyi
fuente
4

Guardo mis repositorios que no son de Github en Dropbox. Una advertencia que encontré fue la sincronización después de una reinstalación. Dropbox descargará primero los archivos más pequeños antes de pasar a los más grandes. No es un problema si comienzas de noche y vuelves después del fin de semana :-)

Mi hilo: http://forums.dropbox.com/topic.php?id=29984&replies=6

Ben
fuente
4

Ahora en 2014, he estado usando Git y Dropbox durante aproximadamente un año y medio sin problemas. Sin embargo, algunos puntos:

  • Todas mis máquinas que usan Dropbox están en Windows, diferentes versiones (7 a 8) + 1 mac.
  • No comparto el repositorio con otra persona, así que soy el único que lo modifica.
  • git push empuja a un repositorio remoto, de modo que si alguna vez se corrompe, puedo recuperarlo fácilmente.
  • Tenía que crear alias en C:\Usersla mklink /D link targetporque algunas bibliotecas se apuntaron a localizaciones absolutas.
Mikaël Mayer
fuente
3

Me gusta la respuesta más votada por Dan McNevin. Terminé haciendo la secuencia de comandos git demasiadas veces y decidí hacer un script. Asi que aqui esta:

#!/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}"

El script solo requiere un nombre de proyecto. Generará un repositorio git ~/Dropbox/git/con el nombre especificado y enviará todo el contenido del directorio actual a la rama maestra de origen recién creada. Si se da más de un nombre de proyecto, se utilizará el argumento del nombre del proyecto más a la derecha.

Opcionalmente, el argumento del comando -r especifica la rama remota que se enviará al maestro de origen. La ubicación del maestro de origen del proyecto también se puede especificar con el argumento -m. Un archivo .gitignore predeterminado también se coloca en el directorio de sucursal remota. Los valores predeterminados del directorio y del archivo .gitignore se especifican en el script.

ChisholmKyle
fuente
3

Otro enfoque:

Todas las respuestas hasta ahora, incluida la respuesta @Dan, que es la más popular, abordan la idea de usar Dropbox para centralizar un repositorio compartido en lugar de usar un servicio centrado en git como github, bitbucket, etc.

Pero, como la pregunta original no especifica qué significa realmente usar "Git y Dropbox juntos efectivamente", trabajemos en otro enfoque: "Usar Dropbox para sincronizar solo el árbol de trabajo".

El tutorial tiene estos pasos:

  1. dentro del directorio del proyecto, uno crea un .gitdirectorio vacío (por ejemplo mkdir -p myproject/.git)

  2. desincronice el .gitdirectorio en Dropbox. Si usa la aplicación de Dropbox: vaya a Preferencias, Sincronización y "elija carpetas para sincronizar", donde el .gitdirectorio debe quedar sin marcar. Esto eliminará el .gitdirectorio.

  3. ejecutar git initen el directorio del proyecto

También funciona si .gitya existe, entonces solo haz el paso 2. Sin embargo, Dropbox mantendrá una copia de los archivos git en el sitio web.

El paso 2 hará que Dropbox no sincronice la estructura del sistema git, que es el resultado deseado para este enfoque.

¿Por qué uno usaría este enfoque?

  • Los cambios que aún no se han presionado tendrán una copia de seguridad de Dropbox, y se sincronizarán en todos los dispositivos.

  • En caso de que Dropbox arruine algo al sincronizar entre dispositivos, git statusy git diffserá útil para resolver las cosas.

  • Ahorra espacio en la cuenta de Dropbox (el historial completo no se almacenará allí)

  • Evita las preocupaciones planteadas por @dubek y @Ates en los comentarios sobre la respuesta de @ Dan, y las preocupaciones de @clu en otra respuesta .

La existencia de un control remoto en otro lugar (github, etc.) funcionará bien con este enfoque.

Trabajar en diferentes sucursales trae algunos problemas que deben ser atendidos:

  • Un problema potencial es tener Dropbox (¿innecesariamente?) Sincronizando potencialmente muchos archivos cuando uno extrae diferentes ramas.

  • Si dos o más dispositivos sincronizados de Dropbox tienen diferentes ramas desprotegidas, se pueden perder los cambios no comprometidos en ambos dispositivos,

Una forma de evitar estos problemas es usarlo git worktreepara mantener los pagos de sucursales en directorios separados.

IBrum
fuente
Como alguien que está trabajando en archivos que sería bueno para el control de versiones, pero también editable en un iPad (a través de la sincronización de Dropbox), esta respuesta cubre ese caso de uso.
Vagari
Seguimiento rápido, el comportamiento actual de Dropbox es diferente. Simplemente eliminar y decirle a Dropbox que no se sincronice significa lo contrario, se queda en la nube, se elimina de lo local. Pero hay una respuesta de superusuario con una solución. superuser.com/a/1527145/109561 En mi caso (en Mac) lo siguiente marca el archivo para ignorarlo xattr -w com.dropbox.ignored 1 /path/to/somewhere.
Vagari
3

Para mis 2 centavos, Dropbox solo tiene sentido para uso personal donde no desea molestarse en obtener un host de repositorio central. Para cualquier desarrollo profesional, probablemente creará más problemas de los que resolverá, como ya se mencionó varias veces en el hilo, Dropbox no está diseñado para este caso de uso. Dicho esto, un método perfectamente seguro para volcar repositorios en Dropbox sin ningún complemento o herramienta de terceros es usar paquetes. Tengo los siguientes alias en mi .gitconfigpara guardar la escritura:

[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 #"

Ejemplo:

# 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
Niklas Holm
fuente
2

Me he enfrentado a un problema similar y he creado un pequeño script para el mismo. La idea es usar Dropbox con Git de la manera más simple posible. Actualmente, he implementado rápidamente el código Ruby , y pronto agregaré más.

Se puede acceder al script en https://github.com/nuttylabs/box-git.

Kiran Madipally
fuente
0

Sin usar herramientas de integración de terceros, podría mejorar un poco la condición y usar DropBox y otros servicios de disco en la nube similares, como SpiderOak con Git.

El objetivo es evitar la sincronización en el medio de las modificaciones de estos archivos, ya que puede cargar un estado parcial y luego volver a descargarlo, corrompiendo por completo su estado git.

Para evitar este problema, hice:

  1. Agrupe mi índice git en un archivo usando git bundle create my_repo.git --all.
  2. Establezca un retraso para la supervisión del archivo, por ejemplo, 5 minutos, en lugar de instantáneo. Esto reduce las posibilidades de que DropBox sincronice un estado parcial en medio de un cambio. También es de gran ayuda al modificar archivos en el disco de la nube sobre la marcha (como con las aplicaciones de toma de notas de guardado instantáneo).

No es perfecto ya que no hay garantía de que no volverá a estropear el estado git, pero ayuda y por el momento no tuve ningún problema.

gaborous
fuente
0

En MacOS, también puede detener Dropbox, realizar sus cambios y luego volver a iniciar Dropbox. Estoy usando la siguiente combinación y estoy bastante contento con ella:

En ambos (su directorio local de proyectos gestionados por git y su repositorio de git remoto ubicado en Dropbox) ejecute el siguiente comando para deshabilitar el empaque automático (que es el principal problema con la sincronización de Dropbox)

git config --global gc.auto 0

Luego, de vez en cuando, comprima los repositorios con Dropbox deshabilitado. Por ejemplo, hago lo siguiente en mi bash-build-script cada vez que hago nuevas versiones de mis aplicaciones.

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\""
Berbie
fuente