es/clone.txt

   1 == Clonando  ==
   2
   3 En sistemas de control de versiones antiguos, checkout es la operación standard para obtener archivos. Obtienes un conjunto de archivos en el estado guardado que solicitaste.
   4
   5 En Git, y otros sistemas de control de versiones distribuídos, clonar es la operación standard. Para obtener archivos se crea un clon de un repositorio entero. En otras palabras, prácticamente se crea una copia idéntica del servidor central. Todo lo que se pueda hacer en el repositorio principal, también podrás hacerlo.
   6
   7 === Sincronizar Computadoras ===
   8
   9 Este es el motivo por el que usé Git por primera vez. Puedo tolerar hacer tarballs o usar *rsync* para backups y sincronización básica. Pero algunas veces edito en mi laptop, otras veces en mi desktop, y ambas pueden no haberse comunicado en el medio.
  10
  11 Inicializa un repositorio de Git y haz commit de tus archivos en una máquina, luego en la otra:
  12
  13  $ git clone otra.computadora:/ruta/a/archivos
  14
  15 para crear una segunda copia de los archivos y el repositorio Git. De ahora en más,
  16
  17  $ git commit -a
  18  $ git pull otra.computadora:/ruta/a/archivos HEAD
  19
  20 va a traer (pull) el estado de los archivos desde la otra máquina hacia la que estás trabajando. Si haz hecho cambios que generen conflictos en un archivo, Git te va a avisar y deberías hacer commit luego de resolverlos.
  21
  22 === Control Clásico de Fuentes ===
  23
  24 Inicializa un repositorio de Git para tus archivos:
  25
  26  $ git init
  27  $ git add .
  28  $ git commit -m "Commit Inicial"
  29
  30 En el servidor central, inicializa un repositorio vacío de Git con algún nombre,
  31 y abre el Git daemon si es necesario:
  32
  33  $ GIT_DIR=proj.git git init
  34  $ git daemon --detach  # podría ya estar corriendo
  35
  36 Algunos servidores públicos, como http://repo.or.cz[repo.or.cz], tienen un método diferente para configurar el repositorio inicialmente vacío de Git, como llenar un formulario en una página.
  37
  38 Empuja (push) tu proyecto hacia el servidor central con:
  39
  40  $ git push git://servidor.central/ruta/al/proyecto.git HEAD
  41
  42 Ya estamos listos. Para copiarse los fuentes, un desarrollador escribe:
  43
  44  $ git clone git://servidor.central/ruta/al/proyecto.git
  45
  46 Luego de hacer cambios, el código en envía al servidor central con:
  47
  48  $ git commit -a
  49  $ git push
  50
  51 Si hubo actualizaciones en el servidor principal, la última versión debe ser traída antes de enviar lo nuevo. Para sincronizar con la última versión:
  52
  53  $ git commit -a
  54  $ git pull
  55
  56 === Bifurcando (fork) un proyecto ===
  57
  58 ¿Harto de la forma en la que se maneja un proyecto?¿Crees que podrías hacerlo mejor? Entonces en tu servidor:
  59
  60  $ git clone git://servidor.principal/ruta/a/archivos
  61
  62 Luego avísale a todos de tu fork del proyecto en tu servidor.
  63
  64 Luego, en cualquier momento, puedes unir (merge) los cambios del proyecto original con:
  65
  66  $ git pull
  67
  68 === Respaldos Definitivos ===
  69
  70 ¿Quieres varios respaldos redundantes a prueba de manipulación y geográficamente diversos? Si tu proyecto tiene varios desarrolladores, ¡no hagas nada! Cada clon de tu código es un backup efectivo. No sólo del estado actual, sino que también de la historia completa de tu proyecto. Gracias al hashing criptográfico, si hay corrupción en cualquiera de los clones, va a ser detectado tan pronto como intente comunicarse con otros.
  71
  72 Si tu proyecto no es tan popular, busca tantos servidores como puedas para hospedar tus clones.
  73
  74 El verdadero paranoico debería siempre escribir el último hash SHA1 de 20-bytes de su HEAD en algún lugar seguro. Tiene que ser seguro, no privado. Por ejemplo, publicarlo en un diario funcionaría bien, porque es difícil para un atacante el alterar cada copia de un diario.
  75
  76 === Multitask A La Velocidad De La Luz ===
  77
  78 Digamos que quieres trabajar en varias prestaciones a la vez. Haz commit de tu proyecto y ejecuta:
  79
  80  $ git clone . /un/nuevo/directorio
  81
  82 Gracias a los http://es.wikipedia.org/wiki/Enlace_duro[enlaces duros], los clones locales requieren menos tiempo y espacio que un backup plano.
  83
  84 Ahora podrás trabajar en dos prestaciones independientes de manera simultánea. Por ejemplo, puedes editar un clon mientras el otro está compilando. En cualquier momento, puedes hacer commit y pull de los cambios desde el otro clon.
  85
  86  $ git pull /el/otro/clon HEAD
  87
  88 === Control Guerrillero De Versiones ===
  89
  90 ¿Estás trabajando en un proyecto que usa algún otro sistema de control de versiones y extrañas mucho a Git? Entonces inicializa un repositorio de Git en tu directorio de trabajo.
  91
  92  $ git init
  93  $ git add .
  94  $ git commit -m "Commit Inicial"
  95
  96 y luego clónalo:
  97
  98  $ git clone . /un/nuevo/directorio
  99
 100 Ahora debes trabajar en el nuevo directorio, usando Git como te sea más cómodo. Cada tanto, querrás sincronizar con los demás, en ese caso, ve al directorio original, sincroniza usando el otro sistema de control de versiones y escribe:
 101
 102  $ git add .
 103  $ git commit -m "Sincronizo con los demás"
 104
 105 Luego ve al nuevo directorio y escribe:
 106
 107  $ git commit -a -m "Descripción de mis cambios"
 108  $ git pull
 109
 110 El procedimiento para pasarle tus cambios a los demás depende de cuál es tu otro sistema de control de versiones. El nuevo directorio contiene los archivos con tus cambios. Ejecuta los comandos que sean necesarios para subirlos al repositorio central del otro sistema de control de versiones.
 111
 112 El comando *git svn* automatiza lo anterior para repositorios de Subversion,
 113 y también puede ser usado para http://google-opensource.blogspot.com/ncr/2008/05/export-git-project-to-google-code.html[exportar un proyecto de Git a un repositorio de Subversion].