PDF de programación - Píldora de Git

Píldora de Git - UV (GIM)

Cristóbal Belda Pérez

Índice
- ¿Qué es Git y qué es GitHub?
- Pasos previos
- Nomenclatura y conceptos básicos
- Flujo de trabajo
- Trabajar con GitHub
- Caso práctico
- Extras (usos, alternativas, ...)
- Links de interés

¿Git & GitHub?

¿Qué es Git y qué es GitHub?

Git es un software de control de versiones (SCM) diseñado pensando en la
eficiencia y confiabilidad del mantenimiento de versiones de aplicaciones cuando
éstas tienen un gran número de archivos de código fuente.

Grosso modo, podemos decir que nos permite conservar nuestro código fuente de
forma segura, así como agilizar y clarificar nuestra forma de trabajar en él. Esto se
acentúa cuando, además, trabajamos en un equipo.

¿Qué es Git y qué es GitHub?

GitHub es una plataforma de desarrollo colaborativo de software para alojar
proyectos utilizando el sistema de control de versiones (SCM) Git. Brinda
herramientas muy útiles para el trabajo en equipo dentro un proyecto.

Pasos previos

Pasos previos

Instalación de herramientas:

Git

https://git-scm.com/download/

VSCode (opcional)

https://code.visualstudio.com/download

Pasos previos

Creación de cuentas:

GitHub

https://github.com/

Nomenclatura y Conceptos

Nomenclatura y Conceptos

Comandos de consola

Usaremos el cliente de consola Git para realizar las operaciones y los comandos
necesarios.

Una vez instalado el cliente (las distros de Linux lo suelen llevar integrado), puedes
usar las distintas opciones (actualizar cambios, copiar repositorio en tu máquina, ir
a una versión del repositorio, ...) escribiendo en consola:

$ git [option]

Nomenclatura y Conceptos

Repositorio (repo)

Un repositorio es la unidad básica. La forma más fácil de imaginarlo es como la
carpeta donde se encuentra nuestro proyecto.

En él tendremos nuestro código, podremos hacer una copia local (repositorio local)
desde la cual podremos actualizar y subir cambios al repositorio remoto, y un largo
etc.

Nomenclatura y Conceptos

Repositorio (repo)

remote

github.com/cristobal/mi-proyecto

local/directory/mi-proyecto

local

Nomenclatura y Conceptos

Rama (branch)

Una rama es una versión paralela del repositorio. Por defecto, la versión principal
del repositorio se aloja en la rama master. En ella “debería” ofrecerse una versión
estable del proyecto. Las distintas ramas almacenan también en el repositorio sin
afectar las unas a las otras.

Un ejemplo de uso sería la resolución de un bug del proyecto o utilizar una rama
para el desarrollo y dejar la master para sacar versiones nuevas y estables.

Nomenclatura y Conceptos

Rama (branch)

mi-proyecto

development

master

debug

Nomenclatura y Conceptos

Rama (branch)

Nomenclatura y Conceptos

Clone

Cuando nos clonamos un repositorio, significa que estamos “copiando” un
repositorio remoto en nuestra máquina, obteniendo así un repositorio local que
siempre estará apuntando al remoto.

$ git clone https://github.com/cristobal/mi-proyecto

Para ver dónde apunta nuestro repositorio local podemos ejecutar:

$ git remote show origin

Nomenclatura y Conceptos

Commit

Entendemos commit como un conjunto de cambios que se hacen al repositorio.

Imaginemos que modificamos una línea de código de un archivo de nuestro
repositorio. La forma de actualizarlo es hacer un commit de ese cambio.

Antes de hacerlo, hemos de ver qué cambios han surgido en nuestro repo local
comparándolo con el repo remoto. Después añadimos los cambios y finalmente
hacemos el commit (empaquetamos los cambios).

Nomenclatura y Conceptos

Commit

Comprobar si hay diferencias entre local y remoto:

$ git status

Nomenclatura y Conceptos

Commit

Añadir (todos) mis cambios para ser commiteados y checkear:

$ git add .

$ git status

Nomenclatura y Conceptos

Commit

Finalmente
empaquetamos los
cambios añadidos en
un commit.

$ git commit -m
“info sobre los
cambios”

Nomenclatura y Conceptos

Push

Cuando hacemos un push significa que estamos “empujando” el paquete de
cambios (el commit) al repositorio remoto.

En el caso de que estemos en la rama ejemplo del repo local, los cambios serán
actualizados en la rama ejemplo del repo remoto.

$ git push

Nomenclatura y Conceptos

Pull

Para actualizar tu repo local al commit más nuevo. Se ejecuta el pull en el directorio
de trabajo para “bajar y fusionar” los cambios remotos.

Si el repositorio local está actualizado, la consola mostrará un

“Already up-to-date”

$ git pull

Nomenclatura y Conceptos

Push / Pull

Se puede dar el caso en el que existan conflictos. Esto ocurre cuando se intenta
hacer un push a un repo que no tenemos actualizado en local. Para ello,
deberíamos hacer un pull del cambio que no tenemos en local, generar un
commit de nuevo y hacer un push de él (habiendo solucionado los conflictos).

Nomenclatura y Conceptos

Push / Pull

Caso 1: Todo ha ido bien. El repo se actualiza.

$ git push

Caso 2: ∄ conflictos. Pero otrx compañerx ha hecho push
antes que tú. Esto implica:

1.
2.
3.

$ git pull
$ git commit -m “merge with latest changes”
$ git push

Caso 3: ∃ conflictos. El código que pretendes “empujar” el repo
entra en contradicción con el del último commit.

1.
2.
3.
4.
5.

$ git pull
-- resolver conflictos (visibles en tu IDE) --
$ git add .
$ git commit -m “solved merge conflicts”
$ git push

Nomenclatura y Conceptos

Fork

Un fork es una copia personal en tu cuenta del repositorio de otro usuario. Los
forks nos permiten hacer cambios libremente de un proyecto sin afectar el original.

Esta copia permanecerá adjunta al original permitiendo remitir los cambios a éste
mediante un mecanismo llamado pull-request.

También es posible mantener tu fork up-to-date actualizándose con los últimos
cambios del original.

Nomenclatura y Conceptos

Pull-request

Un pull request es un conjunto de cambios propuestos a un repositorio por un
usuario y aceptado o rechazado por otro usuario colaborador de ese repositorio.

Cada pull request tiene su propio hilo de discusión.

Nomenclatura y Conceptos

Merge

Hacer un merge implica compilar los cambios de una branch (en el mismo
repositorio o en un fork) y aplicarlos en otro.

Suele suceder normalmente cuando se hace un pull request (los cambios
propuestos del fork se “mergean” en el repositorio original).

Nomenclatura y Conceptos

Init

Este comando crea un repositorio Git vacío, lo que se traduce en un directorio
./git con sus subdirectorios y archivos de plantillas.

$ git init

Nomenclatura y Conceptos

.gitignore

Podría darse el caso de que no quisiéramos subir todos nuestros archivos locales
al repositorio remoto. Por ejemplo, si se trata de algo que nunca se va a ver
modificado, o una carpeta con dependencias instaladas del proyecto, etc.

El archivo donde reflejamos esto se llama .gitignore (sí, con un ‘.’ delante) y,
generalmente se añade en el directorio root del repositorio. Aquí tenéis ejemplos
de este archivo según el lenguaje en el que esté implementado vuestro
proyecto/repositorio.

Flujo de trabajo

Flujo de trabajo: Ejemplo

2 desarrolladorxs (A y B) están colaborando en un proyecto open-source de
Facebook llamado FBNotifications.

facebook/FBNotifications

A

B

Flujo de trabajo: Ejemplo

A está segurísimx de que sus últimos cambios en local son correctos por lo que
procede a añadirlos a un commit y hacer un push directamente al repositorio.

Staging area (index)

facebook/FBNotifications

$ git add .

$ git commit / push

A

Flujo de trabajo: Ejemplo

Al pasar los tests del commit del repositorio, el manager de lxs desarrolladores
descubre que hay un bug causado por un bucle infinito en el código de A, por
lo que le pide a B que lo solucione.

Flujo de trabajo: Ejemplo

Al pasar los tests del commit del repositorio, el manager de lxs desarrolladores
descubre que hay un bug causado por un bucle infinito en el código de A, por
lo que le pide a B que lo solucione.

?

rí a B

a

é h

¿ Q u

Flujo de trabajo: “Solución” de B

$ git pull

facebook/FBNotifications

-- Se deshace el bucle infinito --

Staging area (index)

facebook/FBNotifications

$ git add .

$ git commit / push

B

B

Flujo de trabajo: Solución (posterior) del Manager

Se instala en el equipo una forma nueva de trabajar:

Siempre y cuando se deba hacer cambios en el repositorio, se hará mediante
pull request.

n
?

á
r
e
b
e
r A y B

Flujo de trabajo: Solución (posterior) del Manager

Se instala en el equipo una forma nueva de trabajar:

Siempre y cuando se deba hacer cambios en el repositorio, se hará mediante
pull request.

é d
e
c

¿ Q u
h

a

Flujo de trabajo: Solución (posterior) del Manager

A/FBNotifications

facebook/FBNotifications

B/FBNotifications

fork

fork

1. A y B se hacen un fork cada unx del
repositorio para hacer commit de sus
cambios sin afectar al original.

A

B

Flujo de trabajo: Solución (posterior) del Manager

A/FBNotifications

facebook/FBNotifications

B/FBNotifications

fork

fork

pull request

pull request

2. Para poder actualizar el repo
original, A y B deberán crear pull
request, que a su vez deberán ser
aprobados por otros componentes
del equipo.

A

B

Trabajar con GitHub

GitHub: Sistemas de documentación

README.md

Este archivo es “renderizado” por el propio GitHub. Utiliza el lenguaje markdown
(.md) de escritura. En estos archivos se suele encontrar información sobre el
repositorio, forma de instalar y ejecutar el proyecto una vez clonado, problemas
encontrados, etc.

GitHub: Sistemas de documentación

README.md

GitHub: Sistemas de documentación

Wiki del repositorio

La wiki de un repositorio la utilizamos para desarrollar una documentación mucho
más amplia sobre el proyecto. En ella podríamos incluso añadir desde la
planificación y el diseño hasta una demostración gráfica de pruebas funcionales,
un resultado de carga de peticiones, etc.

Puede contener documentos tanto en markdown como en asciidoc (utilizados para
el mismo fin).

Gi