¿Qué es el staging?

De paso lean la frase que está ahí al costado ❤️

Aqui mis apuntes compañeros!

Esto se esta poniendo bueno…

Vengo del futuro (del final de las clases)
aca dejo los apuntes para el que le interee, igual concentrate en practicarlos todos a medida que vayas viendo las clases, porfavor no te agobies por la cantidad, es mas facil de lo que parece, igual que todo, poco a poco te vas a ir puliendo…

git init ( sirve para indicar la carpeta “previamente selecccionada” en la que se creara un repositorio en el disco duro o staggng)

git add “e.g. Archivo.txt” (sirve para agregar un archivo especifico al area de stagging)

git add . (sirve para agregar todos los archivos al area de stagging)

git commit -m “mensaje” (sirve para enviar todos los archivos del area de stagging al area del repositorio o “master”)

git show ( me muestra los cambios que han sido realizados a traves de las versiones)

git log ( me muestra las versiones que han sido guardadas en “Master”)

git checkout ( me permite devolver en el tiempo un archivo a una version anterior sin borrar la actual o simplemente toda la carpeta
para que me muestre la version anterior en un archivo en especifico debo indicar al final el nombre del archivo)

git diff (indicandole las versions que queremos, nos muestra las diferencias entre ellas)

git reset xxxxxxxxxxxxxxxxxxxxxx --hard (este devuelve en el tiempo el projecto y elimina todo lo realizado posteriormente a la version a la que estamos volviendo)

git reset xxxxxxxxxxxxxxxxxxxxxx – soft (este elimina los archivos del commit pero mantiene los archivos del area de stagging)

git reset xxxxxxxxxxxxxxxxxxxxxx head ( sirve para pasar los archivos de staging a unstaged en caso de que queramos editar algun archivo o lanzar en otra actualizacion
algun cambio que no era para este commit sino para un commit futuro)

git rm --cached: (Elimina los archivos del área de Staging y del próximo commit pero los mantiene en nuestro disco duro.)

git rm --force: (Elimina los archivos de Git y del disco duro. Git siempre guarda todo, por lo que podemos acceder al registro de la existencia de los archivos,
de modo que podremos recuperarlos si es necesario
(pero debemos usar comandos más avanzados).)

git clone url (sirve para clonar el proyecto de un repositorio ubicado en un servidor a mi repositorio y directorio de trabajo)

git push (sirve para enviar todos los datos actualizados en mi repositorio al repositorio del servidor.)

git fetch (importa un archivo que alguien mas cambio recientemente y no tienes en tu repositorio local, puedes usar git merge para combinar tus archivos,
en el directorio de trabajo con tu repositorio local para que quede unidos los cambios )

git merge (combina dos versiones)

git pull (a diferencia de fetch y merge al mismo tiempo, esta lo que hace es tomar los archivos,
actualizados del repositorio remoto y copiarlos tanto en mi repositorio local como en
mi directorio de trabajo, para asi tener una version actualizada del repositorio remoto.)

git commit -a (sirve para agregar directamente a master sin pasar por el staging)

git branch (sirve para ver las ramas creadas o sirve para crear una rama dependiendo de su uso, si usas el comando tal cual lo leiste,
solo te mostrara las ramas existentes, pero si lo usas de este modo e.g. (git branch "inserte aca nombre que le quiera proporcionar a la rama"
obviamente sin las comillas, crearas una rama nueva con el nombre que quieras.)

git commit -am (sirve para agregar al repositorio local los archivos que estas trackeando con un mensaje)

git remote add “origin” ( sirve para enviar el projecto en el que estamos trabajando a la base de datos o repositorio remoto)

git remote ( nos mostrara el repositorio remoto dispobible o existente)

git remote -v (nos indicara la direccion web del repositorio remoto)

git push “origin” “master”

git pull “origin” “master”

git pull “origin” “master” --allow-unrelated-histories ( sirve para forzar a combinar los archivos del repositoerio remoto con el repositorio local)

git config -l ( nos muestra las configuraciones de git)

gir config global --user.email "[email protected]"

git log --all

git log --all --graph --decorate --oneline" ( me muestra todos los commits realizados en el proyecto de manera que se pueden observar los mensajes y los merges)

alias arbolito=“git log --all --graph --decorate --oneline” (crear un alias, ese es el ejemplo, un alias ya sabes para que funciona)

git tag (me muestra las versionas realizadas es decir los tags

git tag -a v0.1 -m “Resultado de las primeras clases del curso” 5d10f9c (ejempplo de como se hacen los tag)

git show-ref --tags ( me muestra los tags con las versiones y a que commit estan relacionados.)

git push origin --tags ( enviar los tags)

git tag -d “NombreDeTag” (me permite eliminar un tag que le indique)

git push origin :refs/tags/dormido ( codigo para eliminar el tag de github)

git show-branch (nos muestra todas las ramas, y si le agregamos --all nos muestra mas datos)

gitk (abre en un software la historia del proyecto, de una manera ultravisual)

git remote add “upstream” (nos crea otrwa fuente nueva de donde podemos traer datos a nuestras rama amster)

git remote -v

git clone “link” (nos permite clonar un projecto publico)

cuando queremos que git ignore algun archivo, debemos crear un new file en el editor y guardarlo en el directorio
como “.gitignore” luego en el editos utilizaremos “*” para indicarle la extension de los archivos que queramos que
ignore

git rebase ( sirve para el momento de realizar un hotfix y que no se vea en el log de ramas el error)

git branch -D “rama Name” (elimina una rama)

git stash (me devuelve el proyecto al estado anterior antes de ralizar algun cambio, manteniendo el cambio guardado temporalmente, es como presionar cntrl+z en Vs code)

git stash pop ( me devuelve al proyecto luego de hacer los cambios antes de aplicar el stash)

git stash list ( me muestra una lista de los stash)

git stash branch “branch name” (lo que hace es que si existe un stash, esto lo mueve a esa nueva rama, realizas un commit y queda gurdado el trabajo alli)

git stash drop ( sirve para borrar los stash realizados)

git clean (sirve para borrar archivos no deseados, o que no utilizas realmente en tu repositorio, agregando “–dry-run” muestra todo lo que va a borrar el comando
pero si agregamos -f borra todo el listado que te muestra el comando anterior sin preguntar

git cherry-pick (sirve para traer un commit de otro rama a la que te encuentres(ES MALA PRACTICA))

git reflog (aun habiendo eliminado los errores con un git reset --hard, este muestra el log de los errores cometidos, aquellos que no
se ven en un “git log”)

git grep (busca en el proyecto las palabras usadas, el nombre de un archivo o lo que sea que le mandes a buscar, y si agregas “-n” te dice inclusive
en que lineas se utiliza… si utilizamos “-c” nos indica las veces que utilizamos esas palabras)

git log -S “palabra a buscar” (busca la palabra que estas buscando en el historial o commits)

git blame “nombre del archivo” (sirve para ver los commits realizados por las diferentes personas en orden con todos los datos si agregamos “-c” se ve un poco mejor)

si utilizamos

git blame “nombre del archivo” “-L35,53” (nos muestra los cambios realizados por las personas en entre las lineas especificadas.)

comandos y recursos colaborativos en git y github

git shortlog ( me muestra el nombre de las personas colaborando y los commits realizados por cada una de ellas.)

git shortlog -sn (me muestra los nombres y la cantidad en numeros de los commits que hicieron)

git shortlog -sn --all (muestra inclusive los commits borrados)

git shortlog -sn -all --no-merges (lo mismo que el anterior pero omite contar los merges)

git congfig --global alias.(nombre del comando) “git shortlog -sn -all --no-merges”

git branch -r (te permite ver las ramas remotas en tu servidor)

git branch - a (te muestra las ramas locales y las remotas)

agrego el amend aca porque es un proceso por pasos:

para que sirve: cuaqndo realizas un commit pero en el commit olvidaste realizar una parte del trabajo o arreglar un detalle.

1ro. debes hacer tu cambio y verificar que colocaste el codigo bien y todo lo demas en tu editor de codigo como normalmente lo haces.

2do. vas a realizar un git add “aqui vas a indicar el archivo que tiene los cambios que no colocaste”.

3ro. luego de agregar los archivos a staging vas a realizar un git commit --amend (esto agrega el archivo al que le hiciste los cambios al commi anterior.)

y listo, problema resuelto 😄

Keygen ssh creaton proceedements

code:

ssh-keygen -t rsa -b 4096 -C "[email protected]" (para crear el security shell debes introducir el codigo ssh-keygen donde "-t"
nos indicara la complejidad del algoritmo que vamos a utilizar en este caso “rsa"
y -b nos indicara la complejidad de la llave en este caso usaremos “4096” y por ultimo
-C es donde indicaremos el correo a usar "[email protected]”

eval $(ssh-agent -s) (sirve para verificar si el cifrador de llaves esta funcionando en el sistema operativo, es igual en linux y en windows.)

para efectos de un mejor entendimiento se explicaran los siguientes signos a explicar en cada comando;

• “”: la utilizacion de comillas indicara que luego del comando debe ir un nombre que indicara la creacion o el cambio de un archivo hacia otro, de una rama hacia otra
  del envio del projecto al repositorio remoto.

Md= mark down
para que el repositorio se vea como pagina principal hay que escribir por eejempllo en mi caso

;Espancake.github.io

el git rebase solo debe hacerse en repositorios locales, no debe hacerce e repositorios remotos, es muy mala practica.

agregar --help al comando nos abre el manual del mismo.

Notas destacadas del curso:

windows y mac tienenn un standard de tildes distinto es un problema de unicode o de utf -8

se puede solucionar mediante el siguiente meta charset ;

<head>
<metacharset=“UTF-8” />
…
</head>

== Comparto mis apuntes == …

Ya he usado Git y mas o menos se puede decir que yo sabía como usarlo, pero no tenía ni idea que el staging era lo que se almacenaba en la memoria RAM, ahora todo va teniendo sentido. La diferencia entre saber usar algo y entender como funciona.

Conceptos básicos

Directorio: Es la carpeta del proyecto que está en tu disco duro
Staging: Es donde se guardan las modificaciones del archivo antes de enviar la versión final al repositorio (staging es como tener la milanesa empanizada pero no freída).
Repositorio: Es la carpeta donde se guardan las versiones finales de los archivos, todos los que trabajen en el mismo proyecto tienen acceso a esta carpeta y pueden ver qué se ha modificado de un archivo y quién lo realizó.

Estados de un archivo
Untracked: Son todos aquellos archivos que están en el disco duro que no conoce Git.
Staged: Son los archivos que se encuentran en Staging.
Tracked: Son archivos que están en el repositorio o en staging.
Unstaged: Son archivos tracked que han sido modificados, pero no han sido guardados los cambios en staging.

Comandos necesarios

$git mkdir: Crea un directorio.
$git touch: Crea un archivo.
$git init: Define la carpeta del proyecto, crea el staging y el repositorio.
$git add: Guarda la versión del archivo en staging.
$git commit -m””: Guarda el archivo en el repositorio, cada vez que se ejecuta este comando se crea una nueva versión del archivo en el repositorio (en la comillas de -m”” se escribe un comentario sobre las modificaciones para hacer que tus compañeros y tu comprendan posteriormente cuáles fueron los cambios).
$git rm --cached: Cambia el estado de los archivos a untracked.
$git rm --force: Elimina los archivos tanto en el disco duro como en el flujo de Git, aunque queda registro de ese archivo por si se necesita recuperarlo
$checkout: En caso de tener una versión desactualizada de un archivo que está en el repositorio, este comando trae los cambios necesarios al disco duro.

Flujo básico de Git

1. Con el comando $git mkdir se crea un directorio y los archivos necesarios, los cuales están en estado untracked.
2. Con el comando $git init se determina el directorio del proyecto, se crea el repositorio y staging.
3. Con el comando $git touch se crean los archivos necesarios.
   4)Conforme se modifican los archivos, se crean versiones de estos con el comando $git add.
   5)Al terminar de trabajar en los archivos se guardan en el repositorio con el comando $git commit -m””.

Como suele decir Freddy, “no se asusten solo confien en mi”, mas adelante con ejemplo se entendera esta parte

Como me gustan las descripciones gráficas y los “charts” les comparto esta “infografía” que describe de manera simple los procesos iniciales que realizamos en la consola con git.

Por si alguien quiere visitarlo, les dejo un articulo que escribí sobre algunos comandos de Git
https://agustinducca.com/blog/git-17-trucos-y-comandos-para-que-lo-domines-como-un-profesional/

Curioso que Freddy afirme que el Staging Area está en RAM. De acuerdo a la documentación oficial:

The staging area is a simple file, generally contained in your Git directory, that stores information about what will go into your next commit. It’s sometimes referred to as the index, but it’s becoming standard to refer to it as the staging area.

Lo cual es consistente con cómo funciona Git, donde todo (o casi todo) está respaldado por un archivo (branches, tags, commits).

👀 Para prácticar online los comandos de Git 👉
http://git-school.github.io/visualizing-git/

$ git init
Crea un espacio en memoria RAM staging
Crea el repositorio .git

$git add.
Se guardan los cambios/archivos en staging

$git commit -m ""
Se guardan los cambios/archivos en el repositorio(master)

Untracked cuando no se ejecutó $git add.
Tracked cuando se ejecutó $git add.

*Con la práctica te convertirás en un profesional destacado

me parece que podría se útil referirse al traducción de los términos así por ejemplo:

staged = en etapa, significaría que el archivo está “en tránsito”.

tracked = localizar, rastreado. Significaría que está ya “Ubicado en el repositorio”.

unstaged = El archivo está desactualizado en el repositorio. (hay una versión vieja en tracked)

untracked = con este archivo todavia no pasa Nada de nada! no está en etapa, ni está en el repositorio.

entonces:

1.- para poner el archivo en staged uso git add

2.- para pasar de staged a tracked uso git commit

3.- unstaged: es un archivo desactualizado de los repositorios. actualizalo con los dos primeros pasos.

4.- untracked : no se ha ejecutado Ningún comando git para ese archivo

Comandos principales
git init:

• Se crea una área en memoria ram llamada staging, el staging es donde al principio se van agregando los cambios.
• Se crea el repositorio (con el nombre “master” por defecto), ahí van a estar todos los cambios al final del proyecto (conocida como la carpeta /.git /).

git add:

• Este comando agrega los cambios realizados al archivo en el staging área.

git commit:
-Envía el archivo con los cambios realizados al repositorio. (Si se quiere enviar un mensaje se utiliza el comando git commit -m “Mensaje del commit”).

Entonces llegamos a la conclusión de que staging es el estado temporal en donde se agrega archivos que se van cambiando, y el repositorio real es al que se llega cuando se hace un git commit
El repositorio (master) es en donde van a estar todos los cambios realizados.

Estados del archivo
++Untracked: ++
-Cuado aún no se le da git add al archivo, esta sin rastrear.

++Tracked: ++
-Cuando ya se le da el git add y es parte del staging, esta “trackeado”

Traer un cambio del repositorio
Si se desea traer un archivo modificado del repositorio pero que no está en nuestra carpeta (básicamente que alguien más lo realizo) vas a esa “rama” y para traer ese archivo a nuestra carpeta se utiliza el comando git checkout.
Dependiendo de como se modifique el comando git checkout se pueden traer todos los cambios, o ciertos cambios o los cambios de ciertos archivos.

Recuerda que cada vez que se hace un git commit del archivo hacia el repositorio sé esta creando varias versiones (v1, v2, v3, etc) cada git commit es una nueva versión de cambios del archivo hacia el repositorio.

Viendo los comentarios e investigando escontré está página muy útil y explicativa para que la exploren sobre algunos de los comandos en Github
https://gitexplorer.com/

El directorio sera la carpeta donde se almacenaran nuestros archivos localmente.
El Staging es el lugar de preparación en la RAM antes de enviar los cambios de nuestro archivo en repositorio.
El repositorio es el lugar donde se almacenan los cambios de nuestro archivo.
1.- Al escribir git init en nuestra consola se crea el staging en la memoria RAM, que es donde agregaremos los cambios de nuestros archivos temporalmente, y se crea un repositorio, donde finalmente se guardaran los cambios.
2.- Cuando escribimos git add myarchive.txt pasara al staging.
3.- Al escribir commit myarchive.txt pasara al repositorio, puedes agregar un mensaje escribiendo el parámetro -m.
4.- Para eliminar un archivo en staging (antes de mandarlo al repositorio) se escribir git rm myarchive.txt.

Git tiene un documento de apoyo que podemos usar para la explicación de este vídeo. Para quién guste de leer el documento oficial acá encontramos la documentación completa.
Adicionalmente, con lo que se comentó en la clase acá hay un gráfico y una explicación de como se guardan los cambios.

Es importante aprender del ciclo de trabajo. Directorio - Staging - Repositorio

mis Apuntes!

😉 Si hay algo que tiene Platzi es una comunidad de estudiantes increíbles, miren chicos y chicas todos sus aportes son tan importantes y relevantes como la misma clase del profesor, incluso yo inicialmente doy una rapida ojeada a los aportes pero al final hago una pausa justo antes de finalizar el video y me leo cada comentario y aporte, tengo que decir que estoy agradecido por que allí encuentro respuestas a muchas de mis dudas, respuestas que me surgen durante la reproducción de la clase, y a decir verdad esto me da gusto, estudiar en Platzi. 👨🏼‍💻👍

Os comparto una que encontré. Además, en este link está uno INTERACTIVO que está super completo

Flujo de empujado de cambios

Es importante saber cuál es el estatus de tus cambios, ya que al modificar un archivo, éste no por defecto se va a git, sino que se modifica en el working directory, para que sea trackeado por git debe de pasar por el staging area y llegar al repositorio, opcionalmente podría llegar al repositorio remoto. A continuación más detalle.
.

• Working directory (Local): El working directory es el espacio de trabajo no rastreado por git, al modificar un archivo, este se modificará en el working directory andtes de que le des git add para agregarlo al staging area.

• Staging Area: Es un espacio en memoria ram dónde están guardados los cambios, pero todavía no están en el repositorio (no son trackeados por git). para agregar al staging area se utiliza el comando git add

  git add archivo.txt #Agrega el archivo.txt al staging area
  git add . #Agrega todos los cambios de los archivos en las subcarpetas del directorio en el que te encuentras al staging area
  git add -A #Agrega todos los cambios del repositorio en el que estás trabajando al staging area
  

• Git repository: Es el lugar dónde se trackean los cambios, cuando algo está en el repositorio, ya está en la historia de git y puedes acceder a ese historial mediante los commits. git commit

  git commit -m 'Commit 1' #Crea un commit (sube los cambios al repositorio local) con el nombre 'Commit 1'
  git commit #Se prepara para hacer commit y abre el editor por defecto de la terminal para ponerle nombre
  

  Es una buena práctica ser descriptivos con los cambios que se hicieron en cada commit.

• Remote repository: Acá entra github, el repositorio remoto es una copia de tu repositorio local, pero en Internet. Para mandar cambios al repositorio remoto es con el comando git push

  git push origin master #Empuja (envía) los cambios de la rama master al servidor remoto 'origin' 
  

Se nota la diferencia en como Freddy imparte sus clases sin duda para mi es el mejor. en su mayoría cuando imparten sus clases lo hacen como que si alguien los estuviera corriéndo y quieren abarcar todo el contenido posibles, a comparación de Freddy es otro nivel.

En este link explican a profundidad el staging area: https://hackernoon.com/understanding-git-index-4821a0765cf

					***Micro Resumen***

git init /.git/
Directorio => Staging Area => Repositorio

git add : mueve una archivo desde el Directorio al Staging
git commit -m “mensajePersonalizado” : Mueve el archivo que está en el Staging al Repositorio
git checkout ‘nombreRama’ : para mudarse de rama, en caso de que se desee actualizar algún archivo modificado por algún miembro de tu equipo y que aún no lo hayas actualizado
Estados de un archivo
Untracked(Sin rastrear) : El archivo se encuentra en este estado cuando aún se encuentra en el Directorio
Tracked (Rastreado) : El archivo se encuentra en este estado cuando pasa del Directorio al Staging.

¡Saludos! Este resumen (cheatsheet) me ha resultado muy útil. https://education.github.com/git-cheat-sheet-education.pdf

Hice un mapa mental para entenderlo mejor:

• Al momento de ejecutar el comando “git init” en nuestra carpeta que contiene nuestro proyecto se separa un espacio de memoria RAM llamada,
  a esto se le llama “Staging”. Allí es donde se irán guardando los cambios. Para agregar archivos a “staging area”, utilizamos el comando: git add nombre_archivo.

• Lo que conocemos como repositorio es una carpeta que (inicialmente esta oculta) que se llama “.git”; Allí estarán todos los cambios que realicemos al final.
  Para agregar los archivos al repositorio utilizamos el comando : commit -m “El mensaje del commit”.

  • El repositorio tiene un nombre por defecto : “Master”.
  • “-m” significa asignarle un mensaje a el commit.
  • cada commit es una nueva versión del repositorio.

• **chekout **: es un comando que se utiliza para traer los últimos cambios o una versión anterior de un archivo directo hacia nuestra carpeta.
  Nota : Dependiendo como se modifique este comando podremos traer todos los cambios o ciertos cambios o los cambios de ciertos archivos.

    				Estados de un archivo en git.
  

• Untracked : Es cuando el archivo se encuentra en la maquina local.

• Track : Es cuando el archivo se encuentra en el “staging area”.
  Nota : Es posible tener un archivo con modificaciones pero que no se encuentre en el “staging area”.

Hay un pequeño error en la descripción, a ver si alguien me puede decir por qué:
Original
Podemos usar git nombre-del-archivo-o-carpeta para añadir archivos y carpetas
Corrección
Podemos usar git add nombre-del-archivo-o-carpeta para añadir archivos y carpetas

Comandos:
git init - Se crea el área en memoria ram llamada “staging” y se crea el repositorio llamada “.git” (carpeta oculta)
git add NombreArchivo - Agrega el archivo al staging area, se prepara para ser enviado al repositorio. Se pueden agregar mas archivos y remover de ese área usando el comando git rm NombreArchivo.
git commit -m “Mensaje” - El archivo se envía al repositorio, nombre por defecto “Master”. Se crean nuevas versiones.
git checkout - Trae los cambios, según el tiempo que se escoja, hacia tu área de trabajo.

Estados del archivo:
Sin rastrear - Untracked
Cuando se emplea el comando git add - Tracked

https://www.notion.so/S-per-poderes-en-Git-d4cda44a823c4c2984ead9d2af84b598

![](

En resumen los directorios/carpetas contienen archivos (historia.txt) al no ser agregados con el comando git add están en el estado untracked, al momento de agregarlos con ADD pasan a ser tracked y se guardan temporalmente en STAGING ( en la memoria RAM) y finalmente cuando realizo un commit recién se guarda en el repositorio /.git/

Ciclo de vida de un archivo en Git

Si de todos modos voy a hacer commit, ¿Para qué querría hacer staging con git add?
Cuando empecé a usar git esta era una de mis más grandes dudas, desde una perspectiva “practica” (y obviamente limitada) me parecía que el staging no tenía un propósito si de todos modos al final solo le iba a dar git add . y luego con git commit -m ‘{mensaje}’ todo se iba a "commitear"
Con unos pocos meses de experiencia de usar git descubrí que hacer git add . indiscriminadamente es una pésima práctica, por ejemplo, a veces mientras estas desarrollando una funcionalidad puedes acabar descubriendo a la mitad de tu desarrollo que hay un pequeño bug que te estorba y solamente requieres reparar o añadir un par de líneas de código en otro archivo para solucionarlo. si lo solucionas y sigues con tu trabajo para luego commitear todo no sabrás exactamente en qué punto reparaste el bug, si commiteas todo al momento de resolver el bug, el desarrollo que estabas haciendo quedará a la mitad. Es para estos casos que nos ayuda el staging, pues podemos mandar a Staging únicamente el archivo reparado para comittearlo como una nueva versión en dónde únicamente se repara el bug y seguir con nuestro trabajo. sirviéndonos así el área de staging como un filtro para poder hacer pequeños commits auto contenidos.
Cabe aclarar que este es solo un ejemplo de uno de los multiples usos del area de staging.
**tldr: **El staging nos sirve en la práctica para, entre otras cosas, hacer commits pequeños y auto contenidos. Usar git add . indiscriminadamente es una mala práctica.

Resumiendo y espero haber entendido todo :

Al comenzar un proyecto tenemos nuestra carpeta llamada por ejemplo “Proyecto1” esta carpeta esta y el proyecto en si esta en un estado “untracked” hasta que desde la consola ejecutemos el comando >> git init.
El ejecutar este comando nos permite ahora acceder a todos los comandos de git. Al realizar un cambio en un archivo que ya fue inicializado en git, debemos de llevarlo al staging y para eso tenemos que ejecutar >> git add ejemplo.txt. Al hacer esto se guardan nuestros cambios en espacio de memoria ram pero aun no van a estar guardados por completo, para terminar con el cambio de un archivo debemos de ejectuar el comando >>git commit -m"version1" y esto lo guardara por completo dentro de nuestro repositorio, caso contrario nuestro archivo estara en espera dentro del staging.

Les comparto mi apunte sobre funcionalidad y arquitectura Git.

Los nombres de las ramas en GitHub cambiaron. Dejo esta información antes de que lleguemos a los repositorios remotos al que pueda interesarle.

Al querer publicar tu rama local llamada ‘master’, GitHub no la reconocerá y creará una nueva, ¿por qué? porque GitHub cambió el nombre de su rama principal ‘master’ a ‘main’ desde mediados de este año, entonces si eres de esas personas que quiere tener impecable su repositorio remoto de GitHub y no tener más ramas de las necesarias te recomiendo esto:

$ git config --global init.defaultBranch main

Pero, ¿qué hace este comando? Básicamente estas diciéndole a Git que cada vez que ejecute el siguiente comando:

$ git init

El nuevo repositorio tendrá una rama principal llamada ‘main’ justo como está en GitHub.

Espero que les sirva. Saludos a todos 😃

Les dejo algunas preguntas para autoexaminarse para comprobar su aprendizaje de esta clase.

1. ¿Qué es el directorio?
2. ¿Qué es staging?
3. ¿Qué es el repositorio?
4. ¿Qué hace git add?
5. ¿Qué hace commit -m?
6. ¿Qué es la rama master?
7. ¿Qué hace el comando check out?
8. ¿Para qué se utiliza git init?
9. ¿Cuando inicia un archivo estar trackeado?
10. ¿Para qué se usan las ramas en git?

Pregunta: ¿Si el staging vive en la RAM significa que si tengo archivos allí y apago el pc sin hacer commit, se borra el staging?

Aca les dejo mi resumen de lo que va del curso 😉 ojala le sirva!!

Cuando uno escribe estas notas, interiorizas la clase y te ayuda a entenderla de manera más clara.
Dejo aquí mi aporte, lo iré alimentando en el transcurrir de las clases y cualquier recomendación bienvenida!

breve resumen:
Git init -> inicializa el repositorio en una carpeta.

Git add -> pasa la información de un archivo al área de staging.

Staging -> área en memoria ram que almacena la información que va a enviarse al repositorio.

Git commit-> envía la información al repositorio y genera versiones de nuestros archivos.

Checkout -> permite regresar un archivo a una versión anterior previamente guardada en el repositorio.

Ok bien, aprendi algo importante y es que el staging area se crea en Memoria RAM y que los archivos que aun no hayan sido agregados al repositorio SI TIENEN un “estatus” y este es Untracked.

La clase muy didactica y excelente. Freddy que marca y modelo es esa table que usas para la clase?

Vengo de unas clases mas adelante donde la recomendación es practicar y hacer nuestros propios experimentos interiorizando todo lo que vemos.

De nada sirve ver los videos si no practicamos.

Puede sonar muy obvio pero me pareció importante decirlo, Saludos.

He creado mi primer máster!!

Excelente clase! De lo mejor que he escuchado en Platzi! Claro.Simple.Preciso!

tambien puede bajar cambios utilizando el commando git pull

yo definiría a staging como; el estado en el que git sabe que has hecho cambios a un archivo y que están pendiente de subirlo al repositorio mediante el commit.

Acá les dejo un resumen que hice:

Corrijanme si algo está mal.

comandos:
ls: todos los archivos que hay en un directorio
-a: para ver todos los directorios ocultos
rm: borrar archivos
rmdir: borrar directorios
date: fecha del dia
ps ax: para ver todos los procesos que se estan trabajando
ls -l: quien tiene los prmisos asociados
chmomd, chown, chgrp: para alterar los permisos que tiene un permiso asocido
sudo: es el comando que se comvierte en ususuario para poder leer y escribir todo
lynx: navergador de lineas de comandos
pip, composer, npm: manejador de paquetes
lh: para leer mejor los archivos
locate, whereis, find: para encontrar todos los archivos perdidos
type f -mtime + el numero de dias que quieras buscar el archivo
curl wget: para ineractuar con el navegador
ssh: conoccion segura de datos
bash: es un interprete de comandos y un lenguaje de programacion
git init: arranca el dispositorio
git add biografia. txt: es el que arranca el archivo
git commit: es el que envia los archivos a la base de datos del sistema para controlar los cambios que se le han echo
git add . cuando le agregas el punto lo que hace el que agregas todos los archivos que hayan cambiado
git commit -m "cambios a v1"
git status: si has echo un cambio aqui se puede consultar
git show: todos los cambios historicos echos
git push: llevar tu archivo en un lugar donde todo el mundo lo pueda ver
mkdir: para crear una carpeta
cd: para navegar en una carpeta
history: para ver toda la linea de comandos que he escrito
! signo de admiracion mas el numero para ver el ultimo comando que ejecute

✨ git init permite realizar la configuración inicial de un repositorio nuevo, este creará un nuevo subdirectorio . git en tu directorio de trabajo actual.

![](

Comparto el enlace de descarga de un libro muy interesante para este curso, espero los ayude.
https://git-scm.com/book/es/v2

Video 8 y se sigue ejecutando

$ sudo apt-get upgrade

LOL

Mini Resumen:
Vemos los pasos para guardar una versión de nuestro proyecto.
Los archivos de nuestra carpeta, empiezan estando en una estado Untracked(es decir que no están “registrados” en git) una vez ejecutamos el comando git init ; estos archivos pasan a estar “registrados”(dentro de git) ,es cuando hacemos git add . que todos los archivos empiezan a ser “guardados” en la memoria RAM (zona llamada también Staged) y cuando hacemos el git commit -m “mensaje” es cuando pasan a guardarse con sus últimos cambios dentro del repositorio (es decir guardamos la versión de dichas modificaciones en el disco duro donde tenemos el proyecto)

Es importante saber que Directorio y carpeta son lo mismo.
Staging es la memoria RAM (es el estado temporal al que tu agregas archivos que van cambiando).
Cuando no hacemos git add significa que el archivo está sin rastrear, es decir untrack,
Cuando hacemos git add el archivo entra al estado track es decir, lo estamos rastreando y es ahí cuando el archivo entra a ser parte de staging es decir que está trackeado (rastreado).
Pero es cuando le damos commit-m que esos cambios pasan a estar trackeados en el repositorio.

Comol

Interesante clase.

¿En mac que posibilidades hay?

Me perdí un poco en las ramas,ojala en la siguiente clase aclare mis dudas

Muy buena explicación!! Hay definiciones que si es necesario precisar. Les comparto un link oficial de Git que leyendolo todo, logran despejar cualquier duda.
https://git-scm.com/book/es/v2/Fundamentos-de-Git-Guardando-cambios-en-el-Repositorio
Saludos

Estoy repasando los conceptos, ahora entiendo mucho mas!

Adoro las explicaciones de Freddy con dibujos 😃

Comapñeros, algunos aportes brindados por chat GPT:

• El Staging Area es como una sala de espera para tus archivos antes de que los envíes al repositorio. Puedes elegir qué archivos quieres llevar contigo y cuáles quieres dejar atrás.

• El Staging Area es como un probador de ropa en una tienda. Puedes probar diferentes combinaciones de archivos y ver cómo quedan antes de comprarlos (o sea, hacer commit).

• El Staging Area es como un filtro de café. Puedes poner todos los archivos que quieras en el filtro, pero solo los que pasen por los agujeros llegarán a la taza (o sea, al repositorio).

git init

En la clase el profesor Freddy inicia el video explicando el comando git init, y dice que suceden muchas cosas, en particular 2, se crea un área en memoria RAM que se llama staging que funciona en memoria RAM. ¿Es correcto decir el staging vive en la RAM? Si es así, entonces al apagar mi computadora voy a perder el staging y como esto se crea al ejecutar el comando git init no lo voy a volver a tener, ya que el repositorio solo se crea una vez, no es necesario volver a ejecutarlo.
Mucho agradeceré corrijan mi comentario.

Jajajajaja no envejece esta cara.

Git tiene tres estados principales en los que se pueden encontrar tus archivos: confirmado
(committed), modificado (modified), y preparado (staged).

Confirmado: significa que los datos están almacenados de manera segura en tu base de datos local.

Modificado:significa que has modificado el archivo pero todavía no lo has confirmado a tu base dedatos.

Preparado: significa que has marcado un archivo modificado en su versión actual para que vaya en tu próxima confirmación.

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

1. Modificas una serie de archivos en tu directorio de trabajo.
2. Preparas los archivos, añadiéndolos a tu área de preparación.
3. Confirmas los cambios, lo que toma los archivos tal y como están en el área de
   preparación y almacena esa copia instantánea de manera permanente en tu directorio
   de Git.

Mi pregunta es…

Git solo funciona con código? o por ejemplo si uso Photoshop también puede utilizarse?

Comparto un pequeño ejercicio que hice.

Que es el staging y los repositorios?

cuando entramos por consola a un archivo y usamos el comando
git init

se crea un area en memoria ram que se llama staging

y se crea el “repositorio”, es esa carpeta que se conoce como /.git/
ahi van a estar todos los cambios al final del proyecto

se agrega al “staging area” un archivo
usando el comando
git add nombreDeArchivo

ahora este archivo pasa a “vivir” en staging
el archivo está “esperando” a que lo envíes al repositorio

se pueden agregar otros archivos o se puede remover
usando el comando
git rm nombreDeArchivo

asumiendo que se quiere guardar el archivo
se usa el comando
commit

usando el argumento -m “mensaje que quiero agregar” se le puede agregar un mensaje
commit -m “~”

asi el archivo se va al repositorio
nombre por defecto del repositorio es master

Entonces:
staging es el estado temporal a donde se agregan archivos que se van cambiando
repositorio, donde se guarda cuando se hace commit

Estados del archivo
untracked o tracked (rastreado o no rastreado

cuando se usa git add el estado comienza a ser trackeado
y las modificaciones se van a “staging”

cuando se usa commit -m pasa a estar “trackeado” en el repositorio.
ahi es cuando todo el mundo puede ver los cambios que se hicieron
cada commit genera una nueva version del archivo.

para traer un “cambio” que está en el repositorio pero no está en tu carpeta
comando checkout.

Descripción de como funciona git en la memoria ram

STAGING es la meoria RAM. Es el estado temporal al que se agregan los archivos que van cambiando.

Ramas: romper en pedacitos tu código, y luego unirlos de vuelta!..excelente!

**Staging **: area en memoria ram donde se guardan tus cambios utilizando el comando git add, no es hasta cuando se usa el comando commit que lo mandas al repositorio

Checkout : comando que arrastra cambios de otros archivos del repo

Cuando entramos por consola a un archivo y escribimos el comando:
git init: Se crea un area en Memoria RAM (staging), y se crea un repositorio(.git/)
git add (nombre de archivo): Archivo pasa a staging
commit -m"…" : Mandas el archivo al repositorio (master),(version de cambios)
checkout: Trae los cambios de archivo a tu carpeta

Hola, encontré este pequeño error en la redacción.

Ciclo básico de trabajo:

Working directory - Staging área - Git repository

Existen 4 estados en los cuales pueden estar los archivos:

• Untracked: Archivos nuevos. Git no sabe que existen y si tecleas git add <file> estarán en:
• Staged: Git conoce el archivo y es parte del siguiente commit. Si se teclea git commit pasará a:
• Unchanged: El archivo no ha cambiado desde su último commit. Si se modifica se convierte en:
• unstaged: Modificado pero no forma parte del siguiente commit. Si usamos git add <file> pasará a
  staged.

Git Add es muy importante no deberíamos olvidarnos de ejecutar ese comando

git init
Construye su escritorio y mantiene un suministro infinito de cajas debajo de la superficie para colocar los elementos de trabajo para su almacenamiento.

git add
En el momento en que ejecuta un comando de agregar, está agregando al cuadro. Sí, agarra una caja. Cualquier caja. Ponle algo. Acabas de hacer un git add.

el staging es como el limbo

Solo puedo decir una cosa: PORQUE NO ME MATRICULE ANTESSSSSS

que excelente clase

Es cierto que suena medio enredado todo pero leyendo lo que explican los demás compañeros aquí en la sección de comentarios uno logra aclarar mas las cosas.

Viéndolo por niveles
Untracked: Archivos que no han pasado ni por git add ni por git commit
Staged: Archivos que ya fueron afectados por git add, pero después de eso sufrieron cambios y no se les ha vuelto a aplicar git add. Estos archivos nunca han formado parte del repositorio.
Untaged: Archivos que alguna vez ya fueron afectados por git add e incluso por git commit, pero la versión que está en el repositorio es vieja pues el archivo ya sufrió cambios en local. Esta nueva versión, no solo no está en el repositorio, sino que ni siquiera está en el Staging. Es decir, Git tiene una total versión de este archivo en el repositorio, pero antigua. La versión nueva, vive totalmente solo en el disco duro.
Tracked: La versión mas nueva está en el repositorio pues ya fue afectada por git add y git commit.

No estoy totalmente seguro de la parte que marqué en letra itálica, si alguien pudiera confirmarlo se lo agradecería mucho.

Hola, no me queda claro el uso del comando commit-m
me podrían ayudar? 😦

Comandos aprendidos por utilizar

git init 	#Se crea staging (en memoria ram) y repositorio (en hdd)
git add	#Se trackea cambios al staging
commit -m "versión x" #cambios en repositorio
checkout "brunch" #traer cambios de alguna rama

Mi resumen:
Git init: cuando aplicamos este comando sobre nuestro archivo, suceden 2 cosas:
Se crea un espacio en memoria llamado staging (funciona en memoria RAM y es donde al principio se van grabando mis cambios), y se crea el repositorio ( carpeta .git), en esta carpeta van a estar todos los cambios al final del proyecto.
Git add: cuando aplicamos este comando, más el nombre del archivo los cambios pasan a estar en staging (git add prueba.txt). En este momento el archivo queda a la espera de que lo enviemos al repositorio. En este punto podemos remover el archivo usando (git rm nombre archivo) o agregar otros archivos.
commit: podemos aplicar este comando para enviar los cambios a la carpeta repositorio que tiene el nombre de master (aqui van ha estar todos los cambios que haga). Se recomienda hacer commit con el argumento -m que nos permite dejar un comentario para documentar que hicimos (commit -m “Estos fueron los cambios”).
Estados del Archivo:
Si aún no hemos ejecutado el comando git add el archivo se encuentra sin rastrear Untracked.
Después de ejecutar el comando git add el archivo lo estamos rastreando y queda en estado Tracked, y en este punto hace parte de staging, en este punto el archivo está trackeado en staging, y cuando aplicamos el comando commit -m “mensaje”, pasan a estar trackeados en el repositorio.
Traer cambios del repositorio que no están en mi carpeta: debo ir a la carpeta master y aplicar el comando checkout, para traer los últimos cambios o los cambios que yo quiera a mi carpeta.
Cada que aplicó commit a mi archivo estoy creando una nueva versión de mi archivo en el repositorio.
Ramas: es romper en líneas de diferente tiempo nuestro código, para unirlas al final, se usa para trabajos en equipo donde cada programador trabaja en una parte específica del proyecto.