Skip to content

Cómo usar Git

Antonio David Villegas edited this page Jul 22, 2019 · 1 revision

Para una guía muy general puedes consultar esta página.

GIT != GITHUB

Es muy importante tener esto clarísimo desde el primer momento. A lo largo de esta guía vamos a trabajar con dos sistemas relacionados pero que no cumplen el mismo propósito:

  • Git: Controlador de versiones que permite realizar modificaciones a proyectos de forma segura y sorprendentemente bien estructurada.
  • GitHub: Servicio web que permite navegar los repositorios creados usando Git y sus diferentes versiones.

En esta guía vamos a ver cómo trabajar con ambos, ya que estamos usando GitHub para ver los repositorios que hemos creado con Git, pero debes tener siempre en cuenta que no son lo mismo.

INTRODUCCIÓN A GIT

INSTALACIÓN

Para trabajar con Git, lo más importante es tenerlo instalado. Distinguimos entre tres sistemas opertativos:

  • Linux: Sigue este enlace y ejecuta en la terminal las órdenes correspondientes a tu distro.
  • OSX: Sigue este enlace y sigue las instrucciones de instalación.
  • Windows: Sigue este enlace y sigue las instrucciones de instalación.

CREACIÓN DE UN REPOSITORIO

Si creas un repositorio en GitHub te saldrá este mensaje:

…or create a new repository on the command line

   echo "# ejemplo" >> README.md
   git init
   git add README.md
   git commit -m "first commit"
   git remote add origin https://github.com/Usuario/ejemplo.git
   git push -u origin master

Analicémolos paso por paso:

  • echo "# ejemplo" >> README.md → Lo más importante para un repositorio es su archivo README, que es el que va a contener la información esencial sobre su contenido. Esta orden añade el título de tu repositorio a dicho archivo.
  • git init → Crea init un repositorio local en la carpeta en la que estés en ese momento.
  • git add README.md → Añade add el archivo README a tu repo.
    • Te recomendamos (casi obligamos a) que antes de hacer cualquier commit escribas git add . para que tu contribución contenga los cambios hechos en todos los archivos de tu repositorio local.
  • git commit -m "first commit → ¡Es tu primer commit! Los commits son contribuciones que haces al repositorio, añadiendo o eliminando contenido. Puedes hacerlos de dos formas diferentes.
    • git commit -m "Título del commit" → Ponle un título muy corto y claro lo lo más descriptivo posible
    • git commit -m "Título" -m "Descripcción" → Tras un título sencillo, expláyate todo lo que quieras en tu descripción. Como lo tienes que escribir todo en una sola línea, utiliza el carácter de escape \n para hacer un salto de línea y darle un formato medianamente legible.

Hasta este punto hemos estado trabajando con la parte abstracta y local de Git. Si queremos ver nuestros archivos colgados en un repositorio de GitHub tendremos que usar las dos últimas órdenes.

  • git remote add origin https://github.com/Usuario/ejemplo.git → Cuando creamos un repositorio con Git, lo creamos de forma local. Para poder trabajar con GitHub, tenemos que asociarle un repositorio no local remote add y darle el link de dicho repositorio, que en este caso hipotéticos lo hemos llamado https://github.com/Usuario/ejemplo.git. Por último, origin es el nombre que tiene tu repositorio en tu ordenador. Puedes (y deberías) llamar a todos tu repos que vas a subir a GitHub origin para evitar confusiones a la hora de trabajar con otros repos.
  • git push -u origin master → Esto envía push tus cambios a la rama principal master de tu repositorio en GitHub.

¡Felicidades! Ya tienes un repositorio con el que trabajar de forma local y subido a GitHub para que el mundo lo vea. Ahora vamos a ver cómo trabajar con repositorios de otros.

TRABAJAR CON REPOSITORIOS AJENOS

VERSIÓN FÁCIL

EDITAR UNA SECCIÓN DE UN ARCHIVO

Todos los archivos tienen una cabecera con esta estructura:

img

Si pulsas el botón del lápiz podrás editar el documento. Cuando estés de acuerdo con tus cambios, escribe uno buen título y una descripción lo más detallada posible para ellos y, ponle a tu rama un nombre que permita a los administradores identificarla sin tener que entrar a mirar que hay dentro.

img

Con tu rama creada puedes crear una pull request para que los administradores decidan introducir tus cambios. Este proceso se trata un poco más adelante en esta misma págia.

AÑADIR ARCHIVOS

Para añadir archivos al repositorio puedes simplemente arrastrarlos a la carpeta en la que los quieres añadir. Si quieres añadir varias carpetas, asegúrate de que, si vas a subir carpetas que ya existen con nuevos archivos, tengan el mismo nombre.

VERSIÓN COMPLEJA

DESCARGAR EL REPOSITORIO

Hasta ahora hemos visto la orden git push. Vamos a ampliar con la orden git pull.

Imagina que un repositorio es un cajón lleno de carpetas con archivos que estás editando. Cuando has acabado de editarlos, cierras push el cajón y los dejas ahí listos. Cuando abras pull el cajón para seguir trabajando en él puede que otras personas hayan hecho cambios por su cuenta, por lo que la orden git pull te actualiza el repositorio al estado en el que está en ese momento. Es decir, abre el cajón con todos los archivos modificados desde la última vez que se cerró.

Sin embargo, no podemos abrir cajones que no tengamos en nuestro despacho. Para ello existe la orden git clone, que toma un repositorio entero y te lo descarga en el directorio en el que estés en ese momento. Ahora que tienes el repositorio clonado, puedes hacer pull cuando quieras para actualizar su contenido.

Debido a la forma de trabajo y el sistema anti-troll que tiene este repositorio, no se permite hacer cambios directamente a la rama master, por lo que tendrás que crear tu propia rama para poder enviar cambios.

TRABAJAR CON RAMAS

Las ramas son diferentes secciones de trabajo por las que se mueve un proyecto de git. La rama principal y en la que está todo el contenido del repositorio es master y se pueden crear otras ramas para trabajar en partes específicas, como las prácticas de una asignatura o la actualización de los README.

Para poder identificar y controlar más fácilmente los cambios que vas a realizar en el repositorio, crea una rama específica para dichos cambios.

Las ramas se administran con dos órdenes: checkout y branch.

checkout te permite crear ramas y moverte por las ramas de tu repositorio.

  • git checkout -b nombre-rama→ Crea una rama con ese nombre. Ponle un nombre que describa bien qué se va a trabajar en ella y usa los códigos de asignaturas para referirte a ellas.
    • git checkout -b FP-temario
    • git checkout -b CA-maxima
  • git checkout nombre-rama → Cambia a la rama de ese nombre.

branch te permite administrar las ramas que has creado.

  • git branch -v → Muestra todas las ramas creadas en el repositorio.
  • git branch -d nombre-rama → Elimina una rama.
  • git branch -D nombre-rama → Sudo elimina una rama. Usa esta orden sólo si estás completamente seguro de que quieres eliminarla.

LA SECCIÓN PARA ENVIAR LAS RAMAS ESTÁ EN OBRAS, CUANDO HAGAMOS UN PAR DE PRUEBAS LA ESCRIBIREMOS COMPLETAMENTE

PULL REQUESTS

Los cambios que puedes realizar son adiciones o eliminaciones tanto de ficheros como de sus elementos. Para ello puedes pulsar el botón de editar de un archivo y añadir o eliminar las líneas que creas convenientes. Cuando estés seguro de que todos tus cambios son correctos comienza el proceso de aprobación de los cambios, formalmente denominados pull request.

CÓMO REALIZAR UNA PR EXCELENTE

  • Escribe un título sencillo:
  • Escribe una descripción lo más elaborada que puedas:
    • Su extensión debe estar dentro de unos límites razonables.
    • Explica los motivos por los que estás realizando dichos cambios.

Aquí tienes un ejemplo de una PR perfectamente presentada:

img

PROCESAMIENTO DE APROBACIÓN DE UNA PR

  • La PR llega a los administradores
    • Se analiza que los cambios estén en orden:
      • Cumplimiento con las hojas de estilo
      • Cumplimiento con las licencias de terceros
      • Comprobación de errores
    • Se proponen (si se requiriese) cambios a la PR para poder ser aprobada
      • Se inicia una conversación entre el colaborador y los administradores
      • Otros colaboradores pueden proponer cambios u otras soluciones
    • Se acuerda que la PR está lista para ser añadida al repositorio
  • La PR se añade al repositorio