Git y GitHub

¿Por qué usar un sistema de control de

versiones como git?
Nos ayuda a guardar el historial de cambios y crecimiento de los archivos de
nuestro proyecto.
Git funciona como una línea que nos permite regresar a momentos específicos
del código

Comandos básicos de git

¿Qué es Git?
Git es un sistema de control de versiones distribuidos, diseñado por Linus
Torvalds. Está pensado en la eficiencia y la confiabilidad del mantenimiento de
versiones de aplicaciones cuando esta tienen un gran número de archivos de
código fuente.

Git está optimizado para guardar cambios de forma incremental.

Permite contar con un historial, regresar a una versión anterior y agregar

funcionalidades.

Lleva un registro de los cambios que otras personas realicen en los

archivos.

Git fue diseñado para operar en un entorno Linux. Actualmente, es

multiplataforma, es decir, es compatible con Linux, MacOS y Windows.

Características de Git
Git almacena la información como conjunto de archivos

No existen cambios, corrupción en archivos o cualquier alteración sin que

Git lo sepa.

Git y GitHub 1
 Casi todo en Git es local. Es difícil que se necesiten recursos o información
externo, basta con los recursos locales con los que cuenta.

Git cuenta con 3 estados en los que es posible localizar archivos: Staged,
Modified y Committed.

Para qué proyectos sirve Git

Con git se obtiene una mayor eficiencia usando archivos de texto plano, ya que
con archivos binarios no puede guardar solo los cambios, sino que debe volver
a grabar el archivo completo ante cada modificación, por mínima que sea, lo
que hace que incremente demasiado el tamaño del repositorio.

¿Qué es un sistema de control de versiones?

El SCV o VCS es un sistema que registra los cambios realizados sobre un
archivo o conjunto de archivos a lo largo del tiempo, de modo que puedes
llevar el historial del ciclo de vida de un proyecto, comparar cambios a lo largo
del tiempo, ver quién los realiza o revertir el proyecto entero a un estado
anterior.

¿En qué se diferencia de Github?

Github es una plataforma de desarrollo colaborativo para alojar proyectos
utilizando el sistema de control de versiones Git. Se emplea principalmente
para la creación de código fuente de programas de computadora.

Se puede considerar a Github como la rede social de código para los

programadores y en muchos casos es visto como un curriculum vitae, pues
aquí se guarda el portafolio de proyectos de programación.

Características de Github
Github permite alojar proyectos en repositorios de forma gratuita y pública,
pero tiene una forma de pago para privados.

Puede compartir fácilmente tus proyectos.

Permite colaborar para mejorar los proyectos de otros.

Ayuda a reducir significativamente los errores humanos, a tener un mejor

mantenimiento de distintos entornos y a detectar fallos de una forma más
rápida y eficiente.

Git y GitHub 2
 Es la opción perfecta para poder trabajar en equipo en un mismo proyecto.

Ofrece todas las ventajas del sistema de control de versiones Git, pero
también tiene otras herramientas que ayudan a tener un mejor control de
los proyectos.

Instalación de Git y GitBash en Windows

Git y GitHub 3
 Créditos a Angelo Paul Yenque Tume @ayenquet

Git y GitHub 4
 Editores de código, archivo binarios y de
texto plano
Un editor de código o IDE es una herramienta que nos brinda mucha ayuda
para escribir código, algo así como un bloc de notas muy avanzado. Los
editores más populares son VSCode, sublime Text, Atom, pero no es obligatorio
usar algunos de estos para programar.

Tipos de archivos y sus diferencias

Archivo de texto(.txt): Texto plano normal y sin nada especial.

Archivos RTF(.rtf): Podemos guardar texto con diferentes tamaños, estilos y

colores. Pero si lo abrimos desde un editor de código, vamos a ver que es
mucho más complejo que solo el texto plano.

Archivo de Word(.docx): Podemos guardar imágenes y texto con diferentes

tamaños, estilos o colores. Al abrirlo desde un editor de código podemos
ver que es código binario, muy difícil de entender y muy diferente al texto al
que estamos acostumbrados.

Conceptos importantes de Git

Bug: Error en el código

Repository: Donde se almacena todo el proyecto, el cual puede vivir tanto

en local como en remoto. El repositorio guarda un historial de versiones y,
más importante, de la relación de cada versión con la anterior para que
pueda hacerse el árbol de versiones con las diferentes ramas.

Fork: Si en algún momento queremos contribuir al proyecto de otra

persona, o si queremos utilizar el proyecto de otro como el punto de partida
del nuestro. Esto se conoce como “fork”.

Clone: Una vez se decide hacer un fork , hasta ese momento sólo existe en
GitHub. Para poder trabajar en el proyecto, toca clonar el repositorio
elegido al computador personal.

Branch: Es una bifurcación del proyecto que se está realizando para anexar
una nueva funcionalidad o corregir un bug.

Master: Rama donde se almacena la última versión estable del proyecto

que se está realizando. La rama master es la que está en producción en

Git y GitHub 5
 cada momento (o casi) y debería estar libre de bugs. Así, si esta rama está
en producción, sirve como referente para hacer nuevas funcionalidades y/o
arreglar bugs de última hora.

Commit: consiste en subir cosas a la versión local del repositorio. De esta

manera se puede trabajar en la rama de forma local sin tener que modificar
ninguna versión en remoto ni tener que tener la última versión remota, cosa
muy útil en grandes desarrollos trabajados por varias personas.

Push: Consiste en enviar todo lo que se ha confirmado con un commit al

repositorio remoto. Aquí es donde se une nuestro trabajo con el de los
demás.

Checkout: Acción de descargarse una rama del repositorio GIT local (sí, GIT
tiene su propio repositorio en local para poder ir haciendo commits) o
remoto.

Fetch: Actualiza el repositorio local bajando datos del repositorio remoto al

repositorio local sin actualizarlo, es decir, se guarda una copia del
repositorio remoto en el local.

Merge: La acción de merge es la continuación natural del fetch. El merge

permite unir la copia del repositorio remoto con tu repositorio local,
mezclando los diferentes códigos.

Pull: Consiste en la unión del fetch y del merge, esto es, recoge la
información del repositorio remoto y luego mezcla el trabajo en local con
esta.

Diff: Se utiliza para mostrar los cambios entre dos versiones del mismo
archivo.

Introducción al a terminal y línea de

comandos
La línea de comandos nos permite interactuar con nuestra computadora son
necesidad de utilizar una interfaz gráfica.
Recuerda que GitBash usa la ruta /c para dirigirse a C:\ (o /d para dirigirse
a D:\ ) en Windows. Por lo tanto, la ruta del usuario con el que estás trabajando
es /c/Users/Nombre de tu usuario

Git y GitHub 6
 Comandos básicos en la terminal
cd: Nos permite movernos entre las carpetas

cd / : Ir a la ruta principal

cd o cd ~: Ir a la ruta de tu usuario

cd carpeta/subcarpeta: Navegar a una ruta dentro de la carpeta donde

estamos ahora mismo.

cd .. : Regresar una carpeta hacia atrás.

pwd: Nos muestra la ruta de la carpeta en la que te encuentras.

mkdir: Nos permite crear carpetas ejemplo: mkdir nombre_de_la_carpeta.

touch: Nos permite crear archivos ejemplo: touch nombre_de_archivo.txt

rm: Nos permite borrar un archivo o carpeta.

car: Ver el contenido de un archivo ejemplo: cat nombre_de_archivo

ls: Nos permite cambiar ver los archivos de la carpeta donde ahora mismo.

history: Ver los últimos comandos que ejecutamos y un número especial

con el que podemos repetir su ejecución.

! + número: Ejecutar algún comando con el número que nos muestra el

comando history.

clear: Para limpiar la terminal.

Crear un repositorio de Git y haz tu primer

commit
Para crear un nuevo repositorio utilizando el sistema de control de versiones
debemos posicionarnos en la carpeta raíz de nuestro proyecto. Pero antes
debemos configurar git para poder añadir nuestro usuario y correo para que
sepan quien realizo los cambios al código.

git config --global user.name "tu nombre"

git config --global user.email "tu@correo.com"

Git y GitHub 7
 Estando en la carpeta del proyecto usamos el siguiente comando para iniciar el
repositorio.

git init

Se crea el repositorio.
Para añadir archivos usamos.

git add nombre_del_archivo.txt

git add . (para añadir varios archivos)

Envía el archivo al Staged.

Para revisar el estatus utilizamos.

git status

Este comando nos permite ver el estado, si es requerido agregar al Staged o si

se requiere commit.

Para realizar el commit se utiliza

git commit -m "comentario"

En caso de hayas cometido un error se puede utilizar estos comandos .

Para eliminar el archivo del Staged(ram).

git rm --cached nombre_del_archivo.txt

Para eliminar del repositorio

git rm nombre_del_archivo.txt

Analizar cambios en los archivos de tu

proyecto

Git y GitHub 8
 El comando

git show

nos muestra los cambios que han existido sobre un archivo y es muy útil para
detectar cuándo se produjeron ciertos cambios.

Para ver la diferencia entre una versión y otro usamos el comando.

git diff commitA commitB

¿Qué es el staging?
Es el lugar donde se guardan temporalmente los cambios, para luego ser
llevados definitivamente al repositorio. El repositorio es el lugar donde se
guardan todos los registros de los cambios realizados a los archivos.

¿Qué es el área de staging?

Se puede ver como un limbo donde nuestro archivos están por ser enviados al
repositorio o ser regresados a la carpeta del proyecto.

Cómo funciona el staging y el repositorio: ciclo

básico de trabajo en git
El flujo de trabajo básico en git es algo así:

1. Modificas una serie de archivos en tu directorio de trabajo.

2. Preparas los archivos, añadiéndolos a tu área de preparación (staging).

Git y GitHub 9
 3. Confirmas los cambios (commit), lo que toma los archivos tal y como están
en el área de preparación y almacena esa copia instantánea de manera
permanente en tu directorio de git.

Veamos a detalle las 3 secciones principales que tiene un proyecto en git.

Working directory
El working directory es una copia de una versión del proyecto. Estos archivos
se sacan de la base de datos comprimida en el directorio de git y se colocan en
el disco para que los puedas usar o modificar.

Staging area
Es un área que almacena información acerca de lo que va a ir en tu próxima
confirmación. A veces se le denomina índice (index).

.git directory (repository)

En el repository se almacenan los metadatos y la base de datos de los objetos
para tu proyecto. Es la parte más importante de git (carpeta .git) y es lo que se
copia cuando clonas un repositorio desde otra computadora.

Ciclo de vida o estado de lso archivos en git

Cuando trabajamos con git, nuetros archivos puede vivir y moverse entre 4
diferentes estados.

Archivos tracked
Son los archivos que viven dentro de git, no tienen cambios pendientes y sus
últimas actualizaciones han sido guardadas en el repositorio gracias a los
comandos git add y git commit .

Archivos staged
Son archivos en staging. Viven dentro de git y hay registro de ellos porque han
sido afectados por el comando git add , aunque no sus últimos cambios. Git ya
sabe de la existencia de estos últimos cambios, pero todavía no han sido
guardados definitivamente en el repositorio porque falta ejecutar el
comando git commit .

Archivos unstaged

Git y GitHub 10
 Entiéndelos como archivos “tracked
pero
unstaged”. Son archivos que viven dentro de git pero no han sido afectados
por el comando git add ni mucho menos por git commit . Git tiene un registro de
estos archivos, pero está desactualizado, sus últimas versiones solo están
guardadas en el disco duro.

Archivos untracked
Son archivos que NO viven dentro de git, solo en el disco duro. Nunca han sido
afectados por git add , así que git no tiene registros de su existencia.

Comandos para mover archivos entre los estados de

Git
Estos son los comandos más importantes que debes conocer:

Git status
git status nos permite ver el estado de todos nuestros archivos y carpetas.

Git add
git addnos ayuda a mover archivos del untracked o unstaged al estado staged.
Podemos usar git nombre-del-archivo-o-carpeta para añadir archivos y carpetas
individuales o git add -A para mover todos los archivos de nuestro proyecto
(tanto untrackeds como unstageds).

Git reset HEAD

Nos ayuda a sacar archivos del estado staged para devolverlos a su estado
anterior. Si los archivos venían de unstaged, vuelven allí. Y lo mismo se venían
de untracked.

Git commit
Nos ayuda a mover archivos de unstaged a tracked. Esta es una ocasión
especial, los archivos han sido guardados o actualizados en el repositorio. Git
nos pedirá que dejemos un mensaje para recordar los cambios que hicimos y
podemos usar el argumento m para escribirlo ( git commit -m "mensaje" ).

Git rm

Git y GitHub 11
 Este comando necesita alguno de los siguientes argumentos para poder
ejecutarse correctamente:

git rm --cached : mueve los archivos que le indiquemos al estado untracked.

: elimina los archivos de git y del disco duro. Git guarda el

git rm --force

registro de la existencia de los archivos, por lo que podremos recuperarlos

si es necesario (pero debemos usar comandos más avanzados).

¿Qué es branch(rama) y cómo funciona

un Merge en Git?
Una rama o branch es una versión del código del proyecto sobre el que estás
trabajando. Estas ramas ayudan a mentener el orden en el control de versiones
y manipular el código de forma segura.

Clases de branches o ramas en Git

Estas son las ramas base de un proyecto en Git:

1. Rama main (Master)

Git y GitHub 12
 Por defecto, el proyecto se crea en una rama llamada Main (anteriormente
conocida como Master). Cada vez que añades código y guardas los cambios,
estás haciendo un commit, que es añadir el nuevo código a una rama. Esto
genera nuevas versiones de esta rama o branch, hasta llegar a la versión actual
de la rama Main.

2. Rama development
Cuando decides hacer experimentos, puedes generar ramas experimentales
(usualmente llamadas development), que están basadas en alguna rama main,
pero sobre las cuales puedes hacer cambios a tu gusto sin necesidad de
afectar directamente al código principal.

3. Rama hotfix
En otros casos, si encuentras un bug o error de código en la rama Main (que
afecta al proyecto en producción), tendrás que crear una nueva rama (que
usualmente se llaman bug fixing o hot fix) para hacer los arreglos necesarios.
Cuando los cambios estén listos, los tendrás que fusionar con la rama Main
para que los cambios sean aplicados. Para esto, se usa un comando
llamado Merge, que mezcla los cambios de la rama que originaste a la rama
Main.
Todos los commits se aplican sobre una rama. Por defecto, siempre
empezamos en la rama Main (pero puedes cambiarle el nombre si no te gusta)
y generamos nuevas ramas, a partir de esta, para crear flujos de trabajo
independientes.

Cómo crear un branch o rama en Git

El comando git branch permite crear una rama nueva. Si quieres empezar a
trabajar en una nueva función, puedes crear una rama nueva a partir de la rama
master con

git branch new_branch

Una vez creada, puedes usar

git checkout new_branch

para cambiar a esa rama.

Git y GitHub 13
 Recuerda que todas tus versiones salen de la rama principal o Master y de allí
puedes tomar una versión específica para crear otra rama de versiones.

Cómo hacer merge

Producir una nueva rama se conoce como Checkout. Unir dos ramas lo
conocemos como Merge.
Cuando haces merge de estas ramas con el código principal, su código se
fusiona originando una nueva versión de la rama master (o main) que ya tiene
todos los cambios que aplicaste en tus experimentos o arreglos de errores.
Podemos generar todas las ramas y commits que queramos. De hecho,
podemos aprovechar el registro de cambios de Git para producir ramas, traer
versiones viejas del código, arreglarlas y combinarlas de nuevo para mejorar el
proyecto.

Solo ten en cuenta que combinar estas ramas (hacer “merge”) puede generar
conflictos. Algunos archivos pueden ser diferentes en ambas ramas. Git es muy
inteligente y puede intentar unir estos cambios automáticamente, pero no
siempre funciona. En algunos casos, somos nosotros los que debemos resolver
estos conflictos a mano.

Volver en el tiempo en nuestro repositorio

utilizando reset y checkout
El comando

git checkout + id del commit + nombre_del_archivo

nos permite viajar en el tiempo. Podemos volver a cualquier versión anterior de

un archivo específico o incluso del proyecto entero. Esta también es la forma
de crear ramas y moverse entre ellas.
Para volver a la rama más actualizada usamos

git checkout + master(nombre de la rama) + nombre_del_archivo

Existe una forma de hacerlo un poco más “rudo” usando el comando

Git y GitHub 14
 git reset

Con este comando no solo volvemos en el tiempo sino que borramos los
cambios que hicimos después de este commit.

Cómo usar Git Reset

Para volver a commits previos, borrando los cambios realizados desde ese
commit, podemos utilizar:

git reset id --soft [SHA 1]: elimina los cambios hasta el staging area

git reset id --mixed [SHA 1]: elimina los cambios hasta el working area

git reset id --hard [SHA 1]: regresa hasta el commit del [SHA-1]Donde el
SHA-1 es el identificador del commit

Git reset vs. Git rm

Git reset y git rm son comandos con utilidades muy diferentes, pero se pueden
confundir muy fácilmente.

git rm
Este comando nos ayuda a eliminar archivos de Git sin eliminar su historial del
sistema de versiones. Esto quiere decir que si necesitamos recuperar el archivo
solo debemos “viajar en el tiempo” y recuperar el último commit antes de
borrar el archivo en cuestión.

Recuerda que git rm no puede usarse así nomás. Debemos usar uno de los
flags para indicarle a Git cómo eliminar los archivos que ya no necesitamos en
la última versión del proyecto:

: Elimina los archivos de nuestro repositorio local y del área de

git rm --cached

staging, pero los mantiene en nuestro disco duro. Básicamente le dice a Git
que deje de trackear el historial de cambios de estos archivos, por lo que
pasaran a un estado untracked .

: Elimina los archivos de Git y del disco duro. Git siempre guarda
git rm --force

todo, por lo que podemos acceder al registro de la existencia de los

archivos, de modo que podremos recuperarlos si es necesario (pero
debemos usar comandos más avanzados).

Git y GitHub 15
 git reset
Este comando nos ayuda a volver en el tiempo. Pero no como git checkout que
nos deja ir, mirar, pasear y volver. Con git reset volvemos al pasado sin la
posibilidad de volver al futuro. Borramos la historia y la debemos sobreescribir.
No hay vuelta atrás.
Este comando es muy peligroso y debemos emplearlo solo en caso de
emergencia. Recuerda que debemos usar alguna de estas dos opciones:
Hay dos formas de utilizar git reset : con el argumento --hard , borrando toda la
información que tengamos en el área de staging (y perdiendo todo para
siempre). O, un poco más seguro, con el argumento --soft , que mantiene allí los
archivos del área de staging para que podamos aplicar nuestros últimos
cambios pero desde un commit anterior.

: Borramos todo el historial y los registros de Git pero

git reset --soft

guardamos los cambios que tengamos en Staging, así podemos aplicar las
últimas actualizaciones a un nuevo commit.

: Borra todo. Todo todito, absolutamente todo. Toda la

git reset --hard

información de los commits y del área de staging se borra del historial.

¡Pero todavía falta algo!

: Este es el comando para sacar archivos del área de staging.

git reset HEAD

No para borrarlos ni nada de eso, solo para que los últimos cambios de
estos archivos no se envíen al último commit, a menos que cambiemos de
opinión y los incluyamos de nuevo en staging con git add , por supuesto.

La relevancia de estos comandos

Imagina el siguiente caso:
Hacemos cambios en los archivos de un proyecto para una nueva
actualización. Todos los archivos con cambios se mueven al área de staging
con el comando git add . Pero te das cuenta de que uno de esos archivos no
está listo todavía. Actualizaste el archivo, pero ese cambio no debe ir en el
próximo commit por ahora.
¿Qué podemos hacer?

Bueno, todos los cambios están en el área de Staging, incluido el archivo con
los cambios que no están listos. Esto significa que debemos sacar ese archivo
de Staging para poder hacer commit de todos los demás.

Git y GitHub 16
 ¡Al usar git rm lo que haremos será eliminar este archivo completamente de git!
Todavía tendremos el historial de cambios de este archivo, con la eliminación
del archivo como su última actualización. Recuerda que en este caso no
buscábamos eliminar un archivo, solo dejarlo como estaba y actualizarlo
después, no en este commit.
En cambio, si usamos git reset HEAD , lo único que haremos será mover estos
cambios de Staging a Unstaged. Seguiremos teniendo los últimos cambios del
archivo, el repositorio mantendrá el archivo (no con sus últimos cambios, pero
sí con los últimos en los que hicimos commit) y no habremos perdido nada.
Conclusión: Lo mejor que puedes hacer para salvar tu puesto y evitar un
incendio en tu trabajo es conocer muy bien la diferencia y los riesgos de todos
los comandos de Git.

Flujo de trabajo básico en Git

Cuando se empieza a trabajar en un entorno local, el proyecto vive únicamente
en tu computadora. Esto significa que no hay forma de que otros miembros del
equipo trabajen en él.

Para solucionarlo, utilizamos los servidores remotos: un nuevo esto que deben
seguir nuestros archivos para conectar y trabajar con equipos de cualquier
parte del mundo.
Estos servidores remotos pueden estar alojados en GitHub, GitLab, BitBucket,
entre otros. Lo que van a hacer es guardar el mismo repositorio que tienes en
tu computadora y darnos una URL con la que todos podremos acceder a lso
archivos del proyecto. Así, el equipo podrá descargarlos, hacer cambios y
volverlos a enviar al servidor remoto para que otras personas vena los
cambios, comparen sus versiones y creen nuevas propuestas para el proyecto.

Comandos para trabajar remoto con Git

Nos permite descargar los archivos de la última versión de la rama principal y
todo el historial de cambios en la carpeta .git.

git clone url_del_servidor_remoto

Luego de hacer git add y git commit debemos ejecutar este comando para
mandar los cambios al servidor remoto.

Git y GitHub 17
 git push

Usamos para traer actualizaciones del servidor remoto y guardar en nuestro

repositorio local(en caso de que hayan).

git fetch

También usamos el comando git merge con servidores remotos. Lo

necesitamos para combinar los últimos cambios del servidor remoto y nuestro
directorio de trabajo.

git merge

Básicamente git fecht y git merge al mismo tiempo es.

git pull

Comandos adicionales

Introducción a las ramas o branches de

Git
Las ramas(branches) son la forma de hacer cambios en nuestro proyecto sin
afectar al flujo de trabajo de la rama principal. Esto porque trabajar una parte
muy especifica de la aplicación o simplemente experimentar.
La cabecera o HEAD representa la rama y el commit de esa rama donde
estamos trabajando. Por defecto, esta cabecera aparecerá en el último commit
de nuestra rama principal.

Cómo funcionan las ramas en Git

Las ramas son la manera de hacer cambios en nuestro proyecto sin afectar el
flujo de trabajo de la rama principal. Esto porque queremos trabajar una parte
muy específica de la aplicación.
Con este comando se genera una nueva rama.

Git y GitHub 18
 git branch nombre_de_la_rama

Con este comando se puede saltar de una rama a otra.

git checkout nombre_de_la_rana

Para generar un rama y movernos a ella automáticamente, usar git branch y git
checkout al mismo tiempo.

git checkout -b rama

Para llegar a cualquier commit sin importar la rama, ya que identificamos el id

del tag, eliminando el historial de los commit posteriores al tag selccionado.

git reset id del commit

Para llevarnos a cualquier commit son borrar los commit posteriores al tag
seleccionado.

git checkout rama o id del commit

Fusión de ramas con Git y GitHub

El comando git merge nos permite crear un nuevo commit con la combinación
de dos ramas o branches.

Cómo usar git merge

Primero nos posicionamos el rama principal o rama en la que queremos.

Creamos un nuevo commit en la rama master combinando los cambios de otra

rama.

git checkout master(rama pricipal)

git merge main(otra rama)

Comandos adicionales

Git y GitHub 19
 Resolución de conflictos al hacer un
marge
Git nunca borra nada, a menos que nosotros se lo indiquemos. Cuando
usamos los comandos git merge o git checkout estamos cambiando de rama o
creando un nuevo commit, no borrando ramas ni commits (recuerda que
puedes borrar commits con git reset y ramas con git branch -d ).
Git es muy inteligente y puede resolver algunos conflictos automáticamente:
cambios, nuevas líneas, entre otros. Pero algunas veces no sabe cómo resolver
estas diferencias, por ejemplo, cuando dos ramas diferentes hacen cambios
distintos a una misma línea.
Esto lo conocemos como conflicto y lo podemos resolver manualmente. Solo
debemos hacer el merge, ir a nuestro editor de código y elegir si queremos
quedarnos con alguna de estas dos versiones o algo diferente. Algunos
editores de código como Visual Studio Code nos ayudan a resolver estos
conflictos sin necesidad de borrar o escribir líneas de texto, basta con hacer
clic en un botón y guardar el archivo.
Recuerda que siempre debemos crear un nuevo commit para aplicar los
cambios del merge. Si Git puede resolver el conflicto, hará commit
automáticamente. Pero, en caso de no pueda resolverlo, debemos solucionarlo
y hacer el commit.
Los archivos con conflictos por el comando git merge entran en un nuevo estado
que conocemos como Unmerged. Funcionan muy parecido a los archivos en
estado Unstaged, algo así como un estado intermedio entre Untracked y
Unstaged. Solo debemos ejecutar git add para pasarlos al área de staging y git
commit para aplicar los cambios en el repositorio.

Cómo revertir un merge

Si nos hemos equivocado y queremos cancelar el merge, debemos usar el
siguiente comando:

git merge --abort

Conflictos en repositorios remotos

Git y GitHub 20
 Al trabajar con otras personas, es necesario utilizar un repositorio remoto.­-Para
copiar el repositorio remoto al directorio de trabajo local, se utiliza el
comando git clone <url> , y para enviar cambios al repositorio remoto se utiliza git
push.-Para actualizar el repositorio local se hace uso del comando git fetch ,
luego se debe fusionar los datos traídos con los locales usando git merge .

Para traer los datos y fusionarlos a la vez, en un solo comando, se usa git
pull .­- Para crear commits rápidamente, fusionando git add y git commit -m "" ,

usamos git commit -am "" .­- Para generar nuevas ramas, hay que posicionarse
sobre la rama que se desea copiar y utilizar el comando git branch <nombre> .

Para saltar entre ramas, se usa el comando git checkout <branch> ­- Una vez
realizado los cambios en la rama, estas deben fusionarse con git merge .

El merge ocurre en la rama en la que se está posicionado. Por lo tanto, la

rama a fusionar se transforma en la principal.

Los merges también son commits.

Los merges pueden generar conflictos, esto aborta la acción y pide que
soluciones el problema manualmente, aceptando o rechazando los cambios
que vienen.

Cambios en GitHub: de master a main

El escritor Argentino Julio Cortázar afirma que las palabras tienen color y peso.
Por otro lado, los sinónimos existen por definición, pero no expresan lo mismo.
Feo no es lo mismo que desagradable, ni aromático es lo mismo que oloroso.
Por lo anterior podemos afirmar que los sinónimos no expresan lo mismo, no
tienen el mismo “color” ni el mismo “peso”.
Sí, esta lectura es parte del curso profesional de Git & GitHub. Quédate
conmigo.

Desde el 1 de octubre de 2020 GitHub cambió el nombre de la rama principal:

ya no es “master” -como aprenderás en el curso- sino main.
Este derivado de una profunda reflexión ocasionada por el movimiento
#BlackLivesMatter.
La industria de la tecnología lleva muchos años usando términos como master,
slave, blacklist o whitelist y esperamos pronto puedan ir desapareciendo.

Y sí, las palabras importan.

Git y GitHub 21
 Por lo que de aquí en adelante cada vez que escuches a Freddy mencionar
“master” debes saber que hace referencia a “main”

Uso de GitHub
GitHub es una plataforma que nos permite guardar repositorios de Git que
podamos usar como servidores remotos y ejecutar algunos comandos de
forma visual e interactiva.
Creamos una cuenta de GitHub para poder crear o importar repositorios.

El README.md es el archivo que veremos por defecto al entrar a un repositorio.

Es una buena práctica configurarlo para describir el proyecto, los
requerimientos y las instrucciones que debemos seguir para contribuir
correctamente.
Para clonar un repositorio desde GitHub(o cualquier otro servidor remoto)
debemos copiar la URL y ejecutar el comando.

git clone + URL

Cómo conectar un repositorio de GitHub a nuestro

documento local
Si queremos conectar el repositorio de GitHub con nuestro repositorio local,
que creamos usando el comando git init , debemos ejecutar las siguientes
instrucciones:

Guardar la URL del repositorio de GitHub con el nombre de origin

git remote add origin URL

Verificar que la URL se haya guardado correctamente:

git remote
git remote -v

Traer la versión del repositorio remoto y hacer merge para crear

un commit con los archivos de ambas partes. Podemos usar git fetch y git

Git y GitHub 22
 merge o solo git pull con el flag -allow-unrelated-histories :

git pull origin master --allow-unrelated-histories

Por último, ahora sí podemos hacer git push para guardar los cambios de
nuestro repositorio local en GitHub:

git push origin master

Cómo autenticarte en GitHub 2022

Cómo funcionan las lleves públicas y

privadas
Las llaves públicas y privadas, conocidas también como cifrado asimétrico de
un solo camino, sirven para mandar mensajes privados entre varios nodos con
la lógica de que firmas tu mensaje con una llave pública vinculada con una
llave privada que puede leer el mensaje.
Las llaves públicas y privadas nos ayudan a cifrar y descifrar nuestros archivos
de forma que los podamos compartir sin correr el riesgo de que sean
interceptados por personas con malas intenciones.

Cómo funciona un mensaje cifrado con llaves

públicas y privadas
Ambas personas deben crear su llave pública y privada.

Ambas personas pueden compartir su llave pública a las otras partes

(recuerda que esta llave es pública, no hay problema si la “interceptan”).

La persona que quiere compartir un mensaje puede usar la llave pública de

la otra persona para cifrar los archivos y asegurarse que solo puedan ser
descifrados con la llave privada de la persona con la que queremos
compartir el mensaje.

El mensaje está cifrado y puede ser enviado a la otra persona sin

problemas en caso de que los archivos sean interceptados.

Git y GitHub 23
 La persona a la que enviamos el mensaje cifrado puede emplear su llave
privada para descifrar el mensaje y ver los archivos.

Configura tus llaves SSH en local

En este ejemplo, aprenderemos cómo configurar nuestras llaves SSH en local.

Cómo generar tus llaves SSH

1. Generar tus llaves SSH**
Recuerda que es muy buena idea proteger tu llave privada con una contraseña.

ssh-keygen -t rsa -b 4096 -C "tu@email.com"

2. Terminar de configurar nuestro sistema.

En Windows y Linux:

Encender el “servidor” de llaves SSH de tu computadora:

eval $(ssh-agent -s)

Añadir tu llave SSH a este “servidor”:

ssh-add ruta-donde-guardaste-tu-llave-privada

En Mac:

Encender el “servidor” de llaves SSH de tu computadora:

eval "$(ssh-agent -s)"

Si usas una versión de OSX superior a Mac Sierra (v10.12), debes crear o
modificar un archivo “config” en la carpeta de tu usuario con el siguiente
contenido (ten cuidado con las mayúsculas):Host *

AddKeysToAgentyes
UseKeychainyes

Git y GitHub 24
 IdentityFile ruta-donde-guardaste-tu-llave-privada

Añadir tu llave SSH al “servidor” de llaves SSH de tu computadora (en caso

de error puedes ejecutar este mismo comando pero sin el argumento -K):

ssh-add-K ruta-donde-guardaste-tu-llave-privada

Aporte creado por: Juan Luis Rojas

Conexión a GitHub con SHH

La creación de las SHH es necesario solo una vez por cada computadora.

Luego de crear nuestras llaves SSH podemos entregarle la llave pública a

GitHub para comunicarnos de forma segura y sin necesidad de escribir nuestro
usuario y contraseña todo el tiempo.
Para esto debes entrar a la Configuración de Llaves SSH en GitHub, crear una
nueva llave con el nombre que le quieras dar y el contenido de la llave pública
de tu computadora.
Ahora podemos actualizar la URL que guardamos en nuestro repositorio
remoto, solo que, en vez de guardar la URL con HTTPS, vamos a usar la URL
con SSH:

git remote set-url origin ssh-del-repositorio-en-github

Comandos para copiar la llave SSH:

Mac:

pbcopy < ~/.ssh/id_rsa.pub

Windows (Git Bash):

clip < ~/.ssh/id_rsa.pub

Linux (Ubuntu):

Git y GitHub 25
 cat ~/.ssh/id_rsa.pub

Tags y versiones en Git y GitHub

Los tags o etiquetas nos permiten asignar versiones a los commits con
cambios más importantes o significativos de nuestro proyecto.

Comandos para trabajar con etiquetas

Para crear un nuevo tag y asignarlo a un commit:

git tag -a nombre_del_tag -m "comentario" id_del_commit

Para borrar un tag en el repositorio local:

git tag -d nombre_del_tag

Lista de tags de nuestro repositorio:

git tag

git show-ref --tags

Para publicar un tag en el repositorio remoto:

git push origin --tags

Borrar un tag del repositorio:

git tag -d nombre_del_tag

Borrar un tag del repositorio remoto:

git push origin :refs/tags/nombre_del_tag

Comando adicional

Git y GitHub 26
 Para mostrar la historia del repositorio pero comprimida.

git log --all --graph --decorate --oneline

Manejo de ramas en GitHub

Las ramas nos permiten hacer cambios a nuestros archivos sin modificar la
versión principal.

Comandos para manejo de ramas en GitHub

Para saber cuales son las ramas:

git branch

Para crear una rama:

git branch nombre_de_la_rama

Movernos a otra rama:

git checkout nombre_de_la_rama

Publicar una rama local al repositorio remoto:

git push origin nombre_de_la_rama

Para ver gráficamente nuestro entorno y flujo de trabajo local con Git utilizamos
el comando gitk. Gitk fue el primer visor gráfico que se desarrolló para ver de
manera gráfica el historial de nuestro repositorio de Git.

gitk

Si no te funciona el comando gitk es posible que no lo tengas instalado por

defecto. Para instalar gitk debemos ejecutar los siguientes comandos:

sudo apt-get update

Git y GitHub 27
 sudo apt-get install gitk

Configurar múltiples colaboradores en un

repositorio de GitHub
Por defecto, cualquier persona puede clonar o descargar tu proyecto desde
GitHub, pero no pueden crear commits, ni ramas. Esto quiere decir que pueden
copiar tu proyecto pero no colaborar con él. Existen varias formas de
solucionar esto para poder aceptar contribuciones. Una de ellas es añadir a
cada persona de nuestro equipo como colaborador de nuestro repositorio.

Cómo agregar colaboradores en Github

Solo debemos entrar a la configuración de colaboradores de nuestro
proyecto. Se encuentra en: Repositorio > Settings > Collaborators

Ahí, debemos añadir el email o username de los nuevos colaboradores.

Si, como colaborador, agregaste erróneamente el mensaje del commit, lo

puedes cambiar de la siguiente manera:

Hacer un commit con el nuevo mensaje que queremos, esto nos abre el
editor de texto de la terminal:

Git y GitHub 28
 git commit —amend

Corregimos el mensaje.

Traer el repositorio remoto.

git pull origin master

Ejecutar el cambio.

git push --set-upstream origin master

Flujo de trabajo profesional: Haciendo

merge de ramas de desarrollo a master
Para poder desarrollar software de manera óptima y ordenada, necesitamos
tener un flujo de trabajo profesional, que nos permita trabajar en conjunto sin
interrumpir el trabajo de otros desarrolladores. Una buena práctica de flujo de
trabajo sería la siguiente:

Crear ramas

Asignar una rama a cada programador

El programador baja el repositorio con git pull origin master

El programador cambia de rama

El programador trabaja en esa rama y hace commits

El programador sube su trabajo con git push origin #nombre_rama

El encargado de organizar el proyecto baja, revisa y unifica todos los

cambios

Flujo de trabajo profesional con Pull

requests

Git y GitHub 29
 En un entorno profesional normalmente se bloquea la rama master, y para
enviar código a dicha rama pasa por un code review y luego de su aprobación
se unen códigos con los llamados merge request.
Para realizar pruebas enviamos el código a servidores que normalmente los
llamamos staging develop (servidores de pruebas) luego de que se realizan las
pruebas pertinentes tanto de código como de la aplicación estos pasan al
servidor de producción con el ya antes mencionado merge request.

Los PR (pull requests) son la base de la colaboración a proyectos Open Source,

si tienen pensando colaborar en alguno es muy importante entender esto y ver
cómo se hace en las próximas clases. Por lo general es forkear el proyecto,
implementar el cambio en una nueva rama, hacer el PR y esperar que los
administradores del proyecto hagan el merge o pidan algún cambio en el
código o commits que hiciste.

Proceso de un pull request para trabajo en

producción:
Un pull request es un estado intermedio antes de enviar el merge.

El pull request permite que otros miembros del equipo revisen el código y
así aprobar el merge a la rama.

Permite a las personas que no forman el equipo, trabajar y colaborar con

una rama.

La persona que tiene la responsabilidad de aceptar los pull request y hacer

los merge tienen un perfil especial y son llamados DevOps

Utilizando Pull Requests en GitHub

Pull request es una funcionalidad de Github (en Gitlab llamada merge request y
en Bitbucket push request), en la que un colaborador pide que revisen sus
cambios antes de hacer merge a una rama, normalmente master (ahora
conocida como main).

Al hacer un pull request, se genera una conversación que pueden seguir los
demás usuarios del repositorio, así como autorizar y rechazar los cambios.

Cómo se realiza un pull request

Se trabaja en una rama paralela los cambios que se desean.

Git y GitHub 30
 git checkout -b <rama>

Se hace un commit a la rama.

git commit -am '<Comentario>'

Se suben al remoto los cambios.

git push origin <rama>

En GitHub se hace el pull request comparando la rama master con la rama

del fix.

Uno, o varios colaboradores revisan que el código sea correcto y dan

feedback (en el chat del pull request).

El colaborador hace los cambios que desea en la rama y lo vuelve a subir al

remoto (automáticamente jala la historia de los cambios que se hagan en la
rama, en remoto).

Se aceptan los cambios en GitHub.

Se hace merge a master desde GitHub.

Importante: Cuando se modifica una rama, también se modifica el pull request.

Creando un Fork, contribuyendo a un

repositorio
Los forks o bifurcaciones son una característica única de GitHub en la que se
crea una copia exacta del estado actual de un repositorio directamente en
GitHub. Este repositorio podrá servir como otro origen y se podrá clonar (como
cualquier otro repositorio). En pocas palabras, lo podremos utilizar como un
nuevo repositorio git cualquiera
Un fork es como una bifurcación del repositorio completo. Comparte una
historia en común con el original, pero de repente se bifurca y pueden aparecer
varios cambios, ya que ambos proyectos podrán ser modificados en paralelo y
para estar al día un colaborador tendrá que estar actualizando su fork con la
información del original.

Git y GitHub 31
 Al hacer un fork de un poryecto en GitHub, te conviertes en dueñ@ del
repositorio fork, puedes trabajar en este con todos los permisos, pero es un
repositorio completamente diferente que el original, teniendo solamente alguna
historia en común (como crédito al creado o creadora original).
Los forks son importantes porque es la manera en la que funciona el open
source, ya que, una persona puede no ser colaborador de un proyecto, pero
puede contribuír al mismo, haciendo mejor software que pueda ser utilizado
por cualquiera.

Cómo se hace un fork remoto desde consola en

GitHub
Al hacer un fork, GitHub sabe que se hizo el fork del proyecto, por lo que se le
permite al colaborador hacer pull request desde su repositorio propio.
Cuando trabajas en un proyecto que existe en diferentes repositorios remotos
(normalmente a causa de un fork), es muy probable que desees poder trabajar
con ambos repositorios. Para esto, puedes generar un remoto adicional desde
consola.

git remote add <nombre_del_remoto> <url_del_remoto>

Ejemplo:

git remote add upstream https://github.com/freddier/hyperblog

Al crear un remoto adicional, podremos hacer pull desde el nuevo origen. En

caso de tener permisos, podremos hacer fetch y push.

git pull <remoto> <rama>

Ejemplo:

git pull upstream master

Este pull nos traerá los cambios del remoto, por lo que se estará al día en el
proyecto. El flujo de trabajo cambia, en adelante se estará trabajando

Git y GitHub 32
 haciendo pull desde el upstream y push al origin para pasar a hacer pull
request.

git pull upstreammastergit push originmaster

Haciendo deployment a un servidor

Deploy es el proceso que permite enviar al servidor uno o varios archivos. Este
servidor puede ser de prueba, desarrollo o producción.
En el siguiente ejemplo veremos cómo se realiza el deployment de un
documento en un servidor web básico.

Pasos para hacer deployment en un servidor web:

Entrar a la capeta de los archivos del servidor.

Copiar link en clone, elegir entre HTTPS o SSH del repositorio a

contribuir.En la carpeta deseada se clona el repositorio:

git clone url

Deploy:

Realizar cambios y commit en GitHub.

Traer al Repositorio local las actualizacion para el servidor en la capeta de

los archivos del servidor.

git pull ramaRemota main

Nota: Siempre se debe proteger el archivo .git. Dependiendo del software para
el servidor web, existen diferentes maneras. La conexión entre GitHub y el
servidor se puede realizar mediante: Travis (pago) o Jenkis (Open source).

Ignorar archivos en el repositorio con

.gitignore
No todos los archivos que agregas a un proyecto deberían ir a un repositorio.
Por ejemplo, cuando tienes un archivo donde están tus contraseñas que

Git y GitHub 33
 comúnmente tienen la extensión .env o cuando te estás conectando a una base
de datos; son archivos que nadie debe ver.
Por diversas razones, no todos los archivos que agregas a un proyecto
deberían guardarse en un repositorio. Esto es porque hay archivos que no todo
el mundo debería de ver, y hay archivos que al estar en el repositorio ralentizan
el proceso de desarrollo (por ejemplo: los binary large objects, blob, que tardan
en descargarse).
Para que no se suban estos archivos no deseados se puede crear un archivo
con el nombre .gitignore en la raíz del repositorio con las reglas para los
archivos que no se deberían subir: Aquí puedes ver la sintaxis de los .gitignore.

Las razones principales para tomar la decisión de no agregar un archivo a un

repositorio son:

Es un archivo con contraseñas (normalmente con la extensión .env)

Es un blob (binary large object, objeto binario grande), mismos que son
difíciles de gestionar en git.

Son archivos que se generan corriendo comandos, por ejemplo la carpeta

node_modules, que genera npm al correr el comando npm install

Readme.md es un exelente práctica

README.md es el lugar donde se explica de qué trata el proyecto, cómo utilizarlo
y demás información que se considere que se deba conocer cualquier persona
que vaya a trabajar de alguna forma con el proyecto..Los archivos README son
escritos en un lenguaje llamado markdown, por eso la extensión .md, mismo
que es un estándar de escritura en diversos sitios (como Platzi, Wikipedia y el
mismo GitHub). Aquí puedes ver las reglas de markdown.
Los README.md pueden estar en todas las carpetas, pero el más importante es
el que se encuentra en la raíz. Este documento ayuda a que los colaboradores
sepan información relevante del proyecto, módulo o sección. Puedes crear
cualquier archivo con la extensión .md pero solo los README.md los mostrará
por defecto GitHub.

Tu sitio web público con GitHub Pages

GitHub tiene un servicio de hosting gratis llamado GitHub Pages. Con él,
puedes tener un repositorio alojado en GitHub y hacer que el contenido se

Git y GitHub 34
 muestre en la web en tiempo real.
Este es un sitio para nuestros proyectos donde lo único que tenemos que hacer
es tener un repositorio alojado. En la página, podemos seguir las instrucciones
para crear este repositorio

Pasos para subir un repositorio a GitHub Pages

Debemos tomar la llave SSH y hacer un git clone #SSHexample en mi
computador local (Home).

Luego, accederemos a la carpeta nueva que aparece en nuestra máquina

local.

Creamos un nuevo archivo que se llame index.html

Guardamos los cambios, hacemos un git pull y seguido de esto un git

push a master .

Vamos a las opciones de settings de este repositorio y, en la parte de abajo,

en la columna Github Pages, configuramos el source o fuente para que
traiga la rama master

Guardamos los cambios.

Después de esto, podremos ver nuestro trabajo en la web como si tuviéramos

nuestro propio servidor.

Git Rebase: reorganizando l trabajo

realizado
Rebase es el proceso de mover o combinar una secuencia de confirmaciones
en una nueva confirmación base. La reorganización es muy útil y se visualiza
fácilmente en el contexto de un flujo de trabajo de ramas de funciones. El
proceso general se puede visualizar de la siguiente manera.

Git y GitHub 35
 Para hacer un rebase en la rama feature de la rama master, correrías los
siguientes comandos:

git checkout feature

git rebase master(rama)

Esto trasplanta la rama feature desde su locación actual hacia la punta de la

rama master:

Ahora, falta fusionar la rama feature con la rama master

git checkoutmastergit rebase feature

# No reorganices el historial público

Git y GitHub 36
 Nunca debes reorganizar las confirmaciones una vez que se hayan enviado a
un repositorio público. La reorganización sustituiría las confirmaciones antiguas
por las nuevas y parecería que esa parte del historial de tu proyecto se hubiera
desvanecido de repente.
El comando rebase es **_una mala práctica, sobre todo en repositorios
remotos. Se debe evitar su uso, pero para efectos de práctica te lo vamos a
mostrar, para que hagas tus propios experimentos. Con rebase puedes recoger
todos los cambios confirmados en una rama y ponerlos sobre otra.
Ejemplo:

# Cambiamos a la rama que queremos traer los cambios

git checkout experiment
# Aplicamos rebase para traer los cambios de la rama que queremos
git rebase master

Git Stash: Guardar cambios en memoria y

recuperarlos.
El stashed nos sirve para guardar cambios para después, Es una lista de
estados que nos guarda algunos cambios que hicimos en Staging para poder
cambiar de rama o branch sin perder el trabajo que todavía no guardamos en
un commit
Ésto es especialmente útil porque hay veces que no se permite cambiar de
rama, ésto porque tenemos cambios sin guardar, no siempre es un cambio lo
suficientemente bueno como para hacer un commit, pero no queremos perder
ese código en el que estuvimos trabajando.
El stashed nos permite cambiar de ramas, hacer cambios, trabajar en otras
cosas y, más adelante, retomar el trabajo con los archivos que teníamos en
Staging, pero que podemos recuperar, ya que los guardamos en el Stash.

git stash
El comando git stash guarda el trabajo actual del Staging en una lista diseñada
para ser temporal llamada Stash, para que pueda ser recuperado en el futuro.
Para agregar los cambios al stash se utiliza el comando:

Git y GitHub 37
 git stash

Podemos poner un mensaje en el stash, para asi diferenciarlos en git stash list
por si tenemos varios elementos en el stash. Esto con:

git stash save "mensaje identificador del elemento del stashed"

Obtener elelmentos del stash

El stashed se comporta como una Stack de datos comportándose de manera
tipo LIFO (del inglés Last In, First Out, «último en entrar, primero en salir»), así
podemos acceder al método pop.
El método pop recuperará y sacará de la lista el último estado del stashed y lo
insertará en el staging area, por lo que es importante saber en qué branch te
encuentras para poder recuperarlo, ya que el stash será agnóstico a la rama o
estado en el que te encuentres. Siempre recuperará los cambios que hiciste
en el lugar que lo llamas.
Para recuperar los últimos cambios desde el stash a tu staging area utiliza el
comando:

git stash pop

Para aplicar los cambios de un stash específico y eliminarlo del stash:

git stashpopstash@{<num_stash>}

Para retomar los cambios de una posición específica del Stash puedes utilizar
el comando:

git stash apply stash@{<num_stash>}

Donde el <num_stash> lo obtienes desden el git stash list

Listado de elementos en el stash

Para ver la lista de cambios guardados en Stash y así poder recuperarlos o
hacer algo con ellos podemos utilizar el comando:

Git y GitHub 38
 git stash list

Retomar los cambios de una posición específica del Stash || Aplica los cambios
de un stash específico

Crear una rama con el stash

Para crear una rama y aplicar el stash más reciente podemos utilizar el
comando

git stash branch<nombre_de_la_rama>

Si deseas crear una rama y aplicar un stash específico (obtenido desde git stash

list ) puedes utilizar el comando:

git stash branch nombre_de_rama stash@{<num_stash>}

Al utilizar estos comandos crearás una rama con el nombre <nombre_de_la_rama> ,

te pasarás a ella y tendrás el stash especificado en tu staging area.

Eliminar elementos del stash

Para eliminar los cambios más recientes dentro del stash (el elemento 0),
podemos utilizar el comando:

git stash drop

Pero si, en cambio, conoces el índice del stash que quieres borrar (mediante git

stash list ) puedes utilizar el comando:

git stash drop stash@{<num_stash>}

Donde el <num_stash> es el índice del cambio guardado.

Si, en cambio, deseas eliminar todos los elementos del stash, puedes utilizar:

git stash clear

Git y GitHub 39
 Consideraciones:
El cambio más reciente (al crear un stash) SIEMPRE recibe el valor 0 y los
que estaban antes aumentan su valor.

Al crear un stash tomará los archivos que han sido modificados y

eliminados. Para que tome un archivo creado es necesario agregarlo al
Staging Area con git add [nombre_archivo] con la intención de que git
tenga un seguimiento de ese archivo, o también utilizando el comando git
stash -u (que guardará en el stash los archivos que no estén en el staging).

Al aplicar un stash este no se elimina, es buena práctica eliminarlo.

Git Clean: limpiar tu proyecto de archivos

no deseados
Mientras estamos trabajando en un repositorio podemos añadir archivos a él,
que realmente no forma parte de nuestro directorio de trabajo, archivos que no
se deberían de agregar al repositorio remoto.
El comando clean actúa en archivos sin seguimiento, este tipo de archivos son
aquellos que se encuentran en el directorio de trabajo, pero que aún no se han
añadido al índice de seguimiento de repositorio con el comando add .

git clean

La ejecución del comando predeterminado puede producir un error. La

configuración global de Git obliga a usar la opción force con el comando para
que sea efectivo. Se trata de un importante mecanismo de seguridad ya que
este comando no se puede deshacer.

Revisar que archivos no tienen seguimiento.

git clean --dry-run

Eliminar los archivos listados de no seguimiento.

git clean -f

Git y GitHub 40
 Git clean tiene muchísimas opciones adicionales, que puedes explorar al ver
su documentación oficial.

Git cherry-pick: traer commits viejos al

head de un branch
`
Git Cherry-pick es un comando que permite tomar uno o varios commits de
otra rama o branch sin tener que hacer un merge completo. Así, gracias a
cherry-pick, podríamos aplicar los commits relacionados con nuestra
funcionalidad en la rama master sin necesidad de hacer un merge.
Para demostrar cómo utilizar git cherry-pick, supongamos que tenemos un
repositorio con el siguiente estado de rama:

a -b - c - d Master
\
e - f - g Feature

El uso de git cherry-pick es sencillo y se puede ejecutar de la siguiente

manera:

git checkout master

En este ejemplo, commitSha es una referencia de confirmación. Puedes

encontrar una referencia de confirmación utilizando el comando git log. En este
caso, imaginemos que queremos utilizar la confirmación ‘f’ en la rama master.
Para ello, primero debemos asegurarnos de que estamos trabajando con esa
rama master.

git cherry-pick f

Una vez ejecutado, el historial de Git se verá así:

a -b - c - d - f Master
\
e - f - g Feature

Git y GitHub 41
 La confirmación f se ha sido introducido con éxito en la rama de funcionalidad

Atención
Cherry-pick es una mala práctica porque significa que estamos
reconstruyendo la historia, usa cherry-pick con sabiduría. Si no sabes lo que
estás haciendo, mejor evita emplear este comando.

Git Reset y Reflog: úsese en casos de

emergencia
Git guarda todos los cambios aunque decidas borrarlos, al borrar un cambio lo
que estás haciendo sólo es actualizar la punta del branch, para gestionar éstas
puntas existe un mecanismo llamado registros de referencia o reflogs …La
gestión de estos cambios es mediante los hash’es de referencia (o ref ) que son
apuntadores a los commits…Los recoges registran cuándo se actualizaron las
referencias de Git en el repositorio local (sólo en el local), por lo que si deseas
ver cómo has modificado la historia puedes utilizar el comando:

git reflog

Muchos comandos de Git aceptan un parámetro para especificar una

referencia o “ref”, que es un puntero a una confirmación sobre todo los
comandos:

git checkout Puedes moverte sin realizar ningún cambio al commit exacto de
la ref

git checkout eff544f

git reset : Hará que el último commit sea el pasado por la ref , usar este
comando sólo si sabes exactamente qué estás haciendo

git reset --hard eff544f # Perderá todolo quese encuentraen stagingye

nel Working directoryyse moveráel headal commit eff544f

git reset --soft eff544f

Git y GitHub 42
 #Te recuperará todos los cambios que tengas diferentesal commit
#eff544f, los agregaráal staging areay
#moveráel headal commit eff544f

git merge : Puedes hacer merge de un commit en específico, funciona igual

que con una branch, pero te hace el merge del estado específico del
commit mandado

git checkout master

git merge eff544f

#Fusionaráen un nuevo commitla historiade master con el
#momento específicoen elque vive

¿Qué pasa cuando todo se rompe y no sabemos qué está pasando? Con git reset

HashDelHEAD nos devolveremos al estado en que el proyecto funcionaba.

git reset --soft HashDelHEAD te mantiene lo que tengas en staging ahí.

git reset --hard HashDelHEAD resetea absolutamente todo incluyendo lo que

tengas en staging.

Atención
es una mala práctica, no deberías usarlo en ningún momento. Debe ser
git reset

nuestro último recurso.

Reconstruir commits en Git con amend

Remendar un commit con amend puede modificar el commit más reciente
(enmendar) en la misma rama. Lo ejecutamos así:

git add -A # Para hacer uso de amend los archivos deben de estar en stagi
ng
git commit --amend # Remendar último commit

Este comando sirve para agregar archivos nuevos o actualizar el commit

anterior y no generar commits innecesarios. También es una forma sencilla

Git y GitHub 43
 de editar o agregar comentarios al commit anterior porque abrirá la consola
para editar este commit anterior.

Atención
Usar amend es una mala práctica, sobre todo cuando ya se ha hecho push o
pull al repositorio remoto. Al momento de hacer amend con algún commit que
esté en remoto, va a generar un conflicto que se va a arreglar haciendo
un commit adicional y se perderá el beneficio del amend.

Buscar en archivos y commits de Git con

Grep y log
A medida que nuestro proyecto en Git se hace más grande, vamos a querer
buscar ciertas cosas.
Por ejemplo: ¿Cuántas veces en nuestro proyecto utilizamos la palabra color?
Para buscar, empleamos el comando git grep color y nos buscará en todo el
proyecto los archivos en donde está la palabra color.

Con git grep -n color nos saldrá un output el cual nos dirá en qué línea está lo
que estamos buscando.

Con git grep -c color nos saldrá un output el cual nos dirá cuántas veces se
repite esa palabra y en qué archivo.

Si queremos buscar cuántas veces utilizamos un atributo de HTML lo

hacemos con git grep -c "<p>" .

Para buscar en la historia de los commits se usa.

git log -S "palabra que queremos buscar"

La letra S es mayuscula.

Comandos y recursos colaborativos en Git

y GitHub
A continuación veremos una lista de comandos colaborativos para facilitar el
trabajo remoto en GitHub:

Git y GitHub 44
 git shortlog -sn : muestra cuantos commit han hecho cada miembro del equipo.

: muestra cuantos commit han hecho cada miembro del

git shortlog -sn --all

equipo, hasta los que han sido eliminados.

: muestra cuantos commit ha hecho cada miembro,

git shortlog -sn --all --no-merge

quitando los eliminados sin los merges.

git blame ARCHIVO : muestra quien hizo cada cosa línea por línea.

git COMANDO --help :muestra como funciona el comando.

: muestra quien hizo cada cosa línea por

git blame ARCHIVO -Llinea_inicial,linea_final

línea, indicándole desde qué línea ver. Ejemplo -L35,50.

git branch -r : se muestran todas las ramas remotas.

git branch -a : se muestran todas las ramas, tanto locales como remotas.

Recuerda que para aprender bien Git y GitHub no basta con leer y ver videos
hay que practicar para aprender bien esta tecnología.

No pares de aprender!

Comandos más utilizados (Resumidos)

Git y GitHub 45