tipos tag qué lista existen etiquetas crear comandos git version-control cloud dropbox

tag - ¿Usando Git y Dropbox juntos efectivamente?



lista de comandos git (19)

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

Ahora es 2015, y desde hace tres días, se ha creado una https://github.com/anishathalye/git-remote-dropbox basada en Dropbox API v2 para usar git de forma segura en Dropbox. Funciona contra la API en lugar de usar el cliente de escritorio, y maneja correctamente múltiples inserciones simultáneas en un repositorio alojado en una carpeta compartida.

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

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

Ahora, en 2014, he estado usando Git y Dropbox durante aproximadamente un año y medio sin ningún problema. Algunos puntos sin embargo:

  • Todas mis máquinas que utilizan Dropbox están en Windows, diferentes versiones (7 a 8) + 1 mac.
  • No comparto el repositorio con otra persona, por lo 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.
  • Tuve que crear alias en C:/Users con mklink /D link target porque algunas bibliotecas apuntaban a ubicaciones absolutas.

Almaceno mi repo no Github en Dropbox. Una advertencia que encontré fue la sincronización después de una reinstalación. Dropbox descargará los archivos más pequeños antes de pasar a los más grandes. No es un problema si empiezas por la noche y regresas después del fin de semana :-)

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

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

Si cada desarrollador tiene su propio repositorio simple escribible en Dropbox, que solo es para otros desarrolladores, esto facilita el uso compartido 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.

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 un repositorio central. Ya que no quiero alojarlo en un servicio público, y no tengo acceso a un servidor al que siempre pueda ssh, Dropbox se encarga de esto sincronizando (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.git que haya asociado con su cuenta de Dropbox (o haber 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 control de versiones , ( enlace antiguo muerto ) sobre mi razonamiento y cómo configuré mi entorno, se basa en mi experiencia de desarrollo de Ruby on Rails , pero se puede aplicar a cualquier cosa, realmente.

Esta respuesta se basa en la experiencia de Mercurial , no en Git, pero esta experiencia dice que usar Dropbox de esta manera es solicitar repositorios corruptos si existe la posibilidad de que esté actualizando el mismo repositorio basado en Dropbox desde diferentes máquinas en varios momentos (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 fin de línea y cómo se manejan los caracteres en mayúsculas / minúsculas 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''s back, presto, broken repository. 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 desenterrarme de un lío 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 , lo que quieras. 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 juega con sus puntos fuertes.

Ejecutar Git / Mercurial en la parte superior de Dropbox no agrega nada excepto riesgo. No lo hagas

He estado usando Mercurial de la manera recomendada y le pido que tenga cuidado, especialmente si alguna de las máquinas es diferente. Los foros de Dropbox están llenos de quejas de misteriosos problemas de casos de nombres de archivo que surgen 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 representante 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 salir de este lío.

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

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

La causa principal 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 simultáneas o la sincronización desafortunada con la sincronización pueden resultar en un repositorio dañado.

Los controles remotos tradicionales de Git ejecutan el 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 varios 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. Es incluso seguro de usar con carpetas compartidas, por lo que puede usarse para la colaboración (¡yay repositorios privados ilimitados con colaboradores ilimitados!).

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

Me encanta la respuesta de Dan McNevin! También estoy usando Git y Dropbox juntos ahora, 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''

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 en ~/Dropbox/git/ bajo el nombre especificado y empujará 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 de nombre de 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 la sucursal remota. El directorio y los valores predeterminados del archivo .gitignore se especifican en el script.

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 .

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 fusione 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
  • Te obliga a enviar y recibir cambios desde el repositorio central
  • Si varias personas cambian los mismos archivos, el primer archivo confirmado se reemplaza con los posteriores, y no se produce una 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 te preocupa compartir algunos de tus archivos, ¿por qué no los cifras? Y luego podrías obtener la mayor ventaja de Dropbox to Git, es decir, tener archivos públicos y privados ...

No quería poner todos mis proyectos en un repositorio Git, ni quería entrar y ejecutar este código para cada proyecto, así que hice un script Bash que automatizaría el proceso. Puede usarlo en uno o 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

Otro enfoque:

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

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

El cómo tiene estos pasos:

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

  2. desincronizar el directorio .git en Dropbox. Si usa la aplicación Dropbox: vaya a Preferencias, Sincronizar y "elija carpetas para sincronizar", donde el directorio .git debe quedar sin marcar. Esto eliminará el directorio .git .

  3. ejecuta git init en el directorio del proyecto

También funciona si el .git ya existe, entonces solo realice el paso 2. Sin embargo, Dropbox conservará 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 aún no introducidos 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 status y git diff serán útiles para resolver los problemas.

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

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

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

Trabajar en diferentes ramas trae algunos problemas, que deben ser atendidos:

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

  • Si dos o más dispositivos sincronizados de Dropbox tienen diferentes sucursales comprobadas, los cambios no confirmados en ambos dispositivos se pueden perder,

Una forma de evitar estos problemas es usar git worktree para mantener los git worktree de sucursales en directorios separados.

Para mis 2 centavos, Dropbox solo tiene sentido para el uso personal en el que no quiere molestarse en obtener un host de repo central. Para cualquier desarrollo profesional probablemente creará más problemas de los que resolverá, como ya se ha mencionado varias veces en el tema, 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 .gitconfig para 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

Sin utilizar 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 medio de estas modificaciones de archivos, ya que puede cargar un estado parcial y luego descargarlo de nuevo, corrompiendo completamente su estado git.

Para evitar este problema, hice:

  1. Agrupe mi índice git en un archivo utilizando 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 ayuda enormemente a la hora de modificar archivos en el disco de la nube sobre la marcha (por ejemplo, con el ahorro instantáneo de aplicaciones para tomar notas).

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

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 administració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 la wiki del proyecto y los manuales para obtener una referencia completa de comandos y tutoriales.

Usamos este método (creando un repositorio simple en Dropbox) en una carpeta compartida .

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

Una cosa que me falta es una buena manera de que se envíe un correo electrónico con la información de configuración de cambios una vez que se produce un impulso al origen. Estamos utilizando Google Wave para realizar un seguimiento manual de los cambios.

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

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

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

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

Preparar:

  • Crear un contenedor de Truecrypt (Gigabyte múltiple está bien)
  • En las preferencias de Truecrypt, desmarque preserve modification timestamp *.
  • Cree un repositorio como lo mencionó Dan ( https://.com/a/1961515/781695 )

Uso:

  • Salir de Dropbox
  • Montar el contenedor, empujar sus cambios, desmontar
  • Ejecutar Dropbox

PS Al desmarcar la preserve modification timestamp le dice a Dropbox que el archivo ha sido modificado y que debe estar sincronizado. 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 como read-only