# Iniciando en Git y Github

:::info
## Table de Contenido:
[TOC]
:::

## Introducción

En este documento se desea que el usuario pueda introducirse a Git y Github sin conocimiento del mismo.

La gestión de versiones facilita la colaboración de equipos de desarrollo en la modificación y actualización de archivos en un proyecto, mientras se mantiene un registro de los cambios realizados a lo largo del tiempo. Además, esta práctica ayuda a evitar la duplicación de código y a prevenir conflictos que puedan surgir entre diferentes desarrolladores que trabajan simultáneamente en el mismo proyecto. De esta manera, se puede registrar el historial completo de las modificaciones realizadas en cada archivo versionado. Es importante destacar que existen dos categorías principales de sistemas de control de versiones: los centralizados y los distribuidos.

## Instalar Git

### Instalar Git en Linux

**1.-** En la terminal del OS.

 ubuntu@Ubuntu:~$

Para actualizar el repositorio de paquetes disponibles en Ubuntu, se debe ejecutar el siguiente comando.

 $ sudo apt-get update

Luego instale Git

 $ sudo apt-get install git

Si quiere asegurarse de que la instalación de Git se realizó con éxito, puede verificar la versión instalada ingresando el siguiente comando en la terminal.

 $ git -v

### Instalar Git en Windows

Para obtener Git en su computadora con sistema operativo Windows, simplemente seleccione la opción de Windows y descargue el instalador compatible con las especificaciones de su equipo.

[Click para instalar la version mas reciente de Git para Windows](https://git-scm.com/download/win)

Para instalar el software, se requiere hacer doble clic en el archivo de instalación y conceder permiso al sistema operativo para que lo ejecute.

**1.-** En la ventana inicial del asistente de configuración, se presenta la licencia de Git con fines meramente informativos. Es posible leerla detenidamente o simplemente omitirla y continuar haciendo clic en "Next".

**2.-** Por favor, seleccione la ruta donde prefiera guardar los archivos de configuración de Git y luego pulse en el botón "Next".

**3.-** En la ventana siguiente se pueden visualizar diversas configuraciones personalizables, tales como la creación de accesos directos en el escritorio o la activación de Git LFS para manejar archivos de mayor tamaño. Depende de usted si desea dejar estas configuraciones predefinidas o si desea modificarlas, para luego proceder a hacer clic en el botón "Next".

**4.-** Por favor, ingrese el nombre de la carpeta en la que desea guardar los proyectos en su dispositivo o simplemente mantenga el nombre predeterminado y seleccione "Next".

**5.-** Por favor, elija el editor que prefiera para modificar los archivos desde la consola y presione el botón "Next".

**6.-** La ventana siguiente tiene la opción predeterminada de utilizar Git como la interfaz de línea de comandos y posibilitar la utilización de git bash para ejecutar comandos propios de Git. Puede dejar esta configuración por defecto y continuar haciendo clic en "Next".

**7.-** Es momento de elegir el puente de seguridad para utilizar con Git. Actualmente, el protocolo SSL se encuentra preseleccionado como opción por defecto. Si lo considera adecuado, puede dejarlo así y proceder haciendo clic en "Next".

**8.-** En este momento se mostrará la configuración de conversión de línea final. Deje los ajustes tal como están y pulse en "Next".

**9.-** Para utilizar Git, es necesario tener acceso a un emulador de línea de comandos de Linux, y para hacerlo más sencillo, se puede utilizar git bash. Simplemente seleccione la opción por defecto y haga clic en "Next".

**10.-** En la pantalla final del asistente de configuración, encontrará algunas opciones adicionales, como la posibilidad de activar la modificación del sistema de archivos y el administrador de credenciales de Git. Le recomendamos que deje estas opciones tal como están y haga clic en "Next".

**11.-** Después de finalizar la configuración, seleccione el botón "Instalar" y, posteriormente, elija la opción "Iniciar Git Bash" para concluir el proceso.

**12.-** Para concluir, elija la alternativa "Iniciar Git Bash".

 $ git --version

### Instalacion de Git en OS

Se accede a la línea de comandos del sistema operativo.

 user:~$

Puede verificar la versión del gestor de paquetes instalado en su computadora a través de la consulta del número de versión del software de gestión de paquetes en uso.

$ brew -v 

user:~$brew -v
 Homebrew 2.2.12
 Homebrew/homebrew-core (git revision deb5; last commit 2023-04-23)
user:~$

#### Instalar Homebrew

Si no tiene instalado **Homebrew** siga lo siguiente:

[Haga click aqui para instalar Homebrew y siga los pasos correspondientes](https://brew.sh/index_es)

#### Comandos para instalar git OS

Instale Git con el siguiente comando:

$ brew install git

Para verificar que la instalación de Git se haya completado con éxito, puede introducir en la terminal el siguiente comando que mostrará la versión instalada.

$ git --version

## Espacio de Labor

Cuando se trabaja con GIT, se deben tener en cuenta tres áreas clave. La primera corresponde al espacio de trabajo local, donde el desarrollador realiza sus cambios y ajustes. La segunda es el repositorio central, donde se almacenan todas las versiones del proyecto. Por último, se encuentra el área de preparación, que actúa como un espacio intermedio donde se organizan los cambios antes de que se integren en el repositorio central. Es importante tener en cuenta estas tres áreas para llevar un control adecuado del proyecto y evitar errores o conflictos en el trabajo colaborativo.

### Crear un repositorio

El proceso para crear un repositorio inicia en la raíz del directorio donde se encuentran los archivos del proyecto, donde se ejecuta el comando **git init** para inicializar el repositorio de Git. Es un proceso sencillo y rápido que permite al usuario empezar a trabajar en su proyecto y versionarlo de forma efectiva.

> cd <raiz de MyProyect>
> git init

Al ejecutar este comando se establece el repositorio y se habilita el área de preparación.
Al configurar el repositorio, se genera una carpeta .git oculta en el directorio principal del proyecto, la cual será la encargada de almacenar todas las versiones y datos del repositorio.

> cd <raiz de MyProyect>
> git init

Initialized empty Git repository in ./MiProyecto/.git/

### Guardar un Repositorio

Para guardar un archivo en el repositorio, es necesario que se pase previamente al área de preparación. En este espacio, se registran los archivos que se desean enviar al repositorio, y para hacerlo, se utiliza el comando "add" que permite mover los archivos desde el espacio local al área de preparación.

Observando esta situación, se puede apreciar que se ha utilizado para añadir el archivo readme.txt al área de preparación.

> git add readme.txt

### Observar las actualizaciones en nuestro repositorio.

Al ejecutar el comando **git status**, es posible revisar el estado actual del repositorio, lo que nos permitirá conocer si existen archivos nuevos o modificados. En este caso en particular, el archivo readme.txt es detectado como un archivo nuevo ya que esta es la primera vez que se está agregando al repositorio.

> git status
 On branch master
 
   Changes to be comitted:
     (use "git rm --cached <file>..." to unstage)
     
                    new file: readme.txt
                    
Untracked files: 
  (use "git add <file>..." to include in what will be commited)
  
  
                    file1/

Además, se puede notar la presencia de archivos en mi sistema local que aún no han sido agregados al área de preparación. En particular, el archivo llamado File1 es una carpeta que, por ahora, no deseamos trasladar al repositorio.

### Transferir los archivos de la zona de preparación al repositorio.

El comando **commit** es utilizado para enviar los cambios realizados en el área de preparación al repositorio. Este comando requiere la inclusión de un mensaje que describa los cambios realizados. Al ejecutar este comando, se guarda una copia de los archivos en la versión actual y se asocia el mensaje a la versión. Cada versión es identificada mediante un HASH único que corresponde a los archivos contenidos en ella. De esta manera, se mantiene un registro histórico de los cambios realizados en el código.

> git commit -m "Archivo readme del proyecto"

[master (root-commit) dc9fb48] Project readme file 1 file changed, 1 insertion(+)

create mode 100644 readme.txt

Al ejecutar el comando, se nos brinda información sobre la cantidad de archivos que se han añadido y los que han sido modificados. Además, podemos verificar el estado actual del repositorio para conocer cualquier cambio que se haya producido. En este caso, se muestra que no hay cambios pendientes en el área de preparación y que la carpeta1 aún no ha sido incluida en dicha área. También se registra la presencia de un archivo en el repositorio.

### Realizar modificaciones a un archivo que ya se encuentra en el repositorio.

Al modificar el archivo readme.txt, el estado actual del repositorio nos indica la presencia de un archivo modificado en el espacio local. Sin embargo, la carpeta1 aún no ha sido agregada al área de preparación. Para actualizar el repositorio con los cambios, debemos volver a repetir los pasos previos de agregar la carpeta al área de preparación y luego al repositorio.

El comando **add** permite agregar archivos nuevos o modificados al área de preparación. Posteriormente, al revisar el estado del archivo, se puede notar que se encuentra en el área de preparación listo para ser enviado al repositorio mediante el comando **commit** y su correspondiente mensaje. De esta forma, se crea una nueva versión del repositorio con un identificador distinto. Al realizar estos pasos, se pueden tener múltiples versiones en el repositorio.

> git add readme.txt
> git commit -m "Project readme file"

### Revisar el registro de modificaciones anteriores.

 $ git log

Además de la información elemental del registro de cambios, es factible reconocer la rama en la cual se efectuaron las modificaciones y el identificador individualizado del mismo. Este código exclusivo le proporciona la capacidad de buscarlo en el futuro o revertir el ***commit** si fuera necesario.

### Lograr la sincronización entre los repositorios.

#### Emplear la función "pull"

Para mantener sincronizados los repositorios, es esencial utilizar el comando **push**. Esto nos permitirá descargar las últimas modificaciones realizadas en el repositorio original o en el clon del mismo, asegurando que trabajamos con la versión más actualizada del código.

> git pull 

Git es una herramienta esencial para la gestión de versiones de proyectos colaborativos. Entre sus funciones, destaca la posibilidad de descargar contenido desde un repositorio remoto y actualizar de forma inmediata el repositorio local para reflejar dichos cambios. De esta forma, se pueden fusionar los cambios remotos con el nivel de tu repositorio local en una tarea común en flujos de trabajo colaborativos basados en Git.

#### El Fork

En Git, una tarea común es la creación de una copia de un repositorio existente en la cuenta personal del usuario, lo que se conoce como hacer un **fork**. A continuación se detallan los pasos necesarios para realizar esta operación en el repositorio base.

Diríjase al repositorio base que creó previamente en la sección anterior a través de su navegador web y seleccione el botón **Fork** situado en la esquina superior derecha de la pantalla para continuar.

Cuando se realiza un **fork** en GitHub, se crea una copia exacta del repositorio original en el dominio de GitHub, pero con el nombre de usuario del que realiza el **fork** y el nombre del repositorio original. Es decir, el usuario tendrá una copia completa y separada del repositorio original en su propia cuenta de GitHub.

#### Usando Git Push

Esta acción permite transferir datos del repositorio local a un repositorio remoto para asegurar que ambos contengan la misma versión del contenido.

### Usando el Pull Request

Un **pull request** es una solicitud que permite la integración de nuevas propuestas o cambios de código a un proyecto ya existente. Esta solicitud puede ser revisada y evaluada por el equipo de desarrollo antes de que se hagan los cambios necesarios. De esta manera, se asegura que el proyecto se mantenga actualizado y se evitan posibles errores en el código.

Para llevar a cabo esta tarea, es necesario generar una petición de **pull request** con el fin de fusionar las modificaciones efectuadas al repositorio principal.

Una manera alternativa de expresar la misma idea podría ser: "Para incorporar las modificaciones realizadas al repositorio base, se hace necesaria la creación de una solicitud de extracción".

Al hacer clic en **Create Pull Request**, se abre una ventana que permite revisar las diferencias entre los commits y visualizar los archivos involucrados. En esta etapa, el usuario puede agregar comentarios relevantes y detallar los cambios realizados antes de crear la solicitud de extracción.

Se ha generado y le brinda la opción de continuar añadiendo comentarios o clausurarlo a su discreción.

### Revisar y Rechazar Pull Request

Después de crear el comentario, usted tiene la opción de seguir discutiendo o cerrar la conversación. Si en algún momento observa una notificación en su perfil que indica **Pull Request**, simplemente haga clic en ella para abrir el contenido y ver la información detallada, incluyendo el autor del pull request, la fecha y su comentario correspondiente.

Para visualizar los archivos afectados o agregados en un **Pull request**, se puede acceder a la pestaña denominada **Files changed**. Una vez allí, se podrán observar todos los archivos modificados y las adiciones realizadas en ellos durante el proceso del **Pull request**.

Después de la revisión del **Pull Request**, una notificación será enviada al correo electrónico asociado con la cuenta de **Github**, proporcionando un resumen de las observaciones recibidas durante la revisión.

## Las ramas en Git

Es necesario verificar la respuesta del administrador del repositorio base y realizar las correcciones necesarias en base a sus comentarios.

La utilización del comando "branch" sin parámetros nos permite visualizar la lista de ramas existentes. Actualmente, sólo disponemos de una rama, denominada "master". Podemos identificar que estamos trabajando en esta rama gracias al asterisco que aparece antes del nombre de la misma.

Mediante el uso del comando **Git Branch** es posible generar una nueva rama en el proyecto que se esté trabajando.

Para desplazarnos a una nueva rama a partir de nuestra rama principal **(master)**, se debe utilizar el comando **git checkout** seguido del nombre de la nueva rama. Por ejemplo, si deseamos movernos a la rama llamada **New**, debemos ejecutar el comando **git checkout New**. Luego de ejecutar este comando, se mostrará un mensaje indicando que nos encontramos en la rama deseada.

### Fusion de Ramas

Imaginemos que deseamos efectuar un cambio en el archivo denominado **HvGC.html** en la rama **New**. Una vez realizado el cambio, se añade con la instrucción **add** y se envía mediante un **commit** al repositorio local. Posteriormente, para fusionar ambas ramas, por ejemplo con la rama **master**, nos situamos en ella con el comando **git checkout master** y, seguidamente, procedemos a integrar las dos ramas utilizando el comando **merge** seguido del nombre de la rama a fusionar, en este caso, la rama **New**.

Git es capaz de combinar los cambios realizados en dos ramas diferentes en una sola. Si hubiera algún tipo de conflicto debido a que ambas ramas han sido modificadas, Git notificará al usuario para que pueda resolver el conflicto de manera efectiva y asegurarse de que el proceso de fusión se complete con éxito.
De esta forma se pueden visualizar los conflictos y realizar las modificaciones necesarias.
Una vez que hayamos terminado de mezclar los cambios en el archivo, podemos realizar un commit en la rama principal **master** y crear una nueva versión del mismo.

Mediante el uso del comando **git log**, es posible comprobar que se han realizado modificaciones tanto en la rama **New** como en la rama **master**.

En la rama principal llamada **master**, se encuentran la versión inicial, la versión corregida del error y la combinación de la rama **New**. Mientras que en la rama **New** solo se encuentran las versiones relacionadas con el cambio de diseño. La versión más reciente que se encuentra en la rama **master** es la que se ha publicado en el sitio web para actualizar la hoja de vida.

### Las Ramas Remotas

En este ejemplo, vamos a mostrar cómo clonar un repositorio de Git y trabajar con ramas remotas y locales. En primer lugar, clonaremos el repositorio que contiene una carpeta de documentos y un archivo **readme.txt** en nuestro espacio local. A continuación, crearemos una nueva rama en el repositorio remoto y haremos cambios en esa rama. Después, actualizaremos nuestro repositorio local para sincronizarlo con el repositorio remoto y comprobaremos cómo se relacionan las ramas remotas con las ramas locales. Finalmente, crearemos una nueva rama en nuestro repositorio local y la publicaremos en el repositorio remoto.

Una vez que hemos clonado un repositorio, es posible revisar su registro mediante el uso del comando "log".

Observamos que tanto el repositorio **local** como el repositorio **origen** poseen la rama **master**, y en ambos repositorios el puntero **HEAD** apunta a esta rama. Ahora, procederemos a crear una nueva rama llamada **Introducción** en el repositorio remoto de GitHub, y cambiaremos a esa rama.
Mediante el uso del comando **git log --oneline**, es posible visualizar que tanto el repositorio local como el remoto se encuentran apuntando a **HEAD** en la rama principal, denominada **master** y su respectiva copia en el servidor, conocida como **origin**.
En el repositorio actual, se realiza una modificación al archivo **readme.txt**. Se añade una línea adicional en la sección de introducción con el fin de mejorar la información presentada. Es importante mencionar que la edición se realiza dentro del mismo repositorio para simplificar el proceso y mantener la coherencia en las versiones del archivo.

### Llevar una rama remota llevarla a una rama local.

Después de haber realizado la modificación, se procede a realizar el **commit**. Una vez completado este proceso, regresamos a la terminal del repositorio local y llevamos a cabo la ejecución de **pull**.
Cuando se realiza la operación de **pull**, se nos notifica que se ha agregado una nueva rama de **introducción** en el repositorio remoto. Esto significa que podemos descargar la última versión de esa rama y fusionarla con nuestra rama actual, lo que nos permite mantener nuestro código actualizado y trabajar en colaboración con otros desarrolladores.

Si ejecutamos el comando **banch -a**, podremos obtener una lista de todas las ramas disponibles en el repositorio actual.
Podemos observar que la rama llamada **introduccion** se encuentra en el repositorio remoto, pero no en el repositorio local que estamos utilizando actualmente.
Podemos listar las ramas locales utilizando el comando **git branch -a** y ver con qué rama cada una está asociada.
Actualmente, solo contamos con la rama principal llamada **master**. Si deseamos conectar la rama remota de introducción con una rama local, es necesario realizar un procedimiento llamado **checkout**. Al realizar este procedimiento, se establece una conexión entre la rama local y la rama remota.

Revisemos una vez más la lista de ramas.

Con la rama local **introducción** ya creada, comprobemos mediante la opción **-vv** que se ha establecido la asociación con la rama remota.
De esta forma se puede observar el proceso de creación de ramas en repositorios remotos y la actualización correspondiente de los repositorios locales, manteniendo una asociación entre las ramas del repositorio local y el remoto.

## Empujar una rama local hacia un repositorio remoto.

Utilicemos el comando **checkout** para cambiar a la rama de colaboradores que acabamos de crear.

Observamos que en nuestro repositorio local existe una rama recién creada que aún no ha sido integrada al repositorio remoto. En este momento procederemos a modificar el archivo **readme.txt** en la versión correspondiente a esta rama, incluyendo nuevos colaboradores al archivo, y seguidamente guardamos los cambios realizados.

Cuando se quieren guardar los cambios realizados en nuestro código en el repositorio, es necesario utilizar dos comandos esenciales: "add" y "commit". Estos comandos nos permiten añadir los cambios realizados y hacer una confirmación de los mismos para que queden registrados en el historial de versiones del repositorio. De esta manera, se pueden rastrear los cambios realizados y volver a versiones anteriores del código si es necesario.

Para enviar nuestros cambios al repositorio remoto, usaremos el comando **git push --set-upstream origin Colaboradores.** Esto es necesario ya que estaremos creando una nueva rama en el repositorio remoto. Debemos especificar el nombre del repositorio remoto y el nombre que queremos darle a nuestra nueva rama.
Al realizar el envío de los cambios, se notifica la creación de una nueva rama de colaboradores en el repositorio remoto, la cual quedó enlazada a la rama del repositorio local para mantener una sincronización constante entre ambas.

Vamos a echar un vistazo a nuestra nueva rama en GitHub. En este caso, nos encontramos en la rama de colaboradores, donde podemos encontrar el archivo que contiene los cambios que hemos realizado.
Ahora, revisemos la lista de ramas en nuestro repositorio local para asegurarnos de que todo está en orden. Podemos observar que tenemos una rama llamada "colaboradores" en nuestro repositorio local y otra en el repositorio remoto.
Para concluir, comprobaremos la forma en que se vinculan las ramas locales y remotas mediante el uso de la opción **-vv**.
Ahora podemos verificar que la rama de **colaboradores** ha sido correctamente asociada con la rama del mismo nombre en el repositorio remoto.

## Cheat Sheet Git

Un Cheat Sheet que se puede emplear al momento de llevar acabo lo aprendido, y aumentar su habilidad en el uso de los comandos.

$ git init # Crear un nuevo git
 
$ git add # Agregar archivos al area de preparacion
 
$ git status # Estado del repositorio
 
$ git commit -m # pasar archivos del area de preparacion al repositorio local
 
$ git log # ver las versiones de archivos del repositorio
 
$ git clone # clonar un repositorio remoto
 
$ git push # modificar el repositorio remoto, con su nueva actualizacion
 
$ git pull # actualizar tu repositorio local con la ultima version del remoto
 
$ git add # sirve para agregar todos los archivos modificados al area de preparacion

## Referencias

> **Coursera, Git en español**, Universidad de los Andes, [Curso de Git en español](https://www.coursera.org/learn/git-espanol/)

## LICENSE

Copyright (C) 2023 DECENTRALIZED CLIMATE FOUNDATION A.C.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
A copy of the license is included in the section entitled "GNU
Free Documentation License". 

## Autor y Revisor
> Work developed in collaboration with the [Decentralized Climate Foundation](https://decentralizedclimate.org).

Autor:
- [Gustavo Bermudez](mailto:[e-mail])

Revisor:
- [Omar Octavio Huerta Valdez](mailto:[e-mail])