Curso de Git y GitHub

Enlace de repositorio con el que se trabajó del curso

https://github.com/Erickbandido/cursoGit-Github

Enlace de repositorio al que se le aplicó el fork

https://github.com/Erickbandido/ElectivappServer

Introducción
Git y Github son cosas distintas.

Git es un Software libre de control de versiones.

El control de versiones ayuda a facilitar el desarrollo y mantenimiento de una aplicación,

tanto de forma individual como en trabajar en equipo. Va guardando un registro cronológico
de todos los cambios selectos que sufren los archivos.

A modo burdo: crear una aplicación que está compuesta por muchas cosas, lo guardas y
creas una “versión”, como una foto instantánea, de toda la aplicación. Preservando ese
estado de la app en el registro de cambios con un código ÚNICO y el nombre que quieras
de esa instantánea. Modificar unos archivos y te gusta como quedo ahora, guardas y creas
otra instantánea pero puedes solo guardar los cambios que tu decidas, puede que en tu
sistema tengas muchos archivos con cambios pero solo decides tomar la instantánea de
solo uno. Empezaste a trabajar y al probar la app hay algo que no te gusta o que hubo un
cambio muy drástico, puedes regresar a un punto anterior de los registros (instantáneas)
que llevas.

Git también tiene ramas. Ayuda a mantener un control y orden del flujo de trabajo. Imagina
que estás desarrollando y pides ayuda a tu compañero. Crean una rama para cada uno y
pueden trabajar los dos al mismo tiempo con sus propias instantáneas. Y al final, cuando
hayan terminado, pueden juntar o decidir qué cambios son los que se van a quedar en cada
archivo, si es que hay conflictos al trabajar exactamente en la misma parte de un archivo.

Me has convencido, ¿cómo la instalo? Pues en la página oficial de git te dicen cómo
instalarlo para cada tipo de sistema operativo.

Creando un repositorio
Imagina que acabas de crear tu aplicación desde cero y debes de empezar a que git trabaje
en ella. En el directorio raíz de tu aplicación, debes de ejecutar el comando ‘git init’
desde la terminal. Al ejecutarlo, ahora tienes 3 áreas con las que trabaja git. El área de
trabajo es donde vas desarrollando, es el área con la que siempre has trabajado incluso sin
git. Después tenemos el área de ensayo (staging area) que es donde se puede ver que
archivos están siendo seguidos por git y cuáles no, además de que es donde se
presentarán los cambios selectos que tu decidas. La última área es el repositorio local, que
es donde vas a guardar de manera cronológica las instantáneas que vayas haciendo.

Para hacer los cambios selectos, que son los que les dará seguimiento git para la
instantánea, escribimos en la consola ‘git add’, lo que hace el comando es que mueve
el o los archivos al área de ensayo. Para el usuario parecerá que no pasó nada, puedes
modificarlo todavía, digamos que git lo tiene en la mira para poder hacerle la instantánea.

Ya que tenemos seleccionados los archivos en el área de ensayo, le damos ‘git commit’
y listo, tenemos la instantánea creada y registrada en el repositorio local ese punto de
tiempo del desarrollo de tu aplicación.

Ahorita hemos creado un repositorio local nuevo en una carpeta para hacer pruebas. hemos
creado varios directorios y archivos pero solo vamos a hacer add del primer archivo.

Entonces le hacemos el commit y…

Cuando está recién instalado el git, te pide un usuario y un email para poder colocarlos en
las instantáneas para identificar el creador de ellas. Es importante leer siempre los errores
para saber qué hacer.
Subiendo a GitHub
Al hacer de nuevo un git status consigues que ya no aparezca el archivo que acabamos de
hacer commit, porque git ya le está dando seguimiento.

Si modificamos el archivo aparecerá de nuevo pero ahora en rojo, indicando que tiene
cambios (ahora estoy usando -s en status para que muestre como un resumen de lo que
está pasando).

Recuerda, cada vez que vayas a hacer un commit (instantánea) vas a tener que pasar los
archivos al área de staging (ensayo). Como lo comentamos, es como si los pusieran en
cuadro para poder tomarles una foto instantánea. Si no hay nadie enfrente de la cámara,
nada se puede guardar.

Después de hacer varios commits queremos ver el historial. Entonces usamos ‘git log’.
(Se agregó el --oneline para hacer un resumen del registro en una sola línea)

Ahora, que tal si queremos que se restaure un commit. Podemos hacer ‘git reset
--hard [hashDelCommit]’ para regresar a ese commit.

Puedes usar ‘git add *’ para agregar al staging area todos los archivos y carpetas que
git detecta o también puedes usar ‘git add .’, el punto indica el directorio actual y hace
que se agreguen archivos y directorios de la carpeta en la que nos encontramos.

Ok al usar git puedes juntar comandos en una sola instrucción: ‘git -am’. Esto se puede
ver en muchas instrucciones de terminal. Lo que le indicamos es que haga add y commit.

Puedes modificar la descripción de los commits, de hecho puedes modificar varias cosas.
Git al instalarse también instala el editor de textos VIM. Yo tengo nano predeterminado por
lo que se ve y usa diferente.

hasta el momento se ve así:

Puedes crear un repositorio en Github, generalmente en la pantalla principal al hacer login,
aparece un botón a la izquierda que dice nuevo. Le das y pones la configuración de tu
repositorio. Ahora necesitas seguir las instrucciones que te aparecen en pantalla, pero
ejecutándose en tu terminal.

Este es el enlace a mi repositorio:

https://github.com/Erickbandido/cursoGit-Github

Clonación y tags
Puedes editar tus archivos desde GitHub. GitHub tiene su propio editor de texto.

Que pasa si hay cambios en el repositorio remoto que no tienes en local porque se modificó
fuera de tu entorno local, aplicas git pull.

Y ya, no necesitas hacer más (Aún no tomamos en cuenta conflictos)

Imagina que ya quieres mandar la versión 1.0. ¿Cómo le hacemos para indicar que ya está?
Con tags. Bueno, las liberaciones son distintas a las tags. Pero eso se verá más adelante.

Puedes crear una tag desde github, vas a tu repositorio de github y seleccionas el botón
tags y le das en crear.

Para crearla desde tu repositorio local, debes de escribir ‘git tag [nombreDeTag] -m
“Mensaje”’. Recuerda que para que un cambio se vea en el repositorio remoto, es
necesario hacer un git push. En este caso haremos git push --tags solo para hacer push de
los tags.

Imagina que estás en una computadora nueva y quieres seguir trabajando en tu proyecto.
Pues lo clonas, puedes ir a github, darle en el boton clone y aparecen muchas opciones
para poder clonar. La opción más usada es por https aunque puedes hacerlo también por
ssh. Solo debes de hacer git clone [direccion_https].

Ramas o Branches
Al hacer los commits se puede ver la línea de tiempo de estos en el branch. La rama
predeterminada de git es master. Puedes crear ramas paralelas para proyectos complejos o
con equipo grande. Como líneas de tiempo paralelas. Ya si en esa rama te gusta como
quedo, puedes unir esa rama a otras ramas. Esto puede ocasionar conflictos pero se
pueden solucionar para que se puedan unir.

Para crear una rama se usa git branch [nombreRama] la cual empezará desde el
commit en el que estabas. Para pasarse entre ramas debes de usar
git checkout [nombreRama].
Obviamente si trabajas en una rama, esos cambios no aparecerán en otra. Por lo que
puedes trabajar como con dos versiones en paralelo.

Para poder unir dos ramas tienes que usar git merge en la rama donde se concentra el
commit de unión.

En el curso se explica como usar git con VS Code y con Eclipse. Puedes usar el IDE que
sea de tu agrado y poder seguir usando GIT hasta podrías tener un programa que te ayude
a usar git de manera gráfica como sublime merge, incluso dentro desde el mismo GitHub.

Si llegas a usar la interfaz de git de VS Code, entonces deberías de buscar el símbolo en la

barra izquierda que parece una Y con curvas y bolitas en las puntas. (Source Control en
inglés) la puedes también abrir con Ctrl+Shift+G. Ahí aparecen los botones más usados
como add y commit. Mientras que en los tres puntos (...) aparecen todo el resto de
comandos de GIT.

Como experiencia personal, hagan los merge en GitHub. Es más fácil solucionar conflictos
porque ya no dependes del IDE ni de la terminal.

Un git fetch puede ser utilizado para revisar los cambios en el repositorio remoto sin hacer
merge a esos cambios. Así puedes evitar perder lo que llevas trabajando si hay diferencias
en los archivos.

Fork
Ramificación de todo un proyecto.

Imagina que alguien está desarrollando un proyecto y te gusta. Tienes dos opciones,
clonarlo y trabajar sobre ese proyecto y sobre ese repositorio. La otra opción es hacerle un
fork y tener una copia del proyecto en tu propio github, creando tu propio repositorio. NO en
local. Se puede utilizar un proyecto como base y al trabajarlo subirías tus cambios a tu
repositorio.

Ahora. Imaginate que hiciste cambios y quieres mostrarle o darle esos cambios al dueño
original del proyecto. Y ya dependerá del dueño original si aceptarlos o no.

Bueno, una vez hecho el fork, tienes que clonarlo en tu repositorio local para poder empezar
a trabajar en él.