es/multiplayer.txt

   1 == Git Multijugador ==
   2
   3 Inicialmente usaba Git en un proyecto privado donde yo era el único desarrollador.
   4 Entre los comandos relacionados a la naturaleza distribuida de Git, sólo necesitaba *pull*
   5 y *clone* así yo podía mantener el mismo proyecto en diferentes lugares.
   6
   7 Más tarde quize publicar mi código con Git, e incluir cambios de los
   8 contribuyentes. Tuve que aprender a administrar proyectos con múltiples desarrolladores
   9 de todo el mundo. Afortunadamente, esta es la fortaleza de Git, y podría decirse
  10 que su razón de ser.
  11
  12 === ¿Quién Soy Yo? ===
  13
  14 Cada commit tiene un nombre de autor y email, los cuales son mostrados por *git log*.
  15 Por defecto, Git usa la configuración del sistema para rellenar estos campos.
  16 Para decirle explícitamente, escribe:
  17
  18   $ git config --global user.name "John Doe"
  19   $ git config --global user.email johndoe@example.com
  20
  21 Omite la bandera global para poner estas opciones sólo para el repositorio actual.
  22
  23 === Git Sobre SSH, HTTP ===
  24
  25 Supón que tienes acceso SSH a un servidor web, pero Git no está instalado. Aunque
  26 es menos eficiente que su protocolo nativo, Git se puede comuncar por HTTP.
  27
  28 Descarga, compila e instala Git en tu cuenta, y crea un repositorio en
  29 tu directorio web:
  30
  31  $ GIT_DIR=proj.git git init
  32  $ cd proj.git
  33  $ git --bare update-server-info
  34  $ cp hooks/post-update.sample hooks/post-update
  35
  36 En versiones antiguas de Git, el comando cp falla y debes ejecutar:
  37
  38  $ chmod a+x hooks/post-update
  39
  40 Ahora tú puedes publicar tus últimas ediciones via SSH desde cualquier clon:
  41
  42  $ git push web.server:/path/to/proj.git master
  43
  44 y cualquiera puede obtener tu proyecto con:
  45
  46  $ git clone http://web.server/proj.git
  47
  48 === Git Sobre Cualquier Cosa ===
  49
  50 ¿Quieres sincronizar repositorios sin servidores, o incluso sin conexión de red?
  51 ¿Necesitas improvisar durante una emergencia? Hemos visto cómo <<makinghistory, *git
  52 fast-export* y *git fast-import* pueden convertir repositorios a un único archivo
  53 y viceversa>>. Podríamos transportar tales archivos de ida y vuelta para enviar repositorios
  54 git sobre cualquier medio, pero una herramienta más eficiente es *git bundle*.
  55
  56 El emisor crea un 'paquete':
  57
  58  $ git bundle create somefile HEAD
  59
  60 luego envía el paquete, +somefile+, a la otra parte de alguna forma: email,
  61 pendrive, una impresión *xxd* y un escáner OCR, leyendo bits a través del teléfono,
  62 señales de humo, etc. El receptor recupera los commits del paquete escribiendo:
  63
  64  $ git pull somefile
  65
  66 El receptor puede incluso hacer esto desde un repositorio vacío. A pesar de su
  67 tamaño, +somefile+ contiene el repositorio git original completo.
  68
  69 En proyectos más grandes, elimina la basura empaquetando sólo los cambios de los que
  70 carece el otro repositorio. Por ejemplo, supón que el commit ``1b6d...'' es commit
  71 compartido más reciente compartido por ambas partes:
  72
  73  $ git bundle create somefile HEAD ^1b6d
  74
  75 Si se hace a menudo, uno puede olvidar fácilmente cual commit fue el último enviado. La
  76 página de ayuda sugiere usar tags para resolver esto. Es decir, después de que envías un paquete,
  77 escribe:
  78
  79  $ git tag -f lastbundle HEAD
  80
  81 y crea nuevos paquetes de actualización con:
  82
  83  $ git bundle create newbundle HEAD ^lastbundle
  84
  85 === Parches: La Moneda Global ===
  86
  87 Los parches son representaciones de texto de tus cambios que pueden ser fácilmente entendidos
  88 por computadores y humanos por igual. Esto les da una calidad universal. Puedes enviar por email un
  89 parche a los desarrolladores sin importar qué sistema de control de versiones estén usando. Mientras
  90 tu audiencia pueda leer su email, ella puede ver tus ediciones. Similarmente, por tu
  91 lado, todo lo que requieres es una cuenta de correo: no hay necesidad de crear un repositorio
  92 Git en línea.
  93
  94 Recuerda del primer capítulo:
  95
  96  $ git diff 1b6d > my.patch
  97
  98 obtiene un parche que puede se pegado en un email para discusión. En un
  99 repositorio Git, escribe:
 100
 101  $ git apply < my.patch
 102
 103 para aplicar el parche.
 104
 105 En un ambiente más formal, cuando los nombres de los autores y quizás las firmas deben
 106 ser guardadas, genera los parches correspondientes pasados un cierto punto escribiendo:
 107
 108  $ git format-patch 1b6d
 109
 110 Los archivos resultantes pueden ser enviados a *git-send-email*, o enviado a mano. También puedes
 111 especificar un rango de commits:
 112
 113  $ git format-patch 1b6d..HEAD^^
 114
 115 En el extremo receptor, guarda el mensaje a un archivo, luego escribe:
 116
 117  $ git am < email.txt
 118
 119 Esto aplica el parche entrante y también crea el commit, incluyendo información tal como el autor.
 120
 121 Con un cliente de correo, puedes necesitar hacer clic en un botón para ver el mensaje en su forma
 122 original antes de guardar el parche a un archivo.
 123
 124 Hay algunas ligeras diferencias para los clientes basados en casillas de correo, pero si tú usas
 125 uno de esos, ¡eres probablemente la persona que puede deducirlo fácilmente sin leer tutoriales!
 126
 127 === Lo Siento, Nos Hemos Movido ===
 128
 129 Después de clonar un repositorio, correr *git push* o *git pull* hará push hacia o
 130 pull desde la URL original. ¿Cómo Git hace esto? El secreto está en las opciones
 131 de configuración creadas con el clone. Echemos un vistazo:
 132
 133  $ git config --list
 134
 135 La opción +remote.origin.url+ controla la URL fuente; ``origin'' es un alias
 136 dado al repositorio fuente. Al igual que con la convención de la rama ``master'', podemos
 137 cambiar o borrar este alias, pero usualmente no hay razón para hacerlo.
 138
 139 Si el repositorio original se mueve, podemos actualizar la URL con:
 140
 141  $ git config remote.origin.url git://new.url/proj.git
 142
 143 La opción +branch.master.merge+ especifica la rama remota por defecto en un
 144 *git pull*. Durante la clonación inicial, se configura a la rama actual del repositorio
 145 fuente, incluso si el HEAD del repositorio fuente se mueve posteriormente a
 146 una rama diferente, más tarde un pull va a seguir fielmente la rama original.
 147
 148 Esta opción sólo se aplica al repositorio en la primera vez que se clona, que es
 149 guardado en la opción +branch.master.remote+. Si tiramos desde otros repositorios
 150 debemos decirle explícitamente que rama queremos:
 151
 152  $ git pull git://example.com/other.git master
 153
 154 El ejemplo de más arriba explica por qué algunos de nuestros ejemplos anteriores
 155 de push y pull no tenían argumentos.
 156
 157 === Ramas Remotas ===
 158
 159 Cuando clonas un repositorio, también clonas todas sus ramas. Tú puedes no haber
 160 notado esto porque Git los esconde: debes consultar por ellos específicamente.
 161 Esto evita que las ramas en el repositorio remoto interfieran con tus ramas,
 162 y también hace a Git más fácil para los principiantes.
 163
 164 Lista las ramas remotas con:
 165
 166  $ git branch -r
 167
 168 Deberías ver algo como esto:
 169
 170  origin/HEAD
 171  origin/master
 172  origin/experimental
 173
 174 Estas representan ramas y el HEAD del repositorio remoto, y pueden ser usados
 175 en los comandos regulares de Git. Por ejemplo, supón que has hecho muchos commits, y
 176 deseas compararlos con la última versión traída. Tú podrías buscar en los registros (logs)
 177 por el hash SHA1 adecuado, pero es mucho más fácil escribir:
 178
 179  $ git diff origin/HEAD
 180
 181 O puedes ver lo que ha sucedido con la rama ``experimental'':
 182
 183  $ git log origin/experimental
 184
 185 === Múltiples Remotes ===
 186
 187 Supón que otros dos desarrolladores están trabajando en nuestro proyecto, y
 188 queremos mantener pestañas en ambos. Podemos seguir más de un repositorio a la vez con:
 189
 190  $ git remote add other git://example.com/some_repo.git
 191  $ git pull other some_branch
 192
 193 Ahora hemos mezclado una rama desde el segundo repositorio, y tenemos
 194 acceso fácil a todas las ramas de todos los repositorios:
 195
 196  $ git diff origin/experimental^ other/some_branch~5
 197
 198 Pero ¿Qué pasa si queremos comparar sus cambios sin afectar nuestro propio trabajo?
 199 En otras palabras, queremos examinar las ramas evitando que sis cambios invadan nuestro
 200 directorio de trabajo. Entonces, en vez de pull, corre:
 201
 202  $ git fetch        # Fetch from origin, the default.
 203  $ git fetch other  # Fetch from the second programmer.
 204
 205 Esto sólo obtiene historias. Aunque el directorio de trabajo permanece intacto,
 206 podemos referirnos a cualquier rama de cualquier repositorio en un comando Git
 207 ya que ahora poseemos una copia local.
 208
 209 Recuerda que detrás de las cámaras, un pull es simplemente un *fetch* luego
 210 *merge*. Usualmente hacemos *pull* porque queremos mezclar el último commit
 211 después de un fetch; esta situación es una excepción notable.
 212
 213 Vea *git help remote* para saber cómo remover repositorios, ignorar ciertas
 214 ramas, y más.
 215
 216 === Mis Preferencias ===
 217
 218 En mis proyectos, me gusta que los contribuyentes preparen los repositorios desde
 219 los cuales voy a hacer pull. Algunos servicios de hosting Git te permiten hospedar
 220 tu propia bifurcación de un proyecto con el clic de un botón.
 221
 222 Después de que obtengo un árbol, uso comandos Git para navegar y examinar los cambios,
 223 los que idealmente están bien organizados y biein descritos. Mezclo mis propios cambios,
 224 y quizás hago más ediciones. Una vez satisfecho, los empujo al repositorio principal.
 225
 226 Aunque rara vez recibo contribuciones, creo que este enfoque escala bien. Vea
 227 http://torvalds-family.blogspot.com/2009/06/happiness-is-warm-scm.html [esta
 228 entrada de blog por Linus Torvalds].
 229
 230 Permanecer en el mundo Git es ligeramente más conveniente que parchar archivos,
 231 dado que me ahorra convertirlos a commits de Git. Además, Git maneja detalles como
 232 grabar el nombre y dirección de email del autor, así como la hora y fecha, y
 233 le pide al autor desdribir sus propios cambios.