¿Es posible alojar un repository de Git desnudo usando Dropbox para compartir el código?

Me doy count de que hay preguntas similares , pero mi pregunta es un poco diferente: me pregunto si compartir un repository simple a través de una carpeta sincronizada de Dropbox en varias computadoras funcionaría para compartir código a través de Git?

En otras palabras: ¿compartir un repository de Git a través de Dropbox es lo mismo que compartirlo desde una location centralizada, por ejemplo, a través de SSH o HTTP?

¿El repository se actualiza en el disco local de cada persona? ¿Es esto lo mismo que compartir un repository de Git a través de una unidad de networking compartida?

Nota: Esta no es una pregunta empírica: parece funcionar bien. Me pregunto si la forma en que se estructura un repository de Git es compatible con esta forma de compartir.

EDITAR Para aclarar / repetir, estoy hablando de mantener el repository de Git en Dropbox como un repository simple . No estoy hablando de mantener los files reales bajo control de código fuente en Dropbox.

Estoy bastante seguro de que esto no es seguro. Hay un montón de partes mobilees en un repository de Git, y Dropbox podría arruinar fácilmente una de ellas. Por ejemplo, puede terminar con sugerencias de twigs incorrectas (maestro, etc.) en el directory refs , o su almacén de objects podría dejar de funcionar si el file objects/info/packs tiene los contenidos incorrectos. Los repositorys Git son bastante simples y robustos, pero no son simplemente un almacenamiento irrompible.

Acceder a repositorys remotos a través de SSH, git o HTTP, o incluso localmente en un sistema de files de networking, es seguro porque solo se accede al repository a través de un process git , que asegura que todo se mueva en su lugar en el order correcto. Pero Dropbox no ofrece ningún tipo de garantía sobre los pedidos, por lo que puede perder datos.

Simplemente use un server Git (o cualquier server SSH) en su lugar; si no tiene uno, me vienen a la mente GitHub , Bitbucket o GitLab . Le ahorrará muchos problemas, y no es más difícil de usar que un repository local compartido a través de Dropbox (solo tiene URL SSH en lugar de routes locales).

No veo ninguna razón por la cual perdería datos: la estructura del repository de Git es robusta, y en la propia tienda de repository, los files con el mismo nombre siempre tendrán el mismo contenido (esto no se aplica a los nombres de las sucursales).

Sin embargo, no va a ser eficiente. El protocolo de transferencia de Git significa que generalmente solo transferirá un cambio una vez. Con Dropbox, si dos personas empacan repositorys ligeramente diferentes, los packages generados pueden contener datos comunes significativos sin ser idénticos, por lo que Dropbox sincronizaría ambos packages, lo que es ineficiente.

También puede encontrar que, aunque los datos están todos allí, termina con cambios sin seguimiento debido a dos copys que tienen la misma twig actualizada al mismo time. Esto puede evitarse asegurándose de presionar a diferentes twigs de cada copy, pero sería un dolor.

¿Qué sucede si dos usuarios están desconectados, trabajan, ingresan a su copy local del repository simple y luego se conectan? En este caso, cuando Dropbox intente sincronizar obtendrá problemas: los files del package y las sugerencias de las sucursales serán diferentes y Dropbox no puede arreglar eso. Ese es el único problema que pude ver. Creo que lo mismo podría suceder incluso si ambos usuarios están conectados, si están empujando en sus repositorys locales al mismo time.

He tenido problemas al usar Dropbox con Git y con Mercurial. Los files de repository a menudo se corrompen, presumiblemente debido a que la synchronization de Dropbox no es perfecta, especialmente cuando se realizan cambios desde varios lugares. Además, Dropbox funciona en segundo plano, por lo que es muy fácil intentar accidentalmente usar el repository (o reiniciar su máquina) mientras se encuentra en el medio de una operación de synchronization.

Me encanta Dropbox, pero no es un buen reemploop para una unidad compartida o un repository de Git remoto "real".

Solía ​​hacer esto con MobileMe, pero las computadoras no se sincronizaban. Cada computadora tendría un repository diferente al que está en la nube y dado que no existe el concepto de "fusión" en MobileMe (y supongo que también DropBox, ¿no?) Terminaría teniendo que elegir una versión para conservar y perder algunas ediciones, o copyr las ediciones y volver a aplicarlas. La vida se ha vuelto mucho más fácil desde que cambié a un repository central de Git.

Si funciona para ti hasta ahora, bien. Me imagino que vas a tener mucho dolor si dos devs presionan a sus repositorys locales al mismo time, sin embargo. ¿Cómo va a saber DropBox cuál es el correcto?

Si te digo que hay casos en los que Dropbox ha estropeado mi Git, ¿responderé a tu pregunta por contradicción? Al less en mi experiencia, esto ha sucedido más de 5 veces y hay muchas personas que tienen la misma experiencia.

Pero hoy en día no creo que Dropbox realmente sea tan esencial con Git, realmente. De hecho, puedes establecer sucursales remotas (Github, Gitorious, Bitbucket) que pueden replace las funciones de compartir y compartir historial de Dropbox (¿no es todo eso sobre Dropbox?) Y ofrecerte aún más.

Un problema con DropBox tiene que ver con la forma en que manejan las copys de security históricas. Si bien puede retrotraer un file individual (en los últimos 30 días, o para siempre si tiene PackRat), no puede deshacer directorys integers. Esto significa que si su repo se arruina por alguna razón, el increíble service de tener una copy de security histórica es esencialmente inútil, ya que tendría que hacer clic en miles de files para regresarlos a una versión anterior.

Y luego están los problemas con las condiciones de carrera, si se quiere, mencionados por la mayoría de las otras respuestas.

Acabo de alojar mi repository en github.com como un repository privado. Sí, tiene que pagar un plan Micro ($ 7 / plan) pero tiene la security de que tiene una copy de security de su código externamente.