├── README.org └── index.html /README.org: -------------------------------------------------------------------------------- 1 | # -*- mode: org -*- 2 | # -*- coding: utf-8 -*- 3 | #+STARTUP: hidestars overview noindent inlineimages logdrawer shrink 4 | #+OPTIONS: H:1 num:t toc:t \n:nil @:t ::t |:t ^:nil -:t f:t *:t <:t date:nil 5 | #+OPTIONS: TeX:t LaTeX:nil skip:nil d:nil todo:t pri:nil tags:not-in-toc 6 | #+OPTIONS: author:nil email:nil creator:nil timestamp:nil 7 | #+CATEGORY: softwarelibre, periodismodatos 8 | #+TAGS: git, github, gitlab, bitbucket, repositorio 9 | #+DESCRIPTION: Git, Github y publicación web 10 | #+latex_header: \renewcommand{\contentsname}{Prueba} 11 | #+EXPORT_FILE_NAME: index 12 | #+language: es 13 | #+AUTHOR: Adolfo Antón Bravo 14 | #+EMAIL: adolflow@infotics.es 15 | #+TITLE: Git, GitHub y Publicación Web 16 | #+DATE: <2015-12-16 mié 16:00> 17 | #+SETUPFILE: https://raw.githubusercontent.com/fniessen/org-html-themes/master/org/theme-readtheorg.setup 18 | 19 | Notas sobre git y Github: 20 | 21 | - git 22 | - github 23 | - gestión de proyectos 24 | - crear copias de proyectos 25 | - adaptar proyectos 26 | - participar en proyectos. 27 | 28 | Puedes trabajar con git desde herramientas gráficas o desde la línea de comandos. 29 | 30 | En este caso vamos a trabajar con la línea de comandos, preferiblemente en GNU/Linux. 31 | 32 | 33 | * Instalación de git 34 | En GNU/Linux, tan solo hay que instalar =git-core=: 35 | #+BEGIN_SRC sh 36 | apt-get install git-core 37 | #+END_SRC 38 | 39 | En Mac se puede instalar el [[https://sourceforge.net/projects/git-osx-installer/][instalador gráfico de git]] y en Windows, [[https://git-for-windows.github.io/][git for Windows]]. 40 | 41 | #+BEGIN_QUOTE 42 | Para usar git desde la terminal en Mac hay que activar las funciones de Xcode. 43 | #+END_QUOTE 44 | 45 | Si queremos disfrutar de una terminal potente, podríamos usar [[http://cygwin.com][Cygwin]] en Windows o la Terminal en Mac. 46 | 47 | Comprobamos que se ha instalado git con la opción =--version= 48 | 49 | #+BEGIN_SRC sh 50 | git --version 51 | #+END_SRC 52 | 53 | También tenemos los instaladores oficiales de [[http://www.git-scm.com][git]]: 54 | - Mac, http://www.git-scm.com/download/mac 55 | - Windows, http://www.git-scm.com/download/win 56 | 57 | * GitHub 58 | 59 | Crea una [[http://www.github.com][cuenta en GitHub]] 60 | 61 | Si no te atreviste con el paso anterior, puedes usar estos programas de escritorio para Windows y Mac: 62 | 63 | - Windows: http://windows.github.com y [[https://help.github.com/articles/set-up-git/#platform-windows][primeros pasos]] 64 | - Mac OS X: http://mac.github.com y [[https://help.github.com/articles/set-up-git/#platform-mac][primeros pasos]] 65 | ** Wiki 66 | En GitHub se puede añadir el wiki como un submódulo, tal como recuerdan [[https://stackoverflow.com/questions/6941688/how-to-integrate-a-github-wiki-into-the-main-project][aquí]]: 67 | 68 | #+BEGIN_SRC bash 69 | git submodule add git://github.com/you/proj.wiki 70 | #+END_SRC 71 | 72 | Que podríamos enlazar con nuestro directorio preferido: 73 | 74 | #+BEGIN_SRC bash 75 | git submodule add git://github.com/you/proj.wiki vocabulary 76 | #+END_SRC 77 | 78 | Ahí debería haber al menos dos archivos: 79 | - =Home.md=, donde estaría la información de portada del wiki. 80 | - =_Sidebar-vocabulary.md=, el menú de la derecha del wiki. 81 | - =_Footer.md=, información al pie. 82 | 83 | *** Qué son los submódulos 84 | :PROPERTIES: 85 | :url: https://git-scm.com/book/en/v2/Git-Tools-Submodules 86 | :END: 87 | Como su propio nombre indica, son parte de un repositorio git. A efectos prácticos, funcionan como un 88 | subrepositorio, un repositorio dentro de un repositorio. 89 | 90 | Para qué se pueden utilizar: 91 | - Se pueden utilizar para separar código en submódulos. 92 | - Pueden ser parte de más de un repositorio, por lo que pueden compartirse con otros proyectos/repositorios, 93 | de tal forma que cuando se actualice ese submódulo se actualizará en todos los repositorios donde está como 94 | submódulo. 95 | **** Funcionamiento 96 | :PROPERTIES: 97 | :cite: https://gist.github.com/gitaarik/8735255 98 | :END: 99 | Cuando añades un submódulo a un repo, añades el código al repo y queda registrada la información que describe 100 | a qué commit está apuntando el submódulo. El archivo =.gitmodules= almacena la versión del submódulo cuando es 101 | añadido. 102 | **** Añadir un submódulo 103 | Se añade un submódulo de la siguiente manera: 104 | 105 | #+begin_source Bash 106 | git submodule add git@github.com:url_a/mi-submodulo.git ruta-donde-quiero-el-submodulo 107 | #+end_source 108 | 109 | De esta manera se pasa el código y se añade información al repositorio principal sobre el submódulo, lo que 110 | contiene el commit a donde apunta el submódulo, que será el commit de la rama por defecto. 111 | **** Obtener el código 112 | Si se crea el submódulo, las otras personas tienen que inicializar el submódulo. Primero obtienes la 113 | información con =git fech= o bien descargamos información y código con =git pull= y después se inicializan con =git submodule init=. 114 | 115 | Si se clona un repositorio con submódulos, también se tiene que correr este comando para obtener el código del 116 | submódulo ya que no lo hace automáticamente con =git clone=. 117 | **** Actualizaciones del submódulo 118 | 119 | Si actualizamos el submódulo, dado que es un repositorio separado, también tendremos que actualizar el repo 120 | principal ya que su último commit apunta al anterior. Para actualizar, desde el repo principal, =git add=, 121 | =git commit= y =git push=. 122 | **** Mantener actualizados los submódulos 123 | 124 | Si otras personas hicieron cambio en el submódulo, hay que actualizar el código con =git submodule update --remote=. 125 | **** Truco 126 | 127 | Si lanzamos =git submodule update --init=, inicializamos los submódulos. 128 | 129 | En *caso* de /tener/ submódulos dentro de submódulos, añadimos =--recursive= al final de la sentencia. 130 | 131 | Recuerda que se pueden hacer =alias= en =git=, por lo que podríamos crear uno tal que así: 132 | 133 | #+begin_src 134 | git config --global alias.update '!git pull && git submodule update --init --recursive' 135 | #+END_SRC 136 | 137 | De tal forma que con =git update= inicializaríamos correctamente el repositorio y el/los submódulo(s). 138 | 139 | **** Gestión de submódulos 140 | :PROPERTIES: 141 | :cite: https://github.com/exlinc/mdlr 142 | :END: 143 | =mdlr= se declara como una herramienta de git para gestionar submódulos fácilmente. 144 | 145 | * Llave SSH 146 | 147 | #+BEGIN_QUOTE 148 | Si no sabes qué es SSH, sáltate esto 149 | #+END_QUOTE 150 | 151 | Las claves SSH son una forma de identificar ordenadores de confianza sin comprometer contraseñas. Se peude generar unas claves SSH y añadir la clave pública de GitHub para que se produzca la conexión. 152 | 153 | GitHub recomienda revisar regularmente la lista de claves SSH y revocar aquellas que no se usen, no se hayan usado o no se vayan a usar. 154 | 155 | Puedes conectarte por ssh y activar la llave ssh para conectarte de forma autentificada automáticamente. Vayamos paso a paso. 156 | 157 | ** Comprobación de claves 158 | 159 | Primero comprobamos que contamos con clave ssh en el equipo: 160 | 161 | #+BEGIN_SRC sh 162 | ls -la ~/.ssh 163 | #+END_SRC 164 | 165 | Si aparece un listado de claves, podremos saltarnos el siguiente paso. Si no, debemos generar unas claves. 166 | 167 | ** Generar claves ssh 168 | 169 | Necesitas generar una clave ssh el equipo local desde el que te conectas: 170 | 171 | #+BEGIN_SRC sh 172 | ssh-keygen -t rsa -b 4096 -C "correo-electronico@dominio.com" 173 | #+END_SRC 174 | 175 | Lo cual crea una nueva clave ssh y utiliza el correo electrónico como etiqueta. 176 | 177 | Si todo va bien, mostrará el mensaje de generación de la clave, pedirá dónde almacenarla y se puede añadir una contraseña: 178 | 179 | #+BEGIN_EXAMPLE 180 | Generating public/private rsa key pair. 181 | Enter file in which to save the key (/home/usuarix/.ssh/id_rsa): 182 | Enter passphrase (empty for no passphrase): 183 | Enter same passphrase again: 184 | Your identification has been saved in /home/usuarix/.ssh/id_rsa. 185 | Your public key has been saved in /home/usuarix/.ssh/id_rsa.pub. 186 | The key fingerprint is: 187 | (...) 188 | #+END_EXAMPLE 189 | 190 | =(...)= es donde aparece la clave. 191 | 192 | Ahora que ya tenemos la clave, la pegamos en GitHub en las preferencias, en el apartado "SSH and GPG keys". 193 | 194 | *** Copia de clave con método =pbcopy= 195 | Para seleccionar la clave, podemos emplear el método MacOSX =pbcopy=, que podemos hackear en GNU/Linux con un /alias/ a partir de =xsel=: 196 | 197 | #+BEGIN_SRC sh 198 | alias pbcopy='xsel --clipboard --input' 199 | alias pbpaste='xsel --clipboard --output' 200 | #+END_SRC 201 | 202 | De esta forma ya podemos utilizar =pbcopy=: 203 | 204 | #+BEGIN_SRC sh 205 | pbcopy < ~/.ssh/id_rsa.pub 206 | #+END_SRC 207 | 208 | Y pegamos en GitHub. A partir de ahí ya podremos conectarnos con GitHub de forma segura. 209 | 210 | *** Copia de clave con =more= y copiar y pegar 211 | 212 | Podemos hacerlo en dos pasos, mostrando la clave y copiándola con el ratón: 213 | 214 | #+BEGIN_SRC sh 215 | more ~/.ssh/id_rsa.pub 216 | #+END_SRC 217 | 218 | ** Configuración local y comprobación 219 | 220 | Ya está casi todo hecho. Ahora falta decirle a git que nos conectamos a GitHub de forma segura. Para ello, podemos comprobar que lo podemos hacer, y en el mismo paso aprobar la conexión: 221 | 222 | #+BEGIN_SRC sh 223 | ssh -T git@github.com 224 | #+END_SRC 225 | 226 | Nos pedirá la contraseña que hayamos puesto a la clave si lo hemos hecho, lo introducimos y listo. Si no, nos saldrá directamente el mensaje: 227 | 228 | #+BEGIN_EXAMPLE 229 | The authenticity of host 'github.com (192.30.252.1)' can't be established. 230 | RSA key fingerprint is 16:27:ac:a5:76:28:2d:36:63:1b:56:4d:eb:df:a6:48. 231 | Are you sure you want to continue connecting (yes/no)? 232 | #+END_EXAMPLE 233 | 234 | Nótese que =192.30.252.1= es una de las direcciones IP de GitHub, pero podría salir otra. Lo más importante es fijarse en el fingerprint. 235 | 236 | Le decimos que sí y entonces GitHub nos responde: 237 | 238 | #+BEGIN_EXAMPLE 239 | Hi usuarix! You've successfully authenticated, but GitHub does not provide shell access. 240 | #+END_EXAMPLE 241 | 242 | Donde =usuarix= es nuestrx usuarix en GitHub. Ya está hecho. 243 | 244 | Si nos apareciese el mensaje =access denied=, recomiendo seguir los pasos anteriores o [[https://help.github.com/articles/error-permission-denied-publickey][este artículo de GitHub]] para comprobar que lo hemos hecho bien. 245 | 246 | * Cambiar el editor por defecto 247 | Por defecto, bash y git vienen con el editor =vi= por defecto. Para cambiarlo, tal como explican en [[https://stackoverflow.com/questions/2596805/how-do-i-make-git-use-the-editor-of-my-choice-for-commits][stackoverflow]], podemos hacerlo en una o en 248 | ambas. 249 | ** core.editor 250 | Para usar =nano= o el editor de texto CLI de nuestra elección, corremos: 251 | #+BEGIN_EXAMPLE 252 | git config --global core.editor "nano" 253 | #+END_EXAMPLE 254 | 255 | La opción =--global= es para hacerlo en todo git. Si solo quisiéramos en este repositorio, sería sin esa 256 | opción. 257 | ** nano como editor por defecto 258 | Lo hacemos en dos líneas, con dos variables de entorno: 259 | 260 | #+BEGIN_EXAMPLE 261 | export VISUAL=nano 262 | export EDITOR=$VISUAL 263 | #+END_EXAMPLE 264 | * Configuración 265 | 266 | La primera vez que usas Git te pedirá tu nombre de usuarix y dirección de correo. Lo podemos agregar con el comando =config=. 267 | 268 | Tal como comenta [[https://stackoverflow.com/a/16682441][sarigalin]] hay tres niveles de configuración de =git=, de más específico a más general, siendo 269 | la más específica la que sobreescribe la más general. 270 | 271 | - =project=, configuración de proyecto, solo disponible para el actual proyecto. Se almacena en =.git/config= 272 | en el directorio del proyecto. 273 | - =global=, configuración global para todos los proyectos del usuario del sistema. Se almacena en =~/.gitconfig=. 274 | - =system=, configuración para el sistema, para todas las cuentas del sistema. 275 | 276 | Por tanto, si queremos tener una configuración para el sistema, escribiremos: 277 | 278 | #+begin_example 279 | git config --system user.name "Fulanito de Tal" 280 | #+end_example 281 | 282 | Si queremos que sea global para nuestra cuenta: 283 | 284 | #+begin_example 285 | git config --global user.name "Fulanito de Tal" 286 | #+end_example 287 | 288 | Y si queremos que sea especifica del repositorio, que es la configuración por defecto, no hay que añadir 289 | =--project= como en los otros dos casos. 290 | 291 | #+begin_example 292 | git config user.name "Fulanito de Tal" 293 | #+end_example 294 | 295 | ** Configuración global 296 | 297 | Añado el nombre de la cuenta, en este caso el nombre de usuarix en GitHub: 298 | 299 | #+BEGIN_SRC sh 300 | git config --global user.name "Nombre_de_Usuarix" 301 | 302 | #+END_SRC 303 | Añado la dirección de correo electrónico: 304 | #+BEGIN_SRC sh 305 | git config --global user.email "usuarix@dominio" 306 | #+END_SRC 307 | 308 | Si no queremos aplicar esta configuración a todo el sistema y solo a este repositorio porque manejamos más usuarixs de GitHub, por ejemplo, no pongáis la opción =--global= 309 | 310 | Cuando hagamos luego =git push=, nos pedirá el usuario y contraseña por https: 311 | #+BEGIN_EXAMPLE 312 | Username for 'https://github.com': usuarix 313 | Password for 'https://usuarix@github.com': 314 | 315 | #+END_EXAMPLE 316 | 317 | * Crear un repositorio 318 | 319 | ** Opción GitHub al final 320 | 321 | Podemos iniciar el proyecto git en un directorio cualquiera, ya creado, o bien crearlo en uno nuevo. 322 | 323 | *** Nuevo repositorio en directorio nuevo 324 | 325 | Si queremos crearlo en uno nuevo, iniciamos el repositorio con la opción =init= seguida del nombre del directorio: 326 | 327 | #+BEGIN_SRC sh 328 | git init nombre_repo 329 | #+END_SRC 330 | 331 | *** Nuevo repositorio en directorio existente 332 | 333 | También podemos crear un directorio con =mkdir= y luego inicializar ese directorio solo con la opción =init=: 334 | 335 | #+BEGIN_SRC sh 336 | mkdir nombre_directorio 337 | cd nombre_directorio 338 | git init 339 | #+END_SRC 340 | 341 | *** Pasarlo a GitHub 342 | 343 | Para que el repositorio o proyecto también esté en GitHub, vamos a Github y creamos un proyecto nuevo que llamamos con el nombre del directorio que hemos creado o del directorio que ya existía. 344 | 345 | #+BEGIN_QUOTE 346 | No marques la opción /Initialize with README/ y tampoco le asignes licencia, vamos a crear un repositorio vacío para que nos sea más fácil realizar el primer =push=. 347 | 348 | #+END_QUOTE 349 | 350 | Conectamos el directorio local donde nos encontramos con GitHub de la siguiente manera: 351 | 352 | #+BEGIN_SRC sh 353 | git remote add origin https://github.com/cuenta/nombre-repositorio 354 | #+END_SRC 355 | 356 | Donde le decimos a =git= que añadimos un =git= remoto en la URL de GitHub. 357 | 358 | Hemos de crear al menos un archivo README.md donde puedes poner la información del proyecto: 359 | 360 | #+BEGIN_SRC sh 361 | echo "# Otro proyecto ni más ni menos" >> README.md 362 | #+END_SRC 363 | 364 | Añadimos el archivo a git: 365 | 366 | #+BEGIN_SRC sh 367 | git add README.md 368 | #+END_SRC 369 | 370 | Lo comiteamos: 371 | #+BEGIN_SRC sh 372 | git commit -m "mi primer commit" 373 | #+END_SRC 374 | 375 | Y lo subimos a GitHub: 376 | #+BEGIN_SRC sh 377 | git push -u origin master 378 | 379 | #+END_SRC 380 | ** Opción GitHub 381 | 382 | Primero creas un repositorio con un nombre en Github. 383 | 384 | Github te sugiere varias formas de copiarlo en local, en el propio ordenador. Os recomiendo seguir estos pasos: 385 | 386 | #+BEGIN_SRC sh 387 | echo "# Proyecto de ..." >> README.md 388 | git init 389 | git add README.md 390 | git commit -m "primer commit" 391 | git remote add origin https://github.com/cuenta/nombre-repositorio 392 | git push -u origin master 393 | #+END_SRC 394 | 395 | ** Comprobaciones 396 | 397 | Comprobamos su estado con la opción =status=: 398 | 399 | #+BEGIN_SRC sh 400 | git status 401 | #+END_SRC 402 | 403 | Si listamos el directorio, comproboremos que tenemos un directorio oculto llamado =.git= 404 | 405 | #+BEGIN_SRC sh 406 | ls -la 407 | #+END_SRC 408 | 409 | Cuando quieras que el directorio deje de ser un repositorio git, tan solo hay que borrar este directorio oculto con =rm -rf=: 410 | 411 | #+BEGIN_SRC sh 412 | rm -rf .git 413 | #+END_SRC 414 | 415 | Si en este caso podríamos saber el /status/ de git, el mensaje nos avisaría diciendo que no se trata de un repositorio git. 416 | 417 | * Clonar un repositorio 418 | 419 | Vamos a cualquier proyecto de GitHub y copiamos la URL que aparece en la casilla de *HTTPS*. En este caso, vamos a clonar el proyecto Boilerplate de Paul Irish: 420 | 421 | #+BEGIN_SRC shell 422 | git clone git://github.com/paulirish/html5-boilerplate.git 423 | #+END_SRC 424 | 425 | Si en vez de clonar un repositorio lleno queremos hacerlo vacío, hay que poner: 426 | 427 | #+BEGIN_SRC shell 428 | git clone --bare https://github.com/exampleuser/old-repository.git 429 | 430 | #+END_SRC 431 | 432 | * Estado del repositorio 433 | 434 | Podemos ver el estado del repositorio con la opción =log= 435 | 436 | #+BEGIN_SRC sh 437 | git log 438 | #+END_SRC 439 | 440 | Que nos da toda esta información: 441 | 442 | - La lista de cada =commit= 443 | - El /hash/ /SHA1/ del /commit/, una cadena única de cada /commit/ 444 | - La autoría 445 | - El mensaje que describía el cambio 446 | 447 | * Información de cambios en el repositorio 448 | 449 | Si queremos ver los cambios en esta versión, debemos utilizar la opción =diff=: 450 | 451 | #+BEGIN_SRC sh 452 | git diff 453 | #+END_SRC 454 | 455 | * Añadir y modificar documentos 456 | ** Añadir 457 | 458 | #+BEGIN_SRC sh 459 | git add ruta-nuevos-archivos 460 | git commit -m "comentario sobre cambios" 461 | git push -u origin rama 462 | #+END_SRC 463 | 464 | * Renombrar archivos o directorios 465 | 466 | *** Renombrar un archivo 467 | 468 | #+BEGIN_SRC sh 469 | git mv archivo1 archivo2 470 | git add archivo2 471 | git push -u origin master 472 | #+END_SRC 473 | 474 | *** Renombrar un directorio 475 | 476 | #+BEGIN_SRC sh 477 | git mv directorio1 directorio2 478 | git add directorio2 479 | git push -u origin master 480 | #+END_SRC 481 | 482 | Ver los cambios que vamos a realizar con la opción =-n=, el atajo de =--dry-run= 483 | 484 | #+BEGIN_SRC sh 485 | git mv -n nombre_directorio_antiguo nombre_directorio_nuevo 486 | #+END_SRC 487 | 488 | *** Case sensitive 489 | 490 | Renombrar en sistemas que no distinguen entre mayúsculas y minúsculas, puede dar un error cuando modifiquemos el nombre por caracteres en mayúsculas, por lo que tendríamos que hacer: 491 | 492 | #+BEGIN_SRC sh 493 | git mv directorio1 tempname && git mv tempname Directorio2 494 | #+END_SRC 495 | 496 | Si nuestro sistema no es /case sensitive/, puede ocurrir que queramos tener dos ficheros que se llaman igual, pero uno emplea mayúsculas y otro minúsculas, y git no nos lo deje incluir. 497 | 498 | Por ejemplo, si tenemos =TFM.html= y =tfm.html= en local, y añadimos a git uno de ellos, luego no podremos añadir el otro a no ser que configuremos nuestro git como /case sensitive/: 499 | 500 | #+BEGIN_SRC sh 501 | git config core.ignorecase false 502 | #+END_SRC 503 | 504 | Ahora ya podremos hacer =git add= con éxito. 505 | 506 | La solución viene de [[http://stackoverflow.com/questions/17683458/how-do-i-commit-case-sensitive-only-filename-changes-in-git][Stackoverflow]] 507 | 508 | 509 | 510 | *** Borrar del repositorio 511 | 512 | Borrar un archivo del repositorio sin borrarlo del sistema de directorios local: 513 | 514 | #+BEGIN_SRC sh 515 | git rm --cached archivo.org 516 | 517 | #+END_SRC 518 | 519 | *** Borrar un directorio 520 | 521 | Para borrar un directorio: 522 | #+BEGIN_SRC sh 523 | git rm --cached -r directorio 524 | 525 | #+END_SRC 526 | 527 | * Actualizar repositorio 528 | 529 | Si queremos actualizar el repositorio con los cambios que se hayan producido en él, lo haremos con la opción =pull=: 530 | 531 | #+BEGIN_SRC sh 532 | git pull 533 | #+END_SRC 534 | 535 | * Deshacer cambios 536 | 537 | Si realizamos un =commit= pero queremos volver atrás, si no hemos realizado push, es: 538 | 539 | #+BEGIN_SRC sh 540 | git reset --hard HEAD-1 541 | 542 | #+END_SRC 543 | 544 | Si hemos realizado el =commit= lo mejor es hacer [[http://schacon.github.io/git/git-revert.html][revert]], tal como explican 545 | 546 | 547 | #+begin_example 548 | git revert 549 | #+end_example 550 | 551 | Para saber el =hash-or-ref= se puede consultar la parte de Commits de la página del repo o 552 | bien con el comando ~git log --pretty=online~. 553 | 554 | Luego hacemos ~git push~ para actualizar el repositorio con el cambio revertido. 555 | 556 | * Pull request 557 | 558 | Haremos un /pull request/ cuando queramos contribuir con nuestros cambios -mejoras, corrección de errores, actualizaciones- a un repositorio que ya existe. 559 | 560 | Por eso, lo primero que tenemos que hacer es crear una copia del proyecto: 561 | 562 | #+BEGIN_SRC sh 563 | git clone ruta-proyecto.git 564 | 565 | #+END_SRC 566 | 567 | Luego creamos una rama donde hacer las modificaciones: 568 | 569 | #+BEGIN_SRC sh 570 | 571 | git checkout -b nueva-rama 572 | 573 | #+END_SRC 574 | 575 | Al crearla nos movemos a esa rama. Podemos comprobarlo si tenemos el asterisco en la rama deseada: 576 | 577 | #+BEGIN_SRC sh 578 | git branch 579 | #+END_SRC 580 | 581 | Si no estamos ahí, vamos con: 582 | #+BEGIN_SRC sh 583 | git checkout nueva-rama 584 | #+END_SRC 585 | 586 | Luego hacemos las modificaciones que sean a nuestros archivos, las añadimos, las comiteamos y las subimos a la rama creada: 587 | 588 | #+BEGIN_SRC sh 589 | git add ruta-nuevos-archivos 590 | git commit -m "comentario sobre cambios" 591 | git push -u origin nueva-rama 592 | #+END_SRC 593 | 594 | Comprobamos el estado de git con =git status= 595 | 596 | #+BEGIN_SRC sh 597 | git status 598 | #+END_SRC 599 | 600 | Si todo está bien, vamos a nuestra copia del proyecto en Github y en la página del repo pondrá que hay una rama sobre la que hacer un /pull-request/, pinchamos y seguimos los pasos. 601 | 602 | Si no hay discusión, si está todo bien, el administrador lo aprobará y entonces podremos borrar la rama. Nos movemos a master y desde ahí borramos en local y en el servidor: 603 | 604 | #+BEGIN_SRC sh 605 | git checkout master 606 | git branch -d nueva-rama 607 | git push origin --delete nueva-rama 608 | 609 | #+END_SRC 610 | * Borrar rama 611 | 612 | En local: 613 | 614 | #+BEGIN_SRC sh 615 | git branch -d rama-local 616 | 617 | #+END_SRC 618 | 619 | Si no se borra así, con =-D= 620 | 621 | #+BEGIN_SRC sh 622 | git branch -d rama-local 623 | 624 | #+END_SRC 625 | 626 | En remoto:: 627 | 628 | #+BEGIN_SRC sh 629 | git push origin --delete rama-remota 630 | 631 | #+END_SRC 632 | 633 | o también: 634 | #+BEGIN_SRC sh 635 | git push origin :ramaremota 636 | 637 | #+END_SRC 638 | 639 | * Mantener un repositorio forkeado actualizado 640 | 641 | Añades =remoteando= como servidor remoto: 642 | 643 | #+BEGIN_SRC sh 644 | git remote add remoteando git://ruta-repositorio.git 645 | git remote add remoteando https://github.com/cuenta/nombre-repositorio.git 646 | #+END_SRC 647 | 648 | Actualizas remoteando pero sin integrar los cambios 649 | #+BEGIN_SRC sh 650 | git fetch upstream 651 | #+END_SRC 652 | 653 | Integras los cambios con la versión local: 654 | 655 | #+BEGIN_SRC sh 656 | git pull upstream master 657 | 658 | #+END_SRC 659 | 660 | * Publicación web 661 | 662 | Si el contenido del proyecto es HTML, podemos utilizar a GitHub como servidor web de nuestro contenido web, a través de la funcionalidad [[http://pages.github.com/][Pages]]. 663 | 664 | Se puede hacer de dos maneras: 665 | 666 | ** Nombre del repositorio 667 | 668 | Si el nombre del repositorio sigue la estructura "nombre-de-usuarix.github.io", el proyecto que cuelgue de ahí se publicará automágicamente en http://nombre-de-usuarix.github.io 669 | 670 | ** Rama gh-pages 671 | 672 | Cualquier repositorio que tenga la rama =gh-pages= será publicado, y se verá su contenido web. 673 | 674 | Por ejemplo, si tenemos un repositorio con nombre =mi-proyecto= que contiene una web y queremos publicarlo como página web, solo tenemos que crear una nueva rama =branch= de nuestro proyecto que llamaremos =gh-pages=: 675 | 676 | #+BEGIN_SRC sh 677 | git checkout -b gh-pages 678 | #+END_SRC 679 | 680 | Luego ponemos ahí todo el contenido de la rama =master=: 681 | 682 | #+BEGIN_SRC sh 683 | git merge master 684 | #+END_SRC 685 | 686 | Por último subimos a GitHub todo lo que tenemos en la nueva rama: 687 | 688 | #+BEGIN_SRC sh 689 | $ git push -u origin gh-pages 690 | 691 | #+END_SRC 692 | 693 | En unos minutos, GitHub lo habrá publicado en una URL del tipo http://nombre-de-usuarix.github.io/mi-proyecto 694 | 695 | Si tu repositorio es solo una web, puedes optar por utilizar solo la rama =gh-pages= en vez de mantener las dos ramas. Para ello tienes que elegir en GitHub qué rama utilizas. 696 | 697 | Si mantienes las dos, actualizar la web se puede convertir en algo tedioso si lo haces habitualmente. 698 | 699 | Para facilitar la tarea, [[http://brettterpstra.com/2012/09/26/github-tip-easily-sync-your-master-to-github-pages/][brettterpstra.com recomienda una solución]], puedes editar =.git/config= y añadir estas líneas a =[remote "origin"]=: 700 | 701 | #+BEGIN_SRC sh 702 | push = +refs/heads/master:refs/heads/gh-pages 703 | push = +refs/heads/master:refs/heads/master 704 | #+END_SRC 705 | 706 | Quedando así: 707 | 708 | #+BEGIN_SRC sh 709 | [remote "origin"] 710 | fetch = +refs/heads/*:refs/remotes/origin/* 711 | url = git@github.com:user/repo.git 712 | push = +refs/heads/master:refs/heads/gh-pages 713 | push = +refs/heads/master:refs/heads/master 714 | 715 | #+END_SRC 716 | 717 | De esta manera, cuando hagas git push lo harás en los dos repos. 718 | * Gitignore 719 | https://git-scm.com/docs/gitignore 720 | * Problemas 721 | ** 403 fatal: HTTP request failed 722 | http://stackoverflow.com/questions/7438313/pushing-to-git-returning-error-code-403-fatal-http-request-failed 723 | #+BEGIN_SRC sh 724 | git remote set-url origin https://yourusername@github.com/user/repo.git 725 | 726 | #+END_SRC 727 | 728 | ** git: error: src refspec master does not match any 729 | http://stackoverflow.com/questions/10568641/git-error-src-refspec-master-does-not-match-any 730 | #+BEGIN_SRC sh 731 | git remote rm origin 732 | git remote set-url origin git@.... 733 | git push -u origin master 734 | #+END_SRC 735 | 736 | ** Please, commit your changes or stash them before you can merge. 737 | Si alguien o tú mismo en otro equipo ha actualizado el repositorio 738 | mientras tú trabajabas y te sale este error, sin entrar en las 739 | opciones con las ramas, tienes [[http://stackoverflow.com/questions/15745045/how-do-i-resolve-git-saying-commit-your-changes-or-stash-them-before-you-can-me][tres opciones]]: 740 | 741 | *** Comitear el cambio de la forma típica: 742 | #+BEGIN_SRC sh 743 | git commit -m "comentario" 744 | #+END_SRC 745 | 746 | *** Reservarlo o depositarlo en una pila o /stack/ con =stash=: 747 | 748 | #+BEGIN_SRC sh 749 | git stash 750 | 751 | #+END_SRC 752 | 753 | Ahí puedes hacer =push= y aparece en orden inverso: 754 | 755 | #+BEGIN_SRC sh 756 | git stash pop 757 | #+END_SRC 758 | 759 | *** Descartar los cambios que has hecho 760 | 761 | #+BEGIN_SRC sh 762 | git reset --hard 763 | 764 | #+END_SRC 765 | 766 | ** Github fatal remote origin already exists :noexport: 767 | 768 | Versión corta de la solución: actualiza irotisoper le:otomer o 769 | 770 | TL;DR you should just update the existing remote: 771 | 772 | $ git remote set-url origin git@github.com:ppreyer/first_app.git 773 | 774 | Long version: 775 | 776 | As the error message indicates, there is already a remote configured with the same name. So you can either add the new remote with a different name or update the existing one if you don't need it: 777 | 778 | To add a new remote, called for example github instead of origin (which obviously already exists in your system), do the following: 779 | 780 | $ git remote add github git@github.com:ppreyer/first_app.git 781 | 782 | Remember though, everywhere in the tutorial you see "origin" you should replace it with "github". For example $ git push origin master should now be $ git push github master. 783 | 784 | However, if you want to see what that origin which already exists is, you can do a $ git remote -v. If you think this is there by some error, you can update it like so: 785 | 786 | $ git remote set-url origin git@github.com:ppreyer/first_app.git 787 | 788 | http://stackoverflow.com/questions/10904339/github-fatal-remote-origin-already-exists 789 | 790 | Encuentro respuesta en [[http://stackoverflow.com/questions/10904339/github-fatal-remote-origin-already-exists][stackoverflow]]. 791 | 792 | Versión corta de la solución: actualiza el repositorio remoto: 793 | 794 | #+begin_src bash 795 | git remote set-url origin https://github.com/cuenta/nombre-repositorio 796 | 797 | #+end_src 798 | 799 | Versión larga: tal como indica el error, ya hay un =remote= configurado con el mismo nombre por lo que puedes 800 | añadir un nuevo =remoto= con otro nombre o actualizar el existente si no lo necesitas. 801 | 802 | Para añadir un nuevo =remoto= vale el ejemplo de la versión corta y en vez de =origin= llámalo como quieras: 803 | 804 | #+begin_src bash 805 | git remote set-url como-quieras https://github.com/cuenta/nombre-repositorio 806 | #+end_src 807 | 808 | Y entonces podrías actualizarlo con: 809 | 810 | #+begin_src bash 811 | git push como-quieras master https://github.com/cuenta/nombre-repositorio 812 | #+end_src 813 | 814 | #+begin_notes 815 | Recuerda que puedes ver los =remote= que tienes con ~git remote -v~ 816 | #+end_notes 817 | 818 | 819 | * Pruebas 820 | [[https://try.github.io/levels/1/challenges/1][Try Git]] 821 | * Bibliografía 822 | ** Algunos recursos 823 | - [[https://git-scm.com/book/es][Git, distributed is the new centralized]] 824 | - http://alistapart.com/article/get-started-with-git 825 | - http://progit.org/book/ch1-4.html 826 | - Mastering markdown, guía de Github https://guides.github.com/features/mastering-markdown/ 827 | - [[http://ferblape.github.io/github.com-medialab-desigualdad][Qué es y cómo publicar nuestros proyectos en Github]] 828 | - [[http://rooteando.com/escenarios-de-trabajo-en-git/][Escenario de trabajo en git]] 829 | 830 | ** Git Github Course 831 | :PROPERTIES: 832 | :url: https://github.com/OxfordRSE/git-github-course 833 | :END: 834 | 835 | ** Cheatsheets 836 | - [[http://overapi.com/static/cs/git-cheat-sheet.pdf][git cheat sheet]] 837 | ======= 838 | ** Cheatsheets 839 | - [[http://overapi.com/static/cs/git-cheat-sheet.pdf][Git cheat sheet]] 840 | 841 | -------------------------------------------------------------------------------- /index.html: -------------------------------------------------------------------------------- 1 | 2 | 4 | 5 | 6 | 7 | 8 | Git, GitHub y Publicación Web 9 | 10 | 12 | 196 | 197 | 198 | 199 | 200 | 201 | 202 | 224 | 225 | 226 |
227 |

Git, GitHub y Publicación Web

228 | 256 |

257 | Notas sobre git y Github: 258 |

259 | 260 | 268 | 269 |

270 | Puedes trabajar con git desde herramientas gráficas o desde la línea de comandos. 271 |

272 | 273 |

274 | En este caso vamos a trabajar con la línea de comandos, preferiblemente en GNU/Linux. 275 |

276 | 277 | 278 |
279 |

1. Instalación de git

280 |
281 |

282 | En GNU/Linux, tan solo hay que instalar git-core: 283 |

284 |
285 | 
apt-get install git-core
 286 |
287 |
288 | 289 |

290 | En Mac se puede instalar el instalador gráfico de git y en Windows, git for Windows. 291 |

292 | 293 |
294 |

295 | Para usar git desde la terminal en Mac hay que activar las funciones de Xcode. 296 |

297 |
298 | 299 |

300 | Si queremos disfrutar de una terminal potente, podríamos usar Cygwin en Windows o la Terminal en Mac. 301 |

302 | 303 |

304 | Comprobamos que se ha instalado git con la opción --version 305 |

306 | 307 |
308 | 
git --version
 309 |
310 |
311 | 312 |

313 | También tenemos los instaladores oficiales de git: 314 |

315 | 319 |
320 |
321 | 322 |
323 |

2. GitHub

324 |
325 |

326 | Crea una cuenta en GitHub 327 |

328 | 329 |

330 | Si no te atreviste con el paso anterior, puedes usar estos programas de escritorio para Windows y Mac: 331 |

332 | 333 | 337 |
338 |
    339 |
  1. Wiki
    340 |
    341 |

    342 | En GitHub se puede añadir el wiki como un submódulo, tal como recuerdan aquí: 343 |

    344 | 345 |
    346 | 
    git submodule add git://github.com/you/proj.wiki
 347 |
    348 |
    349 | 350 |

    351 | Que podríamos enlazar con nuestro directorio preferido: 352 |

    353 | 354 |
    355 | 
    git submodule add git://github.com/you/proj.wiki vocabulary
 356 |
    357 |
    358 | 359 |

    360 | Ahí debería haber al menos dos archivos: 361 |

    362 |
      363 |
    • Home.md, donde estaría la información de portada del wiki.
      • 364 |
    • _Sidebar-vocabulary.md, el menú de la derecha del wiki.
      • 365 |
    • _Footer.md, información al pie.
      • 366 |
    367 |
    368 | 369 |
      370 |
    1. Qué son los submódulos
      371 |
      372 |

      373 | Como su propio nombre indica, son parte de un repositorio git. A efectos prácticos, funcionan como un 374 | subrepositorio, un repositorio dentro de un repositorio. 375 |

      376 | 377 |

      378 | Para qué se pueden utilizar: 379 |

      380 |
        381 |
      • Se pueden utilizar para separar código en submódulos.
        • 382 |
      • Pueden ser parte de más de un repositorio, por lo que pueden compartirse con otros proyectos/repositorios, 383 | de tal forma que cuando se actualice ese submódulo se actualizará en todos los repositorios donde está como 384 | submódulo.
        • 385 |
      386 |
      387 |
        388 |
      1. Funcionamiento
        389 |
        390 |

        391 | Cuando añades un submódulo a un repo, añades el código al repo y queda registrada la información que describe 392 | a qué commit está apuntando el submódulo. El archivo .gitmodules almacena la versión del submódulo cuando es 393 | añadido. 394 |

        395 |
        396 |
        2. 397 |
      2. Añadir un submódulo
        398 |
        399 |

        400 | Se añade un submódulo de la siguiente manera: 401 |

        402 | 403 |
        404 |

        405 | git submodule add git@github.com:url_a/mi-submodulo.git ruta-donde-quiero-el-submodulo 406 |

        407 | 408 |
        409 | 410 |

        411 | De esta manera se pasa el código y se añade información al repositorio principal sobre el submódulo, lo que 412 | contiene el commit a donde apunta el submódulo, que será el commit de la rama por defecto. 413 |

        414 |
        415 |
        3. 416 |
      3. Obtener el código
        417 |
        418 |

        419 | Si se crea el submódulo, las otras personas tienen que inicializar el submódulo. Primero obtienes la 420 | información con git fech o bien descargamos información y código con git pull y después se inicializan con git submodule init. 421 |

        422 | 423 |

        424 | Si se clona un repositorio con submódulos, también se tiene que correr este comando para obtener el código del 425 | submódulo ya que no lo hace automáticamente con git clone. 426 |

        427 |
        428 |
        4. 429 |
      4. Actualizaciones del submódulo
        430 |
        431 |

        432 | Si actualizamos el submódulo, dado que es un repositorio separado, también tendremos que actualizar el repo 433 | principal ya que su último commit apunta al anterior. Para actualizar, desde el repo principal, git add, 434 | git commit y git push. 435 |

        436 |
        437 |
        5. 438 |
      5. Mantener actualizados los submódulos
        439 |
        440 |

        441 | Si otras personas hicieron cambio en el submódulo, hay que actualizar el código con git submodule update --remote. 442 |

        443 |
        444 |
        6. 445 |
      6. Truco
        446 |
        447 |

        448 | Si lanzamos git submodule update --init, inicializamos los submódulos. 449 |

        450 | 451 |

        452 | En caso de tener submódulos dentro de submódulos, añadimos --recursive al final de la sentencia. 453 |

        454 | 455 |

        456 | Recuerda que se pueden hacer alias en git, por lo que podríamos crear uno tal que así: 457 |

        458 | 459 | 
         460 | git config --global alias.update '!git pull && git submodule update --init --recursive'
 461 |
        462 | 463 |

        464 | De tal forma que con git update inicializaríamos correctamente el repositorio y el/los submódulo(s). 465 |

        466 |
        467 |
        7. 468 | 469 |
      7. Gestión de submódulos
        470 |
        471 |

        472 | mdlr se declara como una herramienta de git para gestionar submódulos fácilmente. 473 |

        474 |
        475 |
        8. 476 |
      477 |
      2. 478 |
    479 |
    2. 480 |
481 |
482 | 483 |
484 |

3. Llave SSH

485 |
486 |
487 |

488 | Si no sabes qué es SSH, sáltate esto 489 |

490 |
491 | 492 |

493 | Las claves SSH son una forma de identificar ordenadores de confianza sin comprometer contraseñas. Se peude generar unas claves SSH y añadir la clave pública de GitHub para que se produzca la conexión. 494 |

495 | 496 |

497 | GitHub recomienda revisar regularmente la lista de claves SSH y revocar aquellas que no se usen, no se hayan usado o no se vayan a usar. 498 |

499 | 500 |

501 | Puedes conectarte por ssh y activar la llave ssh para conectarte de forma autentificada automáticamente. Vayamos paso a paso. 502 |

503 |
504 | 505 |
    506 |
  1. Comprobación de claves
    507 |
    508 |

    509 | Primero comprobamos que contamos con clave ssh en el equipo: 510 |

    511 | 512 |
    513 | 
    ls -la ~/.ssh
 514 |
    515 |
    516 | 517 |

    518 | Si aparece un listado de claves, podremos saltarnos el siguiente paso. Si no, debemos generar unas claves. 519 |

    520 |
    521 |
    2. 522 | 523 |
  2. Generar claves ssh
    524 |
    525 |

    526 | Necesitas generar una clave ssh el equipo local desde el que te conectas: 527 |

    528 | 529 |
    530 | 
    ssh-keygen -t rsa -b 4096 -C "correo-electronico@dominio.com"
 531 |
    532 |
    533 | 534 |

    535 | Lo cual crea una nueva clave ssh y utiliza el correo electrónico como etiqueta. 536 |

    537 | 538 |

    539 | Si todo va bien, mostrará el mensaje de generación de la clave, pedirá dónde almacenarla y se puede añadir una contraseña: 540 |

    541 | 542 | 
     543 | Generating public/private rsa key pair.
 544 | Enter file in which to save the key (/home/usuarix/.ssh/id_rsa): 
 545 | Enter passphrase (empty for no passphrase): 
 546 | Enter same passphrase again: 
 547 | Your identification has been saved in /home/usuarix/.ssh/id_rsa.
 548 | Your public key has been saved in /home/usuarix/.ssh/id_rsa.pub.
 549 | The key fingerprint is:
 550 | (...)
 551 |
    552 | 553 |

    554 | (...) es donde aparece la clave. 555 |

    556 | 557 |

    558 | Ahora que ya tenemos la clave, la pegamos en GitHub en las preferencias, en el apartado "SSH and GPG keys". 559 |

    560 |
    561 | 562 |
      563 |
    1. Copia de clave con método pbcopy
      564 |
      565 |

      566 | Para seleccionar la clave, podemos emplear el método MacOSX pbcopy, que podemos hackear en GNU/Linux con un alias a partir de xsel: 567 |

      568 | 569 |
      570 | 
      alias pbcopy='xsel --clipboard --input'
 571 | alias pbpaste='xsel --clipboard --output'
 572 |
      573 |
      574 | 575 |

      576 | De esta forma ya podemos utilizar pbcopy: 577 |

      578 | 579 |
      580 | 
      pbcopy < ~/.ssh/id_rsa.pub
 581 |
      582 |
      583 | 584 |

      585 | Y pegamos en GitHub. A partir de ahí ya podremos conectarnos con GitHub de forma segura. 586 |

      587 |
      588 |
      2. 589 | 590 |
    2. Copia de clave con more y copiar y pegar
      591 |
      592 |

      593 | Podemos hacerlo en dos pasos, mostrando la clave y copiándola con el ratón: 594 |

      595 | 596 |
      597 | 
      more ~/.ssh/id_rsa.pub
 598 |
      599 |
      600 |
      601 |
      3. 602 |
    603 |
    3. 604 | 605 |
  3. Configuración local y comprobación
    606 |
    607 |

    608 | Ya está casi todo hecho. Ahora falta decirle a git que nos conectamos a GitHub de forma segura. Para ello, podemos comprobar que lo podemos hacer, y en el mismo paso aprobar la conexión: 609 |

    610 | 611 |
    612 | 
    ssh -T git@github.com
 613 |
    614 |
    615 | 616 |

    617 | Nos pedirá la contraseña que hayamos puesto a la clave si lo hemos hecho, lo introducimos y listo. Si no, nos saldrá directamente el mensaje: 618 |

    619 | 620 | 
     621 | The authenticity of host 'github.com (192.30.252.1)' can't be established.
 622 | RSA key fingerprint is 16:27:ac:a5:76:28:2d:36:63:1b:56:4d:eb:df:a6:48.
 623 | Are you sure you want to continue connecting (yes/no)?
 624 |
    625 | 626 |

    627 | Nótese que 192.30.252.1 es una de las direcciones IP de GitHub, pero podría salir otra. Lo más importante es fijarse en el fingerprint. 628 |

    629 | 630 |

    631 | Le decimos que sí y entonces GitHub nos responde: 632 |

    633 | 634 | 
     635 | Hi usuarix! You've successfully authenticated, but GitHub does not provide shell access.
 636 |
    637 | 638 |

    639 | Donde usuarix es nuestrx usuarix en GitHub. Ya está hecho. 640 |

    641 | 642 |

    643 | Si nos apareciese el mensaje access denied, recomiendo seguir los pasos anteriores o este artículo de GitHub para comprobar que lo hemos hecho bien. 644 |

    645 |
    646 |
    4. 647 |
648 |
649 | 650 |
651 |

4. Cambiar el editor por defecto

652 |
653 |

654 | Por defecto, bash y git vienen con el editor vi por defecto. Para cambiarlo, tal como explican en stackoverflow, podemos hacerlo en una o en 655 | ambas. 656 |

657 |
658 |
    659 |
  1. core.editor
    660 |
    661 |

    662 | Para usar nano o el editor de texto CLI de nuestra elección, corremos: 663 |

    664 | 
     665 | git config --global core.editor "nano"
 666 |
    667 | 668 |

    669 | La opción --global es para hacerlo en todo git. Si solo quisiéramos en este repositorio, sería sin esa 670 | opción. 671 |

    672 |
    673 |
    2. 674 |
  2. nano como editor por defecto
    675 |
    676 |

    677 | Lo hacemos en dos líneas, con dos variables de entorno: 678 |

    679 | 680 | 
     681 | export VISUAL=nano
 682 | export EDITOR=$VISUAL
 683 |
    684 |
    685 |
    3. 686 |
687 |
688 |
689 |

5. Configuración

690 |
691 |

692 | La primera vez que usas Git te pedirá tu nombre de usuarix y dirección de correo. Lo podemos agregar con el comando config. 693 |

694 | 695 |

696 | Tal como comenta sarigalin hay tres niveles de configuración de git, de más específico a más general, siendo 697 | la más específica la que sobreescribe la más general. 698 |

699 | 700 |
    701 |
  • project, configuración de proyecto, solo disponible para el actual proyecto. Se almacena en .git/config 702 | en el directorio del proyecto.
    • 703 |
  • global, configuración global para todos los proyectos del usuario del sistema. Se almacena en ~/.gitconfig.
    • 704 |
  • system, configuración para el sistema, para todas las cuentas del sistema.
    • 705 |
706 | 707 |

708 | Por tanto, si queremos tener una configuración para el sistema, escribiremos: 709 |

710 | 711 | 
 712 | git config --system user.name "Fulanito de Tal"
 713 |
714 | 715 |

716 | Si queremos que sea global para nuestra cuenta: 717 |

718 | 719 | 
 720 | git config --global user.name "Fulanito de Tal"
 721 |
722 | 723 |

724 | Y si queremos que sea especifica del repositorio, que es la configuración por defecto, no hay que añadir 725 | --project como en los otros dos casos. 726 |

727 | 728 | 
 729 | git config  user.name "Fulanito de Tal"
 730 |
731 |
732 | 733 |
    734 |
  1. Configuración global
    735 |
    736 |

    737 | Añado el nombre de la cuenta, en este caso el nombre de usuarix en GitHub: 738 |

    739 | 740 |
    741 | 
    git config --global user.name "Nombre_de_Usuarix"
 742 | 
 743 |
    744 |
    745 |

    746 | Añado la dirección de correo electrónico: 747 |

    748 |
    749 | 
    git config --global user.email "usuarix@dominio"
 750 |
    751 |
    752 | 753 |

    754 | Si no queremos aplicar esta configuración a todo el sistema y solo a este repositorio porque manejamos más usuarixs de GitHub, por ejemplo, no pongáis la opción --global 755 |

    756 | 757 |

    758 | Cuando hagamos luego git push, nos pedirá el usuario y contraseña por https: 759 |

    760 | 
     761 | Username for 'https://github.com': usuarix
 762 | Password for 'https://usuarix@github.com': 
 763 | 
 764 |
    765 |
    766 |
    2. 767 |
768 |
769 | 770 |
771 |

6. Crear un repositorio

772 |
773 |
774 |
    775 |
  1. Opción GitHub al final
    776 |
    777 |

    778 | Podemos iniciar el proyecto git en un directorio cualquiera, ya creado, o bien crearlo en uno nuevo. 779 |

    780 |
    781 | 782 |
      783 |
    1. Nuevo repositorio en directorio nuevo
      784 |
      785 |

      786 | Si queremos crearlo en uno nuevo, iniciamos el repositorio con la opción init seguida del nombre del directorio: 787 |

      788 | 789 |
      790 | 
      git init nombre_repo
 791 |
      792 |
      793 |
      794 |
      2. 795 | 796 |
    2. Nuevo repositorio en directorio existente
      797 |
      798 |

      799 | También podemos crear un directorio con mkdir y luego inicializar ese directorio solo con la opción init: 800 |

      801 | 802 |
      803 | 
      mkdir nombre_directorio
 804 | cd nombre_directorio
 805 | git init
 806 |
      807 |
      808 |
      809 |
      3. 810 | 811 |
    3. Pasarlo a GitHub
      812 |
      813 |

      814 | Para que el repositorio o proyecto también esté en GitHub, vamos a Github y creamos un proyecto nuevo que llamamos con el nombre del directorio que hemos creado o del directorio que ya existía. 815 |

      816 | 817 |
      818 |

      819 | No marques la opción Initialize with README y tampoco le asignes licencia, vamos a crear un repositorio vacío para que nos sea más fácil realizar el primer push. 820 |

      821 |
      822 | 823 |

      824 | Conectamos el directorio local donde nos encontramos con GitHub de la siguiente manera: 825 |

      826 | 827 |
      828 | 
      git remote add origin https://github.com/cuenta/nombre-repositorio
 829 |
      830 |
      831 | 832 |

      833 | Donde le decimos a git que añadimos un git remoto en la URL de GitHub. 834 |

      835 | 836 |

      837 | Hemos de crear al menos un archivo README.md donde puedes poner la información del proyecto: 838 |

      839 | 840 |
      841 | 
      echo "# Otro proyecto ni más ni menos" >> README.md
 842 |
      843 |
      844 | 845 |

      846 | Añadimos el archivo a git: 847 |

      848 | 849 |
      850 | 
      git add README.md
 851 |
      852 |
      853 | 854 |

      855 | Lo comiteamos: 856 |

      857 |
      858 | 
      git commit -m "mi primer commit"
 859 |
      860 |
      861 | 862 |

      863 | Y lo subimos a GitHub: 864 |

      865 |
      866 | 
      git push -u origin master
 867 | 
 868 |
      869 |
      870 |
      871 |
      4. 872 |
    873 |
    2. 874 |
  2. Opción GitHub
    875 |
    876 |

    877 | Primero creas un repositorio con un nombre en Github. 878 |

    879 | 880 |

    881 | Github te sugiere varias formas de copiarlo en local, en el propio ordenador. Os recomiendo seguir estos pasos: 882 |

    883 | 884 |
    885 | 
    echo "# Proyecto de ..." >> README.md
 886 | git init
 887 | git add README.md
 888 | git commit -m "primer commit"
 889 | git remote add origin https://github.com/cuenta/nombre-repositorio
 890 | git push -u origin master
 891 |
    892 |
    893 |
    894 |
    3. 895 | 896 |
  3. Comprobaciones
    897 |
    898 |

    899 | Comprobamos su estado con la opción status: 900 |

    901 | 902 |
    903 | 
    git status
 904 |
    905 |
    906 | 907 |

    908 | Si listamos el directorio, comproboremos que tenemos un directorio oculto llamado .git 909 |

    910 | 911 |
    912 | 
    ls -la
 913 |
    914 |
    915 | 916 |

    917 | Cuando quieras que el directorio deje de ser un repositorio git, tan solo hay que borrar este directorio oculto con rm -rf: 918 |

    919 | 920 |
    921 | 
    rm -rf .git
 922 |
    923 |
    924 | 925 |

    926 | Si en este caso podríamos saber el status de git, el mensaje nos avisaría diciendo que no se trata de un repositorio git. 927 |

    928 |
    929 |
    4. 930 |
931 |
932 | 933 |
934 |

7. Clonar un repositorio

935 |
936 |

937 | Vamos a cualquier proyecto de GitHub y copiamos la URL que aparece en la casilla de HTTPS. En este caso, vamos a clonar el proyecto Boilerplate de Paul Irish: 938 |

939 | 940 |
941 | 
git clone git://github.com/paulirish/html5-boilerplate.git
 942 |
943 |
944 | 945 |

946 | Si en vez de clonar un repositorio lleno queremos hacerlo vacío, hay que poner: 947 |

948 | 949 |
950 | 
git clone --bare https://github.com/exampleuser/old-repository.git
 951 | 
 952 |
953 |
954 |
955 |
956 | 957 |
958 |

8. Estado del repositorio

959 |
960 |

961 | Podemos ver el estado del repositorio con la opción log 962 |

963 | 964 |
965 | 
git log
 966 |
967 |
968 | 969 |

970 | Que nos da toda esta información: 971 |

972 | 973 |
    974 |
  • La lista de cada commit
    • 975 |
  • El hash SHA1 del commit, una cadena única de cada commit
    • 976 |
  • La autoría
    • 977 |
  • El mensaje que describía el cambio
    • 978 |
979 |
980 |
981 | 982 |
983 |

9. Información de cambios en el repositorio

984 |
985 |

986 | Si queremos ver los cambios en esta versión, debemos utilizar la opción diff: 987 |

988 | 989 |
990 | 
git diff
 991 |
992 |
993 |
994 |
995 | 996 |
997 |

10. Añadir y modificar documentos

998 |
999 |
1000 |
    1001 |
  1. Añadir
    1002 |
    1003 |
    1004 | 
    git add ruta-nuevos-archivos
1005 | git commit -m "comentario sobre cambios"
1006 | git push -u origin rama
1007 |
    1008 |
    1009 |
    1010 |
    2. 1011 |
1012 |
1013 | 1014 |
1015 |

11. Renombrar archivos o directorios

1016 |
1017 |
1018 |
    1019 |
  1. Renombrar un archivo
    1020 |
    1021 |
    1022 | 
    git mv archivo1 archivo2
1023 | git add archivo2
1024 | git push -u origin master
1025 |
    1026 |
    1027 |
    1028 |
    2. 1029 | 1030 |
  2. Renombrar un directorio
    1031 |
    1032 |
    1033 | 
    git mv directorio1 directorio2
1034 | git add directorio2
1035 | git push -u origin master
1036 |
    1037 |
    1038 | 1039 |

    1040 | Ver los cambios que vamos a realizar con la opción -n, el atajo de --dry-run 1041 |

    1042 | 1043 |
    1044 | 
    git mv -n nombre_directorio_antiguo nombre_directorio_nuevo
1045 |
    1046 |
    1047 |
    1048 |
    3. 1049 | 1050 |
  3. Case sensitive
    1051 |
    1052 |

    1053 | Renombrar en sistemas que no distinguen entre mayúsculas y minúsculas, puede dar un error cuando modifiquemos el nombre por caracteres en mayúsculas, por lo que tendríamos que hacer: 1054 |

    1055 | 1056 |
    1057 | 
    git mv directorio1 tempname && git mv tempname Directorio2
1058 |
    1059 |
    1060 | 1061 |

    1062 | Si nuestro sistema no es case sensitive, puede ocurrir que queramos tener dos ficheros que se llaman igual, pero uno emplea mayúsculas y otro minúsculas, y git no nos lo deje incluir. 1063 |

    1064 | 1065 |

    1066 | Por ejemplo, si tenemos TFM.html y tfm.html en local, y añadimos a git uno de ellos, luego no podremos añadir el otro a no ser que configuremos nuestro git como case sensitive: 1067 |

    1068 | 1069 |
    1070 | 
    git config core.ignorecase false
1071 |
    1072 |
    1073 | 1074 |

    1075 | Ahora ya podremos hacer git add con éxito. 1076 |

    1077 | 1078 |

    1079 | La solución viene de Stackoverflow 1080 |

    1081 |
    1082 |
    4. 1083 | 1084 | 1085 | 1086 |
  4. Borrar del repositorio
    1087 |
    1088 |

    1089 | Borrar un archivo del repositorio sin borrarlo del sistema de directorios local: 1090 |

    1091 | 1092 |
    1093 | 
    git rm --cached archivo.org
1094 | 
1095 |
    1096 |
    1097 |
    1098 |
    5. 1099 | 1100 |
  5. Borrar un directorio
    1101 |
    1102 |

    1103 | Para borrar un directorio: 1104 |

    1105 |
    1106 | 
    git rm --cached -r directorio
1107 | 
1108 |
    1109 |
    1110 |
    1111 |
    6. 1112 |
1113 |
1114 | 1115 |
1116 |

12. Actualizar repositorio

1117 |
1118 |

1119 | Si queremos actualizar el repositorio con los cambios que se hayan producido en él, lo haremos con la opción pull: 1120 |

1121 | 1122 |
1123 | 
git pull
1124 |
1125 |
1126 |
1127 |
1128 | 1129 |
1130 |

13. Deshacer cambios

1131 |
1132 |

1133 | Si realizamos un commit pero queremos volver atrás, si no hemos realizado push, es: 1134 |

1135 | 1136 |
1137 | 
git reset --hard HEAD-1
1138 | 
1139 |
1140 |
1141 | 1142 |

1143 | Si hemos realizado el commit lo mejor es hacer revert, tal como explican 1144 |

1145 | 1146 | 1147 | 
1148 | git revert <hash-or-ref>
1149 |
1150 | 1151 |

1152 | Para saber el hash-or-ref se puede consultar la parte de Commits de la página del repo o 1153 | bien con el comando git log --pretty=online. 1154 |

1155 | 1156 |

1157 | Luego hacemos git push para actualizar el repositorio con el cambio revertido. 1158 |

1159 |
1160 |
1161 | 1162 |
1163 |

14. Pull request

1164 |
1165 |

1166 | Haremos un pull request cuando queramos contribuir con nuestros cambios -mejoras, corrección de errores, actualizaciones- a un repositorio que ya existe. 1167 |

1168 | 1169 |

1170 | Por eso, lo primero que tenemos que hacer es crear una copia del proyecto: 1171 |

1172 | 1173 |
1174 | 
git clone ruta-proyecto.git
1175 | 
1176 |
1177 |
1178 | 1179 |

1180 | Luego creamos una rama donde hacer las modificaciones: 1181 |

1182 | 1183 |
1184 | 
1185 | git checkout -b nueva-rama
1186 | 
1187 |
1188 |
1189 | 1190 |

1191 | Al crearla nos movemos a esa rama. Podemos comprobarlo si tenemos el asterisco en la rama deseada: 1192 |

1193 | 1194 |
1195 | 
git branch
1196 |
1197 |
1198 | 1199 |

1200 | Si no estamos ahí, vamos con: 1201 |

1202 |
1203 | 
git checkout nueva-rama
1204 |
1205 |
1206 | 1207 |

1208 | Luego hacemos las modificaciones que sean a nuestros archivos, las añadimos, las comiteamos y las subimos a la rama creada: 1209 |

1210 | 1211 |
1212 | 
git add ruta-nuevos-archivos
1213 | git commit -m "comentario sobre cambios"
1214 | git push -u origin nueva-rama
1215 |
1216 |
1217 | 1218 |

1219 | Comprobamos el estado de git con git status 1220 |

1221 | 1222 |
1223 | 
git status
1224 |
1225 |
1226 | 1227 |

1228 | Si todo está bien, vamos a nuestra copia del proyecto en Github y en la página del repo pondrá que hay una rama sobre la que hacer un pull-request, pinchamos y seguimos los pasos. 1229 |

1230 | 1231 |

1232 | Si no hay discusión, si está todo bien, el administrador lo aprobará y entonces podremos borrar la rama. Nos movemos a master y desde ahí borramos en local y en el servidor: 1233 |

1234 | 1235 |
1236 | 
git checkout master
1237 | git branch -d nueva-rama
1238 | git push origin --delete nueva-rama
1239 | 
1240 |
1241 |
1242 |
1243 |
1244 |
1245 |

15. Borrar rama

1246 |
1247 |

1248 | En local: 1249 |

1250 | 1251 |
1252 | 
git branch -d rama-local
1253 | 
1254 |
1255 |
1256 | 1257 |

1258 | Si no se borra así, con -D 1259 |

1260 | 1261 |
1262 | 
git branch -d rama-local
1263 | 
1264 |
1265 |
1266 | 1267 |

1268 | En remoto:: 1269 |

1270 | 1271 |
1272 | 
git push origin --delete rama-remota
1273 | 
1274 |
1275 |
1276 | 1277 |

1278 | o también: 1279 |

1280 |
1281 | 
git push origin :ramaremota
1282 | 
1283 |
1284 |
1285 |
1286 |
1287 | 1288 |
1289 |

16. Mantener un repositorio forkeado actualizado

1290 |
1291 |

1292 | Añades remoteando como servidor remoto: 1293 |

1294 | 1295 |
1296 | 
git remote add remoteando git://ruta-repositorio.git
1297 | git remote add remoteando https://github.com/cuenta/nombre-repositorio.git
1298 |
1299 |
1300 | 1301 |

1302 | Actualizas remoteando pero sin integrar los cambios 1303 |

1304 |
1305 | 
git fetch upstream
1306 |
1307 |
1308 | 1309 |

1310 | Integras los cambios con la versión local: 1311 |

1312 | 1313 |
1314 | 
git pull upstream master
1315 | 
1316 |
1317 |
1318 |
1319 |
1320 | 1321 |
1322 |

17. Publicación web

1323 |
1324 |

1325 | Si el contenido del proyecto es HTML, podemos utilizar a GitHub como servidor web de nuestro contenido web, a través de la funcionalidad Pages. 1326 |

1327 | 1328 |

1329 | Se puede hacer de dos maneras: 1330 |

1331 |
1332 | 1333 |
    1334 |
  1. Nombre del repositorio
    1335 |
    1336 |

    1337 | Si el nombre del repositorio sigue la estructura "nombre-de-usuarix.github.io", el proyecto que cuelgue de ahí se publicará automágicamente en http://nombre-de-usuarix.github.io 1338 |

    1339 |
    1340 |
    2. 1341 | 1342 |
  2. Rama gh-pages
    1343 |
    1344 |

    1345 | Cualquier repositorio que tenga la rama gh-pages será publicado, y se verá su contenido web. 1346 |

    1347 | 1348 |

    1349 | Por ejemplo, si tenemos un repositorio con nombre mi-proyecto que contiene una web y queremos publicarlo como página web, solo tenemos que crear una nueva rama branch de nuestro proyecto que llamaremos gh-pages: 1350 |

    1351 | 1352 |
    1353 | 
    git checkout -b gh-pages
1354 |
    1355 |
    1356 | 1357 |

    1358 | Luego ponemos ahí todo el contenido de la rama master: 1359 |

    1360 | 1361 |
    1362 | 
    git merge master
1363 |
    1364 |
    1365 | 1366 |

    1367 | Por último subimos a GitHub todo lo que tenemos en la nueva rama: 1368 |

    1369 | 1370 |
    1371 | 
    $ git push -u origin gh-pages
1372 | 
1373 |
    1374 |
    1375 | 1376 |

    1377 | En unos minutos, GitHub lo habrá publicado en una URL del tipo http://nombre-de-usuarix.github.io/mi-proyecto 1378 |

    1379 | 1380 |

    1381 | Si tu repositorio es solo una web, puedes optar por utilizar solo la rama gh-pages en vez de mantener las dos ramas. Para ello tienes que elegir en GitHub qué rama utilizas. 1382 |

    1383 | 1384 |

    1385 | Si mantienes las dos, actualizar la web se puede convertir en algo tedioso si lo haces habitualmente. 1386 |

    1387 | 1388 |

    1389 | Para facilitar la tarea, brettterpstra.com recomienda una solución, puedes editar .git/config y añadir estas líneas a [remote "origin"]: 1390 |

    1391 | 1392 |
    1393 | 
    push = +refs/heads/master:refs/heads/gh-pages
1394 | push = +refs/heads/master:refs/heads/master
1395 |
    1396 |
    1397 | 1398 |

    1399 | Quedando así: 1400 |

    1401 | 1402 |
    1403 | 
    [remote "origin"]
1404 |         fetch = +refs/heads/*:refs/remotes/origin/*
1405 |         url = git@github.com:user/repo.git
1406 |         push = +refs/heads/master:refs/heads/gh-pages
1407 |         push = +refs/heads/master:refs/heads/master
1408 | 
1409 |
    1410 |
    1411 | 1412 |

    1413 | De esta manera, cuando hagas git push lo harás en los dos repos. 1414 |

    1415 |
    1416 |
    3. 1417 |
1418 |
1419 |
1420 |

18. Gitignore

1421 |
1422 |

1423 | https://git-scm.com/docs/gitignore 1424 |

1425 |
1426 |
1427 |
1428 |

19. Problemas

1429 |
1430 |
1431 |
    1432 |
  1. 403 fatal: HTTP request failed
    1433 |
    1434 |

    1435 | http://stackoverflow.com/questions/7438313/pushing-to-git-returning-error-code-403-fatal-http-request-failed 1436 |

    1437 |
    1438 | 
    git remote set-url origin https://yourusername@github.com/user/repo.git
1439 | 
1440 |
    1441 |
    1442 |
    1443 |
    2. 1444 | 1445 |
  2. git: error: src refspec master does not match any
    1446 |
    1447 |

    1448 | http://stackoverflow.com/questions/10568641/git-error-src-refspec-master-does-not-match-any 1449 |

    1450 |
    1451 | 
    git remote rm origin
1452 | git remote set-url origin git@....
1453 | git push -u origin master
1454 |
    1455 |
    1456 |
    1457 |
    3. 1458 | 1459 |
  3. Please, commit your changes or stash them before you can merge.
    1460 |
    1461 |

    1462 | Si alguien o tú mismo en otro equipo ha actualizado el repositorio 1463 | mientras tú trabajabas y te sale este error, sin entrar en las 1464 | opciones con las ramas, tienes tres opciones: 1465 |

    1466 |
    1467 | 1468 |
      1469 |
    1. Comitear el cambio de la forma típica:
      1470 |
      1471 |
      1472 | 
      git commit -m "comentario"
1473 |
      1474 |
      1475 |
      1476 |
      2. 1477 | 1478 |
    2. Reservarlo o depositarlo en una pila o stack con stash:
      1479 |
      1480 |
      1481 | 
      git stash
1482 | 
1483 |
      1484 |
      1485 | 1486 |

      1487 | Ahí puedes hacer push y aparece en orden inverso: 1488 |

      1489 | 1490 |
      1491 | 
      git stash pop
1492 |
      1493 |
      1494 |
      1495 |
      3. 1496 | 1497 |
    3. Descartar los cambios que has hecho
      1498 |
      1499 |
      1500 | 
      git reset --hard
1501 | 
1502 |
      1503 |
      1504 |
      1505 |
      4. 1506 |
    1507 |
    4. 1508 |
1509 |
1510 | 1511 | 1512 |
1513 |

20. Pruebas

1514 |
1515 |

1516 | Try Git 1517 |

1518 |
1519 |
1520 |
1521 |

21. Bibliografía

1522 |
1523 |
1524 |
    1525 |
  1. Algunos recursos
    1526 |
    1527 | 1535 |
    1536 |
    2. 1537 | 1538 |
  2. Git Github Course
    1539 |
    1540 |
    1541 |
    3. 1542 | 1543 |
  3. Cheatsheets
    1544 |
    1545 | 1548 |

    1549 | ===== 1550 |

    1551 |
    1552 |
    4. 1553 |
  4. Cheatsheets
    1554 |
    1555 | 1558 |
    1559 |
    5. 1560 |
1561 |
1562 |
1563 |
1564 |

Validate

1565 |
1566 | 1567 | 1568 | --------------------------------------------------------------------------------