/es/clone.txt

  1== Clonando  ==
  2
  3En 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
  5En 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
  9Este 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
 11Inicializa 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
 15para 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
 20va 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
 24Inicializa un repositorio de Git para tus archivos:
 25
 26 $ git init
 27 $ git add .
 28 $ git commit -m "Commit Inicial"
 29
 30En el servidor central, inicializa un repositorio vacío de Git con algún nombre,
 31y 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
 36Algunos 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
 38Empuja (push) tu proyecto hacia el servidor central con:
 39
 40 $ git push git://servidor.central/ruta/al/proyecto.git HEAD
 41
 42Ya estamos listos. Para copiarse los fuentes, un desarrollador escribe:
 43
 44 $ git clone git://servidor.central/ruta/al/proyecto.git
 45
 46Luego de hacer cambios, el código en envía al servidor central con:
 47
 48 $ git commit -a
 49 $ git push
 50
 51Si 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
 62Luego avísale a todos de tu fork del proyecto en tu servidor.
 63
 64Luego, 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
 72Si tu proyecto no es tan popular, busca tantos servidores como puedas para hospedar tus clones.
 73
 74El 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
 78Digamos que quieres trabajar en varias prestaciones a la vez. Haz commit de tu proyecto y ejecuta:
 79
 80 $ git clone . /un/nuevo/directorio
 81
 82Gracias a los http://es.wikipedia.org/wiki/Enlace_duro[enlaces duros], los clones locales requieren menos tiempo y espacio que un backup plano.
 83
 84Ahora 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
 96y luego clónalo:
 97
 98 $ git clone . /un/nuevo/directorio
 99
100Ahora 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
105Luego ve al nuevo directorio y escribe:
106
107 $ git commit -a -m "Descripción de mis cambios"
108 $ git pull
109
110El 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
112El comando *git svn* automatiza lo anterior para repositorios de Subversion,
113y 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].