INTRODUCCIÓN A LA TERMINAL

Para acceder a la terminal de la computadora, se utilizan diferentes interfaces:

Interfaz de línea de comandos CLI (comand line interface): Actualmente se visualiza en
CMD, la pc recibe comandos, los procesa y arroja resultados.
Como mejora surgió GUI (graphical User Interface). Luego NUI (natural user interface),
lo que se usa en dispositivos móviles.

Modos de abrir la terminal:

- CMD de Windows
- PowerShell
- Git Bash: esta utilizaremos por defecto, la que se utilizará en el curso. La forma de
utilizarla es a través del editor de códigos VSCode.

Interacción con la terminal

La interacción se produce mediante comandos que son instrucciones que el sistema operativo
puede recibir y ejecutar. Para ello, se debe respetar unas reglas de escritura o sintaxis.

Comando:
Una instrucción que realiza una acción, ejecuta un proceso y produce una salida (realiza una
acción).

Estructura de un comando:
Los nombres de los comandos se basan, frecuentemente, en la acción que hacen o la función
de ese comando.
La terminal es sensible a las mayúsculas
Ej:
-el comando pwd=print working directory/imprimir el directorio.
-ls=list/listar – al ejecutarse realiza lista de todos los archivos y carpetas del directorio en el
que estamos trabajando
Las opciones de comandos alteran el comportamiento por defecto del mismo comando,
agregando mayor información o utilidad al mismo comando respecto de su uso básico. Las
opciones son todas las precedidas por un guión y sirven para alterar el comportamiento del
comando agregando alguna funcionalidad extra. Ej: ls -a permite ver archivos ocultos.
Todos los comandos tienen opciones diferentes, por lo que no está demás hacer lista con los
más usados.
Comando mkdir=make directory/crear carpeta. Si ponemos el comando solo, no hará nada ya
que se necesita que se agregue el nombre de la carpeta que se va a crear, el nombre será el
argumento. Para usar espacio en los argumentos, debemos usar comillas dobles o simples. Ej:
mkdir “mi primer carpeta”

Los argumentos indican sobre qué elementos se aplicará la instrucción o el comando escrito;
dentro de un comando son todos aquellos sobre los cuales se aplicará el comando que
escribimos. Se puede combinar opciones y argumentos en un comando. Ej: mkdir -v =para
que se confirme la creación del dir

CLI
La interfaz de línea de comandos o CLI, en inglés, command line interfaces, que no es más que una caja negra
que puede recibir comandos a través de la escritura por medio de un teclado conectado a la computadora,
procesarlos y arrojar un resultado, ya sea positivo si el comando se leyó con éxito, o negativo si escribimos algo
erróneo o la computadora no pudo procesar el comando escrito.

Comando
Un comando es simplemente una instrucción que al ejecutarlo en la CLI realiza una acción, cuando se recibe el
comando el sistema operativo ejecuta un proceso que puede leerlo, manipular datos y producir una salida.

Qué es un repositorio?
Almacen o lugar donde se guardan ciertas cosas. En el mundo tech está la necesidad de
guardar, mantener y manipular el código que se escribe hoy para poder trabajarlo días, meses
o años más adelante. Para ello, en 2007 se lanza GIT: Git es un sistema de control de
versiones de código, es decir; un sistema que registra los cambios realizados en un archivo o
conjunto de archivos a lo largo del tiempo, de modo que puedas recuperar versiones
específicas más adelante. Además, brinda la posibilidad de compartir y realizar un
trabajo/proyecto colaborativo. estos proyectos estarán almacenados en un “repositorio”.

Con Git ya estamos controlando las versiones de nuestro código, pero también deseamos
guardar este código en internet (en la nube) para poder compartirlo, y tener un respaldo de él.
Para cumplir esta función existen diferentes herramientas como: gitLab, bitbucket o Github,
nosotros recomendamos utilizar esta última. Github.com es una red para almacenar tus
repositorios, esencialmente es un repositorio de repositorios, y actualmente es el más popular
entre la comunidad de desarrolladores. Es importante aclarar que Git no es igual que Github,
aunque funcionan muy bien juntos.
La diferencia principal entre Git y GitHub es que Git es una herramienta de código abierto
que los desarrolladores instalan localmente para gestionar el código fuente, mientras que
GitHub es un servicio en línea al que los desarrolladores que utilizan Git pueden conectarse y
cargar o descargar recursos.
En resumen, Git es el sistema de control de versiones y GitHub es un servicio de alojamiento
para los repositorios de Git.

Configuración de credenciales GIT para poder empezar a usarlo y nos reconozca como
propietarios o colaboradores de un repositorio. Debemos abrir la consola GitBash y
configurar el mail, debe ser el mismo que usamos para Git
git config --global user.email "tu@email.com”
luego configuraremos el nombre de usuario que puede ser cualquiera:
git config --global user.name "tu nombre"
para crear archivo dentro de carpeta, nos debemos situar dentro de la carpeta
$ cd “nombredelacarpeta”/
$ touch “Mi primer repositorio.txt”

Para abrir el archivo desde el editor de códigos que elegimos, ingresamos en gitbash
$ code "Mi primer repositorio.txt"
Con eso, abrimos y podemos editar el archivo .txt desde el editor de código (VScode)

Creación de repositorio y primer commit

Desde el VSCode, abrimos la carpeta donde queremos crear nuestro primer repositorio Para
crear nuestro repositorio local, utilizamos el comando git init
Esto creará una carpeta oculta con el nombre git donde se almacenará el repositorio por lo que
no debe ser borrada.
Todos los comandos básicos de la terminal de git, comenzarán con esta palabra.
Nunca debemos hacer git init en la carpeta Escritorio ni dentro de carpetas que tengas
archivos muy grandes ya que se haría un seguimiento de todo lo que se encuentra en el disco
duro.

Una vez creado el repositorio, todos los archivos que estén dentro pasan a estar en fase/estado
de seguimiento git.

Commit:
Captura instantánea de los cambios preparados en ese momento del proyecto. El comando
commit guarda una ‘foto’ del estado de los archivos y carpetas del repositorio local, al
momento de ‘ser tomada’ y para hacer el seguimiento. Estamos guardando el estado actual de
nuestro proyecto.
El commit se hará sobre archivos, no se hará sobre carpetas vacías.

git status verificamos que estemos dentro de nuestro repositorio.

git add para agregar un archivo al repositorio (git add “Mi primer repositorio.txt”). Con git
add . (espacio punto) agregamos todos los archivos al commit, pero debemos prestar atención
de no estar agregando archivos que no queremos.
git commit -m "algún mensaje de commit": aquí se generan cambios de "Staging Area" y con
( -m "") se deja un mensaje que nos sea útil.
git log hace un listado de los commit que se crearon en el repositorio con el autor, fecha y
comentario dejado

Crear un repositorio en GitHub

Para llevar el repositorio a nueva pc y almacenarlo en forma local, copiamos la url del
repositorio
Desde el escritorio, abrimos GitBash y con el comando git clone + la url copiada descarga el
repositorio y lo guarda creando una carpeta en el escritorio que es sobre la cual vamos a
trabajar

con esto, se abre el

Vscode con el
respositorio. Ahí estará
el archivo readme.md que se creo al crear el respositorio en GitHub. Desde el VSCode, lo
editamos.

Una vez que clonamos el repositorio a nuestra pc, trabajamos desde ahí con los archivos,
luego le damos git add para subirlos a nuestro repositorio y con git push lo subimos de
manera definitiva al repositorio de git, se sincroniza con el respositorio remoto desde nuestra
pc local.
Puede haber variaciones de este comando, ej: git push origin main refiere al origen donde
queremos enviar la información, main indica la rama de trabajo a la cual le enviaremos. O git
push -u origin main

Para crear un repositorio sin un archivo README.md, hacemos los mismo que antes pero sin
tildar la creación de ese archivo. Luego, en GitHub nos saldrá opciones para hacer y así tener
contenido en el repositorio:
- Crear un archivo README.md:
echo "# PrepCourse-Henry-NoREADME" >> README.md
git init
git add README.md
git commit -m "first commit"
git branch -M main // modifica el nombre de la rama de trabajo actual
git remote add origin https://github.com/Adriana-Carra/PrepCourse-Henry-NoREADME.git
git push -u origin main

- O sincronizarlo con un repositorio existente:

git remote add origin https://github.com/Adriana-Carra/PrepCourse-Henry-NoREADME.git
git branch -M main
git push -u origin main
git remote add origin indica a git hacer una conexión remota desde nuestro repositorio local al
espacio de trabajo donde queremos sincronizarlo

- `git add ArchivoEjemplo.js`: crea el archivo pero no lo guarda de forma definitiva, lo

almacena en (Staging Area).
- `git commit -m "versión 1"`: aquí se generan cambios de "Staging Area" y con ( -m "") se
deja un mensaje que nos sea útil.
- `git commit -m "Cambios v1"`: sirve para generar cambios sobre la versión antigua.
- `git status`: sirve para revisar si has modificado o guardado los cambios hechos.
- `git log "archivo.txt"`: sirve para ver el historial del archivo.
- `git push`: sirve para enviar cambios al repositorio remoto.
- `git pull`: sirve para recibir cambios de repositorio remoto a local.

¿Qué es Node JS?

Fue ideado como un entorno de ejecución de javascript, Node JS nos va a permitir ejecutar
nuestro código, lo leerá y si algo anda mal, nos retornará lo que debemos corregir o en caso
contrario, nos brindara el resultado de la ejecución de nuestro código JS.

HTML
El Lenguaje de Marcado de Hipertexto (HTML) es el código que se utiliza para estructurar y
desplegar una página web y sus contenidos.
Entonces, ¿qué es HTML en realidad?
HTML no es un lenguaje de programación; es un lenguaje de marcado que define la estructura
de tu contenido. HTML consiste en una serie de elementos que usarás para encerrar diferentes
partes del contenido para que se vean o se comporten de una determinada manera.

Anatomía de un elemento HTML

Explora este párrafo en mayor profundidad.

Las partes principales del elemento son:

1. La etiqueta de apertura: consiste en el nombre del elemento, encerrado por paréntesis
angulares (< >) de apertura y cierre. Establece dónde comienza o empieza a tener efecto el
elemento.
2. La etiqueta de cierre: es igual que la etiqueta de apertura, excepto que incluye una barra de
cierre (/) antes del nombre de la etiqueta. Establece dónde termina el elemento.
3. El contenido: este es el contenido del elemento, que en este caso es sólo texto.
4. El elemento: la etiqueta de apertura, más la etiqueta de cierre, más el contenido equivale al
elemento.

Los elementos pueden también tener atributos, que se ven así:

Los atributos contienen información adicional acerca del elemento, la cual no quieres que
aparezca en el contenido real del elemento. Aquí class es el nombre del atributo y editor-note
el valor del atributo. En este caso, el atributo class permite darle al elemento un nombre
identificativo, que se puede utilizar luego para apuntarle al elemento información de estilo y
demás cosas.

Un atributo debe tener siempre:

1. Un espacio entre este y el nombre del elemento (o del atributo previo, si el elemento ya
posee uno o más atributos).
2. El nombre del atributo, seguido por un signo de igual (=).
3. Comillas de apertura y de cierre, encerrando el valor del atributo.
Los atributos siempre se incluyen en la etiqueta de apertura de un elemento, nunca en la de
cierre.

Anidar elementos
Puedes también colocar elementos dentro de otros elementos —esto se llama anidamiento—.
Si, por ejemplo, quieres resaltar una palabra del texto (en el ejemplo la palabra «muy»),
podemos encerrarla en un elemento <strong>, que significa que dicha palabra se debe
enfatizar:

<p>En Henry invertimos <strong> en tu educación</strong></p>

Debes asegurarte que los elementos estén correctamente anidados: en el ejemplo de abajo,
creaste la etiqueta de apertura del elemento <p> primero, luego la del elemento <strong>, por
lo tanto, debes cerrar esta etiqueta primero, y luego la de <p>. Esto es incorrecto:

<p>En Henry invertimos <strong> en tu educación</p></strong>

Elementos vacíos
Algunos elementos no poseen contenido, y son llamados elementos vacíos. Toma, por
ejemplo, el elemento <img> de nuestro HTML:

<img src="images/henry-icon.png" alt="Mi imagen de prueba">

Posee dos atributos, pero no hay etiqueta de cierre </img> ni contenido encerrado. Esto es
porque un elemento de imagen no encierra contenido al cual afectar. Su propósito es
desplegar una imagen en la página HTML, en el lugar en que aparece.
Anatomía de un documento HTML
Ahora verás cómo los elementos individuales son combinados para formar una página HTML
entera.

Tienes:
● <!DOCTYPE html> — el tipo de documento. Es un preámbulo requerido.
Anteriormente, cuando HTML era joven, los tipos de documento actuaban como vínculos a
un conjunto de reglas que el código HTML de la página debía seguir para ser considerado
bueno. Sin embargo, hoy día es simplemente debe ser incluido para que todo funcione
correctamente.
● <html></html> — el elemento <html>. Este elemento encierra todo el contenido de
la página entera y, a veces, se le conoce como el elemento raíz (root element).
● <head></head> — el elemento <head>. Este elemento actúa como un contenedor de
todo aquello que quieres incluir en la página HTML que no es contenido visible por los
visitantes de la página. Incluye cosas como palabras clave (keywords), una descripción de la
página que quieres que aparezca en resultados de búsquedas, código CSS para dar estilo al
contenido, declaraciones del juego de caracteres, etc.
● <meta charset="utf-8"> — <meta>. Este elemento establece el juego de caracteres
que tu documento usará en utf-8, que incluye casi todos los caracteres de todos los idiomas
humanos. Básicamente, puede manejar cualquier contenido de texto que puedas incluir.
● <title></title> — el elemento <title> establece el título de tu página, que es el título
que aparece en la pestaña o en la barra de título del navegador cuando la página es cargada, y
se usa para describir la página cuando es añadida a los marcadores o como favorita.
● <body></body> — el elemento <body>. Encierra todo el contenido que deseas
mostrar a los usuarios web que visiten tu página, ya sea texto, imágenes, videos, juegos, pistas
de audio reproducibles, y demás.
Marcado de texto
Encabezados
Los elementos de encabezado permiten especificar que ciertas partes del contenido son
encabezados, o subencabezados del contenido. HTML posee seis niveles de encabezados,
<h1>–<h6>, aunque probablemente solo llegues a usar 3-4 como mucho:

Párrafos
Los elementos <p> se utilizan para encerrar párrafos de texto; los usarás frecuentemente para
el marcado de contenido de texto regular:

Listas
El marcado de listas se realiza siempre en al menos dos elementos. Los dos tipos de listas más
comunes son las listas ordenadas y las desordenadas:
1. Las listas desordenadas son aquellas en las que el orden de los items no es relevante, como
en una lista de compras. Estas son encerradas en un elemento <ul> (unordered list).
2. Las listas ordenadas son aquellas en las que el orden sí es relevante, como en una receta.
Estas son encerradas en un elemento <ol> (ordered list).
Cada elemento de la lista se coloca dentro de un elemento <li> (list item).
Por ejemplo, si quieres transformar parte del siguiente párrafo en una lista:

Podrías hacer lo siguiente:

Vínculos
Los vínculos o enlaces son muy importantes —son los que hacen de la web, la web—. Para
implementar un vínculo, necesitas usar un vínculo simple — <a> — la a es la abreviatura de
la palabra inglesa «anchor» («ancla»). Para convertir algún texto dentro de un párrafo en un
vínculo, sigue estos pasos:
1. Elige algún texto.
2. Encierra el texto en un elemento <a>, así:

3. Proporciónale al elemento <a> un atributo href, así:

4. Completa el valor de este atributo con la dirección web con la que quieras conectar al
vínculo:

Podrías obtener resultados inesperados si al comienzo de la dirección web omites la parte

https:// o http:// llamada protocolo.
href podría parecer, en principio, una opción un tanto oscura para un nombre de atributo. Si
tienes problemas para recordarla, recuerda que se refiere a hypertext reference (referencia de
hipertexto).
----------------------------------------------------------------------

Homeworks

IMPORTANTE: Para ejecutar los tests de cada homework tenes que pararte en la carpeta
donde clonaste tu repo (es decir la carpeta donde está este README.md) y ejecutar el
siguiente comando:
npm install
Esto instalará todas las dependencias necesarias (lo tenes que hacer una sola vez), una vez
terminado y cada vez que quieras ver cuantos tests pasaste ejecutá:
npm test {nombre del homework}.test.js
Por ejemplo, para ejecutar los tests del homework 02, ejecutar: npm test JSII.test.js, el del
homework 01: npm test JSI.test.js y así.
No todos los homeworks tienen tests, está detallado en la descripción de cada uno.

------------------------------------------------------

INTERFAZ DE USUARIO (UI)

Es el medio con que el usuario puede comunicarse con una máquina, equipo o dispositivo, y
comprende todos los puntos de contacto entre el usuario y el equipo (Cómo interactuamos con
la pc). Tipos:
 CLI (command line interface):
 Codificada:
 Estricta:
 GUI (grafical user interface): usadas actualmente, mediante gráficos, iconos. Se hace click
en una imagen/icono y ahí se ejecuta un comando.
 Metafórica
 Exploratoria
 NUI (native using interface)
 Directa
 Intuitiva

CLI: consiste en un promt (representado por signo $) espacio donde puedo tirar comando.

Estructura del comando:

command [-option(s)] [argument(s)]

$ head -n3 README.md (este comando muestra las tres primeras líneas de un archivo
readme)

Habrá comandos que no necesiten opciones/argumentos.

Las opciones comienzan con signo – (menos)

Adri@ADRI-PC MINGW64 /d/CURSOS HTML/Prep-Course

Nombre de usuario – equipo – carpeta
Version Control System (VCS)
Un control de versiones es un sistema que registra los cambios realizados en un archivo o
conjunto de archivos a lo largo del tiempo, de modo que puedas recuperar versiones
específicas más adelante.
Si eres diseñador gráfico o web, y quieres mantener cada versión de una imagen o diseño
(algo que sin duda quieres), un sistema de control de versiones (Version Control System o
VCS en inglés) es una elección muy sabia. Te permite revertir archivos a un estado anterior,
revertir el proyecto entero a un estado anterior, comparar cambios a lo largo del tiempo, ver
quién modificó por última vez algo que puede estar causando un problema, quién introdujo un
error y cuándo, y mucho más. Usar un VCS también significa generalmente que si rompes o
pierdes archivos, puedes recuperarlos fácilmente.
Hay varios tipos de sistemas de versionado, estos pueden ser:

Locales:

Un método de control de versiones, usado por muchas personas, es copiar los archivos a otro
directorio (quizás indicando la fecha y hora en que lo hicieron, si son ingeniosos). Este
método es muy común porque es muy sencillo, pero también es tremendamente propenso a
errores. Es fácil olvidar en qué directorio te encuentras y guardar accidentalmente en el
archivo equivocado o sobrescribir archivos que no querías.
Como se pueden imaginar, este sistema funciona bien para trabajar solos, pero si queremos
incorporar otra gente al equipo van a empezar a surgir problemas.

Centralizado

Para solventar este problema, se desarrollaron los sistemas de control de versiones

centralizados (Centralized Version Control Systems o CVCSS en inglés). Estos sistemas,
como CVS, Subversion, y Perforce, tienen un único servidor que contiene todos los archivos
versionados, y varios clientes descargan los archivos desde ese lugar central. Durante muchos
años éste ha sido el estándar para el control de versiones.
Este sistema ofrece varias ventajas, como por ejemplo: Todo el mundo puede saber en qué
están trabajando los demás colaboradores y los administradores tienen control sobre qué
archivos pueden ver/modificar cada colaborador. Pero también presenta un problema
importante: que hay un punto único de fallo. ¿Si éste server se cae? Nadie puede seguir
trabajando ni trackeando sus cambios. ¿O si se rompe y no hay backups? Se pierde
absolutamente todo el trabajo realizado.

Distribuido

Es aquí donde entran los sistemas de control de versiones distribuidos (Distributed Version
Control Systems o DVCSS en inglés). En un DVCS (como Git, Mercurial, Bazaar o Darcs),
los clientes no sólo descargan la última instantánea de los archivos: replican completamente el
repositorio. Así, si un servidor muere, y estos sistemas estaban colaborando a través de él,
cualquiera de los repositorios de los clientes puede copiarse en el servidor para restaurarlo.

Conceptos de Git
Git modela sus datos como un conjunto de instantáneas de un mini sistema de archivos. Cada
vez que confirmas un cambio, o guardas el estado de tu proyecto en Git, él básicamente hace
una foto del aspecto de todos tus archivos en ese momento, y guarda una referencia a esa
instantánea. Para ser eficiente, si los archivos no se han modificado, Git no almacena el
archivo de nuevo, sólo un enlace al archivo anterior idéntico que ya tiene almacenado.

La mayoría de las operaciones en Git sólo necesitan archivos y recursos locales para operar.
Por lo general no se necesita información de ningún otro ordenador de tu red. Como tienes
toda la historia del proyecto ahí mismo, en tu disco local, la mayoría de las operaciones
parecen prácticamente inmediatas (con otros sistemas el proceso involucra llamados por red
que generan retardos importantes).
ESTADOS POSIBLES EN GIT

Untracked: es la primera vez que aparecen, no están en el repositorio, son cosas nuevas.
Unmodified: no modificado, ya los tenía en mi repositorio y no han sido modificados.
Modified: que se hizo un cambio en un archivo que ya se tenía.
Staged: son cosas que quiero guardar en mi próximo snapshot (quiero que se guarde una foto
de cómo está el archivo en este momento, foto instantánea). Ahí es un commit.

Integridad
Todo en Git es verificado mediante una suma de comprobación (checksum en inglés) antes de
ser almacenado, y es identificado a partir de ese momento mediante dicha suma. Esto
significa que es imposible cambiar los contenidos de cualquier archivo o directorio sin que
Git lo sepa.
El mecanismo que usa Git para generar esta suma de comprobación se conoce como hash
SHA-1. Se trata de una cadena de 40 caracteres hexadecimales (0-9 y a-f), y se calcula en
base a los contenidos del archivo o estructura de directorios. Un hash SHA-1 tiene esta pinta:

Verás estos valores hash por todos lados en Git, ya que los usa con mucha frecuencia. De
hecho, Git guarda todo no por nombre de archivo, sino por el valor hash de sus contenidos.
Vamos a distinguir dos directorios, primero el directorio de git: que es donde almacena los
metadatos y la base de datos de tu proyecto, y segundo el directorio de trabajo que es una
copia de una versión del proyecto en particular. Estos archivos se sacan de la base de datos
comprimida en el directorio de Git, y se colocan en disco para que los puedas usar o
modificar. Los archivos dentro del directorio de trabajo pueden estar en unos de los siguientes
estados:

Estados
Git tiene tres estados principales en los que se pueden encontrar tus archivos:
■ committed: significa que los datos están almacenados de manera segura en tu base de datos
local.
■ modified: significa que has modificado el archivo pero todavía no lo has commiteado a tu
base de
datos.
■ staged: significa que has marcado un archivo modificado en su versión actual para que vaya
en tu
próxima commiteada.
Hay un archivo simple, generalmente contenido en tu directorio de Git, llamado que almacena
información acerca de lo que va a ir en tu próxima confirmación, al contenido de este archivo.
O al archivo mismo se lo conoce como staging area.
Sabiendo esto, el flujo de trabajo básico en Git sería algo así:
■ Modificas una serie de archivos en tu directorio de trabajo.
■ Stageas los archivos, añadiendolos a tu staging area o área de preparación.
■ Commiteas o Confirmas los cambios, lo que toma los archivos tal y como están en el área
de preparación, y almacena esas instantáneas de manera permanente en tu directorio de Git.

Si una versión concreta de un archivo está en el directorio de Git, se considera confirmada

(committed). Si ha sufrido cambios desde que se obtuvo del repositorio, y ha sido añadida al
área de preparación, está preparada (staged). Y si ha sufrido cambios desde que se obtuvo del
repositorio, pero no se ha preparado (no se incluyó en el área de preparación), está modificada
(modified).

----------------------------------------------

GIT Y GITHUB

Comandos básicos
- `git init`: se utiliza para iniciar nuestro repositorio.
- `git add ArchivoEjemplo.js`: crea el archivo pero no lo guarda de forma definitiva, lo
almacena en (Staging Area).
- `git commit -m "versión 1"`: aquí se generan cambios de "Staging Area" y con ( -m "") se
deja un mensaje que nos sea útil.
- `git add .`: Agrega los archivos actualizados al repositorio, pero únicamente en la carpeta
que te encuentras.
- `git commit -m "Cambios v1"`: sirve para generar cambios sobre la versión antigua.
- `git status`: sirve para revisar si has modificado o guardado los cambios hechos.
- `git log "archivo.txt"`: sirve para ver el historial del archivo.
- `git push`: sirve para enviar cambios al repositorio remoto.
- `git pull`: sirve para recibir cambios de repositorio remoto a local.

Ciclos de vida o estados de los archivos en Git

Cuando trabajamos con Git nuestros archivos pueden vivir y moverse entre 4 diferentes
estados (cuando trabajamos remoto pueden ser más estados, pero lo estudiaremos más
adelante)

- **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 por que falta ejecutar el comando git commit.
- **Archivos** ***Unstaged***: entiéndelos como archivos "Traked 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 esta desactualizado, sus
últimas versiones solo estan guardadas en su disco duro.
- **Archivos** ***Untracked***: son archivos que NO viven dentro de Git, solo en el disco
duro. Nunca han sido afectados por git add, asi que Git no tiene registro de su existencia.

Recuerda que hay un caso muy raro donde los archivos tienen dos estados al mismo tiempo:
Staged y Untracked. Esto pasa cuando guardas los cambios de un archivo en el área de
Staging (con el comando git commit), pero antes de hacer commit para guardar los cambios
en el repositorio haces nuevos cambios que todavía no han sido guardados en el área de
Staging (en realidad, todo sigue funcionando igual pero es un poco divertido).

Comandos para mover archivos entre los estados de Git

- `git status`: nos permite ver el estado de todos nuestros archivos y carpetas.
- `git add`: nos 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 los archivos del estado Staged para devolverlos a su
estado anterior. Si los archivos venían de Unstaged, vuelven allí. Y lo mismo si 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 pedira que
dejemos un mensaje para recordar los cambios que hicimos y podemos usar el argumento -m
para describirlo ( git commit -m "mensaje").
- `git rm`: este comando necesita algunos de los argumentos para poder ejecutarse
correctamente:
- `git rm --cached`: Mueve los archivos que le indiquemos al estado Untracked.
- `git rm --force`: Elimina los archivos de Git y del disco duro. Git guarda el registro de la
existencia de los archivos, por lo que podremos recuperarlos si es necesario (pero debemos
usar comandos más avanzados).

¿Qué es un Branch y cómo funciona un Merge?

Checkout es para cambiar de rama. Sólo la crea con el modificador -b. Unir dos Ramas lo
conocemos como Merge.

Estándar de equipos de desarrollo.

- Rama ***Master*** o ***Main***: va a producción.
- Rama ***Development***: se alojan las nuevas features, características y experimentos
(para unirse al Máster cuando estén definitivamente listas).
- Rama ***Hotfix***: issues o errores se solucionan aquí para unirse al Master tan pronto sea
posible.
## Crea un repositorio de Git y haz tu primer commit
Le indicaremos a Git que queremos crear un nuevo repositorio para utilizar un sistema de
control de versiones.
Solo debemos posicionarnos en la carpeta raíz de nuestro proyecto y ejecutar el comando git
init.

Recuerda que al ejecutar este comando (y de aquí en adelante) vamos a tener una nueva
carpeta llamada **.git** con toda la base de datos con cambios atómicos en nuestro proyecto.

Recuerda que Git está optimizado para trabajar en equipo, por lo tanto, debemos darle un
poco de información sobre nosotros. No debemos hacerlo todas las veces que ejecutamos un
comando, basta con ejecutar solo una vez los siguientes comandos con tu información:
```shell
git config --global user.name "tu nombre"
git config --global user.email "tu@email.com"
```
Existen muchas otras configuraciones de Git que puedes encontrar en el comando git config --
list (o solo git config para ver una explicación más detallada)

Analizar cambios en los archivos de tu proyecto

- `git log`: muestra la identificación de los commits.
- `git show`: nos muestra los cambios que han existido sobre un archivo y es muy útil para
detectar cuando se produjeron ciertos cambios, qué se rompió y cómo lo podemos solucionar.
Pero podemos ser más detallados.
- `git diff`: nos muestra la diferencia entre una version y otra, no necesariamente todos los
cambios desde la creación. (Gif diff commitA commitB).

Reset y checkout
- `git checkout + Id del commit`: podemos volver a cualquier versión anterior de un archivo
específico o incluso de nuestro proyecto entero. Esta es también es la forma de movernos
entre ramas.
- `git log --stat`: commit descriptivo con cantidad de líneas agregadas y removidas por
archivo.
- `git reset --soft 'commit'`: mantiene los archivos en el área de Staging para que podamos
aplicar nuestros últimos cambios desde un commit anterior.
- `git reset --hard 'commit'`: borra toda la información que tengamos en el área de Staging.
(Perdiendo todo para siempre).
- `git checkout master 'archivo.txt'`: volvemos a la versión madre.

Ramas o branches
Las ramas son la forma 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 o
simplemente experimentar.

La cabecera o head representan la rama y el commit de esa rama donde estamos trabajando.
Por defecto, esta cabecera aparecerá en el último commit de nuestra rama principal. Pero
podemos cambiarlo al crear una rama (git branch rama, git checkout -b rama) o movernos en
el tiempo a cualquier otro commit de cualquier otra rama con los comandos ( git reset id-
commit, git checkout rama-o-id-commit).

```shell
git branch "nombre de rama" // crea una rama
git checkout "nombre de la rama" // cambiarse de rama
```

**NOTA**: Hacer commit antes de cambiar de ramas para no perder los datos.

Fusión de ramas con Git Merge

El comando git merge nos permite crear un nuevo commit con la combinación de dos ramas,
la rama donde nos encontramos cuando ejecutamos el comando y la rama que le pasamos
después del comando.

```shell
git merge "cualquier otra rama"
```

Resolución de conflictos al hacer un Merge

Git nunca borra nada a menos que se lo indiquemos. Cuando usamos los comandos git merge
o git checkout estamos cambiando de rama pero creando un nuevo commit, no borrando
ramas ni commits (recuerda que puedes borrar commits con `git reset` / `git branch -d`)

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.

Uso de GitHub

Github es una plataforma que nos permite guardar repositorios de git que podemos usar como
servidores remotos y ejecutar algunos comandos de forma visual e interactiva (sin necesidad
de consola de mandos).
Luego de crear nuestra cuenta, podemos crear o importar repositorios, crear organizadores y
proyectos de trabajo, descubrir respositorios de otras personas, contribuir a esos proyectos,
dar estrellas y muchas otras cosas.
El Readme.md es el archivo que veremos por defecto al entrar en un repositorio. Es una muy
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 el
URL (por ahora, usando HTTPS) y ejecutar el comando git clone + la URL que acabamos de
copiar. Esto descargara la versión de nuestro proyecto que se encuentra en GitHub.
Sin embargo, esto solo funciona para las personas que quieren empezar a contribuir en el
proyecto. Si queremos conectar el repositorio de GitHub con nuestro repositorio local, el que
creamos con git init, debemos ejecutar las siguientes instrucciones:

- **Primero:** Guardar la URL del repositorio de GitHub con el nombre de origin

```bash
git remote add origin <URL>
```
- **Segundo**: Verificar que la URL se haya guardado correctamente
```bash
git remote
git remote -v
```
- **Tercero**: 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 merge o solo git pull con el
flag --allow-unrelated-histories:
```bash
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
```bash
git push origin master
```

Manejo de ramas en GitHub

Puedes trabajar con ramas que nunca enviamos a GitHub, así como pueden haber ramas
importantes en GitHub que nunca usas en el repositorio local. Lo importante es que aprendas
a manejarlas para trabajar profesionalmente.

- **Crear una rama en el repositorio local**:

```bash
git branch "nombre de la rama"
o
git "nombre de la rama"
```
- **Publicar una rama local, al repositorio remoto**:
```bash
git push origin "nombre de la rama"
```
Recuerda que podemos ver gráficamente nuestro entorno y flujo de trabajo local con Git
usando el comando `gitk`.

Configurar múltiples colaboradores en un repositorio de GitHub

Por defecto, cualquiera puede clonar o descargar tu proyecto desde GitHub, pero no pueden
crear commits, ni ramas ni nada.
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.
Solo debemos entrar a la configuración de colaboradores de nuestro proyecto (Repositorio >
Settings > Collaborators) y añadir el email o username de los nuevos colaboradores.

Flujo de trabajo profesional con ***pull requests***

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 a el servidor de producción con el ya antes
mencionado merge request.

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 comúnmente tienen la extensión
***.env*** o cuando te estas conectando a una base de datos, son archivos que nadie debe
ver.

#### Reconstruir commits en Git con ***amend***

A veces hacemos un commit, pero resulta que no queríamos mandarlo porque faltaba algo
más. Utilizamos `git commit --amend`, amend en inglés es remendar y lo que hará es que los
cambios que hicimos nos los agrega al commit anterior.

#### Git ***reset*** y ***reflog***: úsese en caso de emergencia

¿Qué pasa cuando todo se rompe y no sabemos qué está pasando?
Con git reset hashDelHEAD nos devolvemos 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.

Git reset es una mala práctica, no deberías usarlo en ningún momento; debe ser nuestro último
recurso.

Buscar en archivos y commits de Git con ***grep*** y ***log***

A medida que nuestro proyecto se hace grande vamos a querer buscar ciertas cosas.
Por ejemplo: ¿Cuántas veces en nuestro proyecto utilizamos la palabra color?
Para buscar utilizamos 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 que línea está lo qué
estamos buscando.
- **Con git grep -c color** nos saldrá un output el cual nos dirá cuantas 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 "atributo"**.

----------------------------

Expresiones vs Statements

Podemos decir que todo el código que escribimos en JS o "hace algo" o "retorna algo" (o una
combinación de los dos). En la terminología de lenguajes de programación esta diferencia está
clasificada en la definición de **expressions** (expresiones) y **statements** (sentencias).

Podriamos definir conceptualmente a ambas como:

- Una **expression** siempre se convierte (retorna) un valor.
- Un **statement** realiza una acción.

Cuando escribimos código, todo el tiempo mezclamos expresiones y statements para

conseguir el resultado final. Por lo tanto, al principio es un poco difícil ver la diferencia entre
las dos, pero vamos a intentar ejemplificar lo anterior:
```js
// retorna algo
1+1
Math.pow(2, 3) + 4;
'hola' + ' soy una expression';
```
`1 + 1` intuitivamente se convierte o resuelve a `2`! eso es una expresión. Es cualquier cosa
que escribamos y esperamos que se convierta en otro valor.
Cuando *pegamos* una expression en la consola de Firefox o de Chrome, vamos a poder ver
el resultado al que resuelve:
```js
// hace algo
if (condicion) {
  // código ejecutado si es true
} else {
  // código ejecutado si es false
}
```
En este ejemplo, vemos que el `if` "hace algo", es decir, escribimos el if para que bifurque le
ejecución del código según el valor de `condicion`. Como ya sabemos, si `condicion` tiene un
valor *verdadero* entonces se ejecutará el bloque de código de arriba, y si no, el de abajo.
Fijensé que acá es importante discriminar lo que está *adentro* de los bloques de código, ya
que ahí adentro podríamos escribir **expresiones** que sí devuelvan algo.
Nos podemos dar cuenta que algo es un statement, porque si lo *pegamos* en la consola del
intérprete -por ejemplo, en la consola del Firefox o Chrome- vamos a ver que no produce
ningún resultado:
> Una regla fácil para distinguir entre una *expression* y un *statement* en JS es la
siguiente:
  Si podemos ponerlo dentro de un `console.log`, es una *expression*, si no, es un
*statement*.
  Por ejemplo:
  ```js
    // expresiones!
    console.log(1 + 1);
    console.log(Math.pow(2,3) + 22);
  
    // statements
    console.log(if( true) {
      // código
    });
    // jamás haríamos esto de arriba, no?
  ```

> El **operador ternario**, es una expresión o un statement? ej: (numero > 10 ? 'mayor' :
'menor');

Expressions

Cómo dijimos arriba, una *expression* es cualquier pedazo de código **que pueda ser
evaluado a un valor**. Justamente por esto, las vamos a usar en lugares donde JavaScript
*espera un valor*. Por ejemplo, cómo cuando pasamos una expresión como argumento de
una función.

Según la documentación de MDN, las expresiones se pueden clasificar en las siguientes

categorías:

Expresiones Aritméticas
Son las expresiones que resuelven a un valor **numérico**. Por ejemplo:
```js
10;
1 + 10;
2 * 16;
```
Expresiones de Strings
Son expresiones que resuelven a una **string**. Por ejemplo:
```js
'hola';
'hola' + ' como va?';
```

Expresiones lógicas
Son expresiones que resuelven a un valor **booleano**. Por ejemplo:
```js
10 > 9;
11 === 2;
false;
```

Expresiones primarias
Son expresiones que se escriben por sí mismas, y no utilizan ningún operador. Incluyen a
valores literales, uso de variables, y algunos keywords de JS. Por ejemplo:
```js
'hola';
23;
true;
this;  // hace referencia al keyword this
numero; // hace referencia a la variable numero
```

Expresiones de asignación
Cuando utilizamos el operador `=` hablamos de un *assigment expression*. Está expresión
retorna el valor asignado. Por ejemplo:
```js
a = 1; // si probamos esto en la consola, vemos que retorna el valor 1.
var c = (a = 2); // vamos a ver que dentro de la variable c, está el valor retornado por la
expresion `a = 2`
```
> Este es un caso muy particular, nótese que esta expresión retornar un valor, **pero a su vez
hace algo**!! Ese algo, es guardar el valor a la derecha del signo `=` en la variable a la
izquierda del signo `=`.
  Otra cosa a notar, es que si usamos el keyword `var` la expresión retorna `undefined`, es
decir, no es lo mismo una asignación que una declaración de variables.

Expresiones con efectos secundarios (side effects)

Son expresiones que al ser evaluadas retornan algo, pero a su vez tienen *un efecto
secundario* (incrementar un valor, etc...). Por ejemplo:
```js
contador++; // retorna el valor de contador e incrementa uno.
++contador; // incrementa el valor de contador y retorna el valor;

mult *= 2;// multiplica mult por dos, asigna ese valor a mult y retorna el valor;
```
Statements (sentencias)
Los *Statements* son instrucciones que le damos al intérprete de JS para que **haga algo**,
ese algo puede ser: crear una variable, ejecutar un bloque de código N veces, ejecutar un
bloque de código o no según una condición de verdad, declarar una función, etc...

Podemos clasificar a los Statements en las siguientes categorías:

Declaration Statements
Este tipo de statements indican al intérprete que declare variables o funciones, se utiliza el
keyword `function` y `var`. Por ejemplo:
```js
var prueba; // declaro la variable prueba
var toni;  // declaro la variable toni

function suma(a, b) {  // declaro la función suma;

  // bloque de código
}
```
> Habíamos dicho que por regla general lo que podamos pasarle a una función (por ejemplo,
`console.log`) por argumento era una expresión... y muchas veces pasamos una declaración de
una función por argumento. Esto sucede porque en JS existen tambien las **function
expressions**.

Function expressions vs function declarations

Cuando declaramos una función el intérprete puede *interpretarla* como un statement o
cómo una expresión, dependiendo del contexto. Por ejemplo:
```js
//function declaration

function resta(a, b) {
 // bloque de código
}

// function expression

var resta = function (a, b) {

  // bloque de código
}

array.map(function() {
  // código;
});
// el argumento de la función espera una expression

// Immediately Invoked Function Expression

(function () {
    console.log('IIFE');
})();
```

Cómo vemos en el ejemplo de arriba, el intérprete *hace algo*: declara la función. Por lo
tanto es un statement. En cambio, en el segundo ejemplo, estamos haciendo una asignación, y
la asignación espera una *expresión* en la parte de la derecha, asi que le estamos pasando un
function expression.

> Nótese que un function expression puede no tener nombre. Estas son las llamadas
**funciones anónimas**.

Conditional Statements
Estos statements sirven para controlar el flujo de ejecución de código según si se cumple o no
una condición. Por ejemplo:
```js
if (condicion) { // condicion puede ser cualquier expression!!
  // ejecuta este bloque si condicion es true
} else if (condicion2) {
  // ejecuta este bloque de código si condicion no es true y condicion2 es true
} else {
  // ejecuta este bloque de código si condicion y condicion2 no son true.
}
```

Loops (bucles) y Jumps (saltos)

Estos statements también controlan el flujo de ejecución del código, pero hacen que un bloque
se ejecute N veces (ej: `for`), o que la ejecución salte a otro contexto (ej: `return`). Por
ejemplo:
```js
// loops
while(condicion) { // condicion es una expresión!!
  // ejecuta este código mientras condicion sea true;
}

for (var i = 1; i < 10; i++) {

  // ejecuta este bloque de código 9 veces;
}

// jumps

function () {
  // bloque de código
  return;  // cuando llegue acá, sale de la ejecución de la función y retorna un valor;
  // bloque de código
}

for (var i = 1; i < 10; i++) {

  // ejecuta este bloque de código N veces;
  continue; // salta a la siguiente iteración del bucle;
  // desde acá no se ejecuta;
}

throw new Error('hubo un error, se termina la ejecución');

```
Expression Statements
JS tiene la particularidad qué en donde sea que el intérprete espera un *statement*, nosotros
podemos pasarle una *expresión*. Esto da lugar a los llamados *expression statements*.

> **Esto no funciona en sentido inverso, donde se espera una expresión *NO* podemos
pasar una statement**.