Taller:
Git _
Sección 1 Sección 2 Sección 3 Sección 4
Git Basics Estrategia recursive Resolución de GitHub
Conflictos
Conocer qué es Git, sus Entender el Aprender a resolver Conocer GitHub como
estados y componentes funcionamiento de la conflictos en Git plataforma de
básicos. estrategia recursive desarrollo colaborativo
y los elementos
necesarios para su
utilización.
Desafío Branching I: Demostración: Desafío Branching II: Desafío GitHub:
Fast-forward Recursive strategy Merge conflict Fork y pull request
Git Basics
¿Qué es Git?
Git es un software de control de versiones, gratuito y de código abierto diseñado
para manejar proyectos de todos los tamaños con rapidez y eficiencia.
Control de Versiones
● Recuperar una versión anterior de nuestro proyecto.
● Mantener registro histórico de los cambios realizados al proyecto e información
de quién los realizó.
● Ayudar a encontrar en qué momento se implementó un cambio que produjo
errores.
¿Quién utiliza Git?
Estados
Luego de haber inicializado Git, nuestros archivos se pueden encontrar en uno de los
siguientes estados.
1. Modified
2. Staged
3. Committed
Esto da lugar a las tres secciones más importantes de un proyecto Git.
Las tres secciones más importantes
Working Staging .git directory
Directory Area (Repository)
Checkout the project
Stage Fixes
Commit
Activación de Conceptos
Commit Checksum Merge
Head Branch Master
● En Git, la mayoría del trabajo se realizar de manera local.
● Es decir, no necesito conexión a internet para utilizar Git.
● No es lo mismo que GitHub.
● Toda la información de versionamiento se encuentra en la carpeta .git
● Puedo subir mi proyecto a un servidor de repositorios a través de remotes.
● Un proyecto puede tener más de un remote.
● Si así lo requerimos, cada remote puede apuntar a un servidor distinto (GitHub, GitLab,
Bitbucket, etc.)
● Al inicializar Git obtendremos -por defecto- un branch llamado master.
Git Basic Workflow
El flujo básico de Git es descrito al pasar por las tres secciones principales:
● Modificamos uno o varios archivos y guardamos los cambios.
● Agregamos los cambios a stage para ser commiteados.
● Generamos un nuevo commit.
Git Basic Workflow
Modified
git add
Staged
git commit
Committed
Git Branches
Desafío Branching I:
Fast-Forward
Desafío Branching I: Fast-Forward
1. Descargar el proyecto base.
2. Inicializar Git dentro del proyecto.
3. Agregar los archivos a stage y luego generar nuestro primer commit.
Desafío Branching I: Fast-Forward
Implementar: Al hacer click en la imagen debemos ser redirigidos a GitHub
4. Para eso crearemos una nueva rama de desarrollo e implementaremos la funcionalidad ahí.
git checkout -b development
Desafío Branching I: Fast-Forward
5. Ahora, posicionados en nuestra rama development, implementaremos la funcionalidad:
<a href="[Link] target="blank">
<img src="[Link]
alt="octocat">
</a>
Desafío Branching I: Fast-Forward
6. Guardamos los cambios.
7. Ejecutamos git status para saber en qué estado se encuentra proyecto.
8. Agregamos los cambios a stage para ser commiteados.
9. Generamos un nuevo commit.
10. Volvemos a la rama master.
Desafío Branching I: Fast-Forward
¿Existe la imagen en la rama master?
11. Vamos a integrar los cambios realizados en development a la rama master.
¿Existe el link a la rama master?
Análisis del Desafío
Al momento de realizar el commit en development y luego volver a master lo más
importante es darnos cuenta que nuestra rama development se encuentra un commit
delante de master.
Es decir, los cambios implementados no se encuentran en master.
Análisis del Desafío
Como mencionamos con anterioridad, en este punto tenemos dos caminos:
1. Descartar los cambios de la rama development
git branch -D development
2. Integrar los cambios de la rama development a master
git merge master
El camino escogido fue el de implementar los cambios a través de merge.
¿Qué información obtendremos
del merge realizado?
> git merge development
Updating 1acb730..62d980e
Fast-forward
[Link] | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Fast-forward
Corresponde al tipo de merge que se ejecuta cuando se cumple que:
La rama que queremos integrar corresponde a un descendiente directo de nuestra rama
principal.
Dicho de otra forma:
El último commit de la rama master es ancestro directo del commit en la rama
development.
git log --graph
* commit 62d980eef9a6826128825bf62e85243d35f48355 (development)
| Author: Juan Pablo Cuevas <[Link]@[Link]>
| Date: Wed Oct 24 12:35:09 2018 -0300
|
| add link to index image
* commit 1acb730ae71e2a2c71089999cd4a7eb40b830db2
Author: Juan Pablo Cuevas <[Link]@[Link]>
Date: Web Oct 24 12:32:59 2018 -0300
initial commit
¿Siempre un merge se implementa
a través de fast-forward?
No.
Fast-forward es la estrategia de merge -por defecto- cuando nuestra rama secundaria es
descendiente directo de la rama principal y no hay inconsistencias ni objeciones con respecto
al merge.
En otras situaciones, obtendremos un comportamiento diferente.
¿Existen otras estrategias
además de fast-forward?
Sí.
Dentro de ellas podemos destacar la estrategia recursive.
Estrategia recursive
Demostración
Al crear la rama development estamos generando un descendiente directo de master.
Todos los commits que generemos en development seguirán siendo generados a partir de una
descendencia directa.
Al volver a master y generar un nuevo commit, perdemos la descendencia directa.
Cuando queremos generar un merge, y no existe descendencia directa, Git generará un nuevo
commit que posee 2 ancestros:
1. El commit de la rama principal
2. El commit de la rama secundaria
Este commit recibe el nombre de merge commit.
Podemos modificar el comentario o utilizar el que existe por defecto.
> git merge style
Merge made by the ´recursive´ strategy.
[Link] | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
La estrategia utilizada recibe el nombre de recursive.
git log --graph
Resolución de Conflictos
Existe un tercer escenario donde obtendremos un comportamiento diferente:
Manipular un mismo archivo en dos ramas distintas y luego realizar un merge.
¿Qué sucede si modificamos
el mismo archivo en dos ramas distintas?
Desafío Branching II:
Merge conflict
Desafío Branching II: Merge conflict
1. En la rama master crear y moverse a un branch nuevo llamado feature_one.
2. En el branch feature_one modificar el texto del botón en [Link].
<button type="button" class="btn">
<a href="[Link] target="_blank">Click aquí para
ir a GitHub!</a>
</button>
Desafío Branching II: Merge conflict
3. Guardar los cambios, agregar el archivo a stage y generar un commit.
4. Volver a la rama master.
5. Modificar el texto del botón en [Link].
<button type="button" class="btn">
<a href="[Link] target="_blank">Haz click
aquí</a>
</button>
Desafío Branching II: Merge conflict
6. Guardar los cambios, agregar el archivo a stage y generar un commit.
7. Realizar un merge de feature_one a master.
Análisis y resolución del desafío
El mensaje obtenido es evidente:
“Merge automático falló; soluciona los conflictos y commitea el resultado”
git status
Ambos commits modificaron [Link]
A partir de aquí tenemos dos caminos:
1. Abortar el merge. git merge --abort
2. Solucionar el conflicto y realizar un nuevo commit.
Anatomía de un conflicto
Siempre un conflicto tendrá la siguiente estructura:
<<<<<<< HEAD
< Contenido de la rama principal >
=======
< Contenido de la rama secundaria >
>>>>>>> nombre_rama_secundaria
Solucionando el conflicto
Vamos a abrir el archivo en Visual Studio Code.
Este editor nos entrega, por defecto, una herramienta para solucionar conflictos de manera
amigable.
Utilizando esta herramienta, podemos escoger entre:
● Accept Current Change: Mantener el contenido de la rama actual.
● Accept Incoming Change: Mantener el contenido de la rama secundaria.
● Accept Both Changes: Mantener ambos contenidos.
● Compare Changes: Comparar los contenidos en ventas nuevas.
Vamos a aceptar los cambios de la rama secundaria
Damos clic en Accept Incoming Change
Hemos solucionado el conflicto, ahora sólo debemos:
● Guardar los cambios.
● Agregar el archivo a stage.
● Generar un nuevo commit.
git log --graph
GitHub
¿Qué es GitHub?
Plataforma de desarrollo colaborativo que nos permite almacenar y gestionar proyectos Git.
Existen diversas plataformas para este propósito, entre ellas podemos descatar:
● GitHub
● GitLab
● Bitbucket
¿Control de versiones?
Nos permite mantener registro de los cambios realizados a un archivo, o a un conjunto de
archivos, en el tiempo.
Git vs GitHub
Git GitHub
Software de versionamiento que registra Plataforma de desarrollo colaborativo
cambios en el tiempo que nos permite almacenar y gestionar
proyectos Git
Se instala y funciona de manera local en Debemos crear una cuenta en la
nuestro computador plataforma web
No necesitamos conexión a internet Necesitamos conexión a internet
Working Staging Local Remote
Directory Area Repository Repository
git add
git commit
git push
git fetch
git checkout
git merge
La comunicación entre nuestro repositorio local y el servidor
se realiza a través de la implementación de remotes.
Remotes
Corresponden a direcciones que apuntan a servidores donde podremos, entre otras
funcionalidades:
● Almacenar y gestionar nuestro proyecto.
● Trabajar de manera colaborativa.
● Compartir el código de nuestro proyecto.
Agregando un remote
Para agregar un remote lo primero que debemos hacer es crear el repositorio en la
plataforma que decidamos utilizar.
Para este ejemplo utilizaremos GitHub.
Ahora podemos agregar -en nuestro repositorio local- el remote que apunte a este servidor.
git remote add nombre_del_remoto url_del_remoto
Por convención un remote único y principal suele llamarse origin.
Podemos mantener o modificar este nombre, nosotros lo llamaremos GitHub.
git remote add github git@[Link]:DesafioLatam/[Link]
¡Listo!
Nuestro repositorio local tiene un remote que apunta a GitHub
¿Puedo tener más de un remote?
Sí.
Puedes agregar, renombrar o eliminar tantos remotes como desees.
Cada remote puede apuntar a una URL distinta, sin restricción alguna.
Remotes
Cuando necesitemos enviar el contenido de nuestro repositorio local a uno remoto, lo
haremos utilizando la instrucción push
git push -u nombre_del_remoto nombre_de_la_rama
● Nuestro remoto se llama github
● Nuestra rama se llama master
git push -u github master
El parámetro -u es opcional, sin embargo, se recomienda su uso.
Lo que hace es generar una referencia para tracking.
De tal manera, podemos comparar local vs remote y entregarnos información como por
ejemplo:
"Tu repositorio local está 2 commits delante de tu remoto".
Remotes
Corresponden a direcciones que apuntan a servidores donde podremos, entre otras
funcionalidades:
● Almacenar y gestionar nuestro proyecto.
● Trabajar de manera colaborativa.
● Compartir el código de nuestro proyecto.
Trabajando con remotes
● En GitHub los repositorios son -por defecto- públicos.
● Cualquier usuario puede acceder y descargar su contenido.
¿Podemos modificar el contenido
de un repositorio público?
No.
A menos que nuestro usuario de GitHub se encuentre en la lista de colaboradores del
repositorio.
Sin embargo, existen mecanismos que nos permiten:
● Generar una copia de un repositorio público.
● Asociar esta copia a nuestra propia cuenta.
● Poder descargar este repositorio, generar cambios y luego subirlos.
● Informar al autor del repositorio original de estos cambios, transparentarlos y darle la
opción de integrarlo.
Estos mecanismos se conocen
como fork y pull request
Fork
Corresponde a la acción de generar una copia exacta de un repositorio y asociar esta
copia a nuestra cuenta (manteniendo la referencia al autor).
Pull Request
Corresponde a la acción de solicitar la implementación de nuestros cambios en un repositorio.
Big Picture
Fork Pull
Upstream Origin Local
Pull request Push
Desafío GitHub:
Fork y Pull request
Desafío GitHub: Fork y Pull request
Imaginemos que el proyecto a utilizar corresponde a un repositorio público desarrollado
por el profesor y ampliamente utilizado por la comunidad de desarrolladores.
Los alumnos -al ver el proyecto- consideran que hay varios cambios que podrían mejorar
el contenido del repositorio y deciden colaborar con el proyecto.
Desafío GitHub: Fork y Pull request
1. Crear un fork del repositorio.
2. Clonar el repositorio forkeado a nuestro computador.
3. Generar cambios simples en el proyecto.
4. Commitear los cambios.
5. Hacer push a nuestro repositorio forkeado.
6. Crear un pull request describiendo los cambios implementados.
El profesor analizará los pull requests y decidirá qué cambios implementar.
¡Así funciona la colaboración en proyectos
de código abierto mantenidos por la comunidad!
[Link]