¿Cómo configuro un repository local de Git y un directory de respaldo local?

ACTUALIZAR

Configuré los dos repositorys de Git siguiendo las instrucciones de una de las respuestas a continuación, pero el directory de respaldo no tiene copys de los files en el directory de trabajo. Esto es lo que veo en el directory de respaldo …

$ ls total 0 drwxr-xr-x 10 Hristo staff 340 Feb 25 21:40 Kamma.git 

… pero esperaba algo como lo siguiente …

 $ ls total 16 drwxr-xr-x 6 Hristo staff 204 Dec 19 19:51 css drwxr-xr-x 3 Hristo staff 102 Nov 13 18:00 images -rw-r--r--@ 1 Hristo staff 4440 Feb 26 03:20 index.html drwxr-xr-x 15 Hristo staff 510 Feb 24 14:19 js 

Una vez más, quiero que mi directory principal de trabajo, /Users/Hristo/Sites/Kamma , sea el lugar donde realizo los cambios y realice commits y reverts, y tal.

Quiero que /Users/Hristo/Sites/Kamma_bak sea ​​el lugar donde periódicamente realizo cambios importantes, como una nueva versión de mi proyecto, donde todo es una copy de mi directory de trabajo, simplemente no es la copy más actualizada.

Espero que esto tenga sentido.


Publicación original

Me gustaría configurar un repository local de Git. Entonces, por ejemplo, me gustaría que mi location principal sea /Users/Hristo/Sites/Kamma que es donde haría todo mi trabajo.

Estoy buscando poder realizar cambios y volver a las versiones anteriores, etc., la forma en que funciona la subversión. Pero también me gustaría tener un directory de respaldo, /Users/Hristo/Sites/Kamma_bak , como una falla segura, donde me gustaría "empujar" las versiones de vez en cuando.

En este directory de respaldo /Users/Hristo/Sites/Kamma_bak , me gustaría que todos los files existan como copys duplicadas, como copys de security, del directory de trabajo /Users/Hristo/Sites/Kamma

¿Cómo podría hacer esto con Git? Ya lo tengo instalado en mi máquina, ejecutando Snow Leopard.

Nota: Una copy de "copy de security" en la misma máquina no es una copy de security (especialmente si está en el mismo disco). Para ser confiable, realmente necesita copyr sus datos en una (o más) máquinas / medios diferentes, preferiblemente en diferentes ubicaciones.

Parece que su "copy de security" es un repository desnudo , pero quiere que sea un repository no desnudo (es decir, desea que tenga su propio tree de trabajo verificado).

El problema es que presionar a un repository no desnudo generalmente no es una buena idea. Efectivamente, es probable que tales impulsos actualicen la twig a la que HEAD apunta sin actualizar el índice o el tree de trabajo. Esto puede llevar a situaciones muy confusas en el repository de recepción (por ejemplo, files añadidos que se muestran con un estado eliminado, etc.). Por esta razón, las versiones de Git 1.7.0 y posteriores establecen de forma pnetworkingeterminada que se niegan a aceptar requestes a la twig actualmente desprotegida de los repositorys no disponibles.

Nota: Cuando accedes a un repository simple para realizar una copy de security, todos los files contenidos en las confirmaciones enviadas están ahí, simplemente no están desprotegidos (se comprimen y guardan en Git el almacén de objects como "objects sueltos" y "files de package" "). Los datos enviados representan una copy completa del historial del contenido que usted comprometió y promovió. Simplemente no puedes acceder al contenido directamente. En su lugar, debe clonarlo en un repository de repository no estricto (y, por lo tanto, consultar una confirmación) o usar git archive para extraer un set de files sin un repository adicional o un pago completo.


Realmente no estoy convencido de que necesites algo como lo que describes.

Si necesita examinar una instantánea anterior de su repository (y no tiene ganas de hacerlo en su repository de trabajo normal), entonces debe simplemente clonar una copy temporal y get el compromiso anterior deseado. Los clones locales son baratos, ya que pueden enlazar los files de la tienda de objects en lugar de copyrlos. El gráfico de confirmación histórica generalmente es todo lo que necesita para "retroceder en el time". Aunque Git te permitirá reescribir el gráfico de historial a voluntad, no estás en gran peligro de realizar cambios irrecuperables, ya que generalmente requiere -f / –cambios de fuerza y ​​/ o proporciona mecanismos de recuperación (reflogs, refs / original /, edad mínima) requisitos antes de recoger objects sin reference, etc.).

Es una buena idea tener otro repository (especialmente en otra máquina en otra location) donde pueda enviar sus confirmaciones con fines de copy de security (para que pueda recuperarse de (por ejemplo) rm -rf working_repo ), pero un repository rm -rf working_repo suele ser completamente suficiente. Cuando necesitas recuperarte, solo haces un clon. Cuando desee examinar una instantánea anterior sin alterar su repository de trabajo normal, creará un clon temporal en alguna parte. Con buena security de compromiso, git diff , git log (especialmente las opciones -p y -S ), y git show menudo puede proporcionar toda la información "arqueológica" que pueda desear de commits antiguos sin necesidad de pagar nada en absoluto (incluso trabajan en repositorys desnudos).


Sin embargo, si está dispuesto a aceptar el riesgo, puede hacer exactamente lo que quiera.

Git, como cualquier otra herramienta "cortante", te permitirá correr el riesgo de "dispararte en el pie" (perdón por la metáfora mixta).

  1. Cree y configure su depósito de respaldo y agréguelo como un control remoto en el repository de trabajo.

     # paths to the repositories WORKING=/path/to/working BACKUP=/path/to/backup # name for the backup repository in the working repository REMOTE=backup ! test -d "$BACKUP" || (echo "error: $BACKUP already exists"; exit 1) && git clone --origin working "$WORKING" "$BACKUP" && ( cd "$BACKUP" && git config receive.denyCurrentBranch false && git remote rm working ) && ( cd "$WORKING" && git remote add "$REMOTE" "$BACKUP" && git config remote."$REMOTE".push 'refs/heads/*:refs/heads/*' ) 
  2. En el repository de copy de security, configure un enganche post-receive o post-update que git reset --hard . Esto mantendrá el índice y el tree de trabajo actualizados con la twig actualmente desprotegida.

    Las preguntas frecuentes de Git "¿Por qué no veré los cambios en el repository remoto después de" git push "?" Apunta a un script de post-update ejemplo que puede hacer esto de manera relativamente segura (guarda un alijo si el tree de trabajo o el índice están sucios) -esto aún puede perder files sin seguimiento si se insertan files recién agregados con los mismos nombres de ruta).

     ( H="$BACKUP"/.git/hooks/post-update && curl http://utsl.gen.nz/git/post-update >$H && chmod +x "$H" ) 
  3. Presione al repository de respaldo cuando desee actualizarlo.

     (cd "$WORKING" && git push "$REMOTE") 

Si usa una configuration como esta, debe evitar trabajar en el tree de trabajo de la copy de security. Cualquier compromiso que realice allí, cualquier cambio por etapas que deje allí, y cualquier file no rastreado que deje allí, pueden perderse.

Sí, puedes absolutamente hacer eso. Aunque recomendaría que su carpeta de respaldo esté en otra computadora.

Por favor, lea este hilo, ¿Cómo usar Git y Dropbox juntos de manera efectiva?

Creo que las instrucciones proporcionan exactamente lo que estás buscando; la parte del "dropbox" es por supuesto opcional (es solo una carpeta).

EDITAR: Olvídate del bit de Dropbox. Dropbox es solo una carpeta local + un service que lo replica fuera del sitio. Estas instrucciones también funcionarán para usted CON UNA CARPETA LOCAL.

Lo importante es crear un repository vacío (local) que configure como un 'control remoto git' y aplique sus cambios.

Déjame copyr y pegar desde el hilo entre comillas, y hacer los cambios por ti.

Algo como esto debería funcionar:

 ~/Sites/Kamma $ git init ~/Sites/Kamma $ git add . ~/Sites/Kamma $ git commit -m "first commit" ~/Sites/Kamma $ cd ~/Sites/Kamma_bak ~/Sites/Kamma_bak $ mkdir Kamma.git ~/Sites/Kamma_bak $ cd Kamma.git ~/Sites/Kamma_bak $ git init --bare ~/Sites/Kamma_bak $ cd ~/Sites/Kamma ~/Sites/Kamma $ git remote add origin ~/Sites/Kamma_bak/Kamma.git ~/Sites/Kamma $ git push origin master 

git init creará un git repo. Para hacer la copy de security, haga un git clone --no-hardlinks en el repository original para copyrlo. Desde allí puede hacer un empujón de un repository al otro.