Flujo de trabajo básico con un repositorio remoto

Algunos comandos que pueden ayudar cuando colaboren con proyectos muy grandes de github:

1. git log --oneline - Te muestra el id commit y el título del commit.
2. git log --decorate- Te muestra donde se encuentra el head point en el log.
3. git log --stat - Explica el número de líneas que se cambiaron brevemente.
4. git log -p- Explica el número de líneas que se cambiaron y te muestra que se cambió en el contenido.
5. git shortlog - Indica que commits ha realizado un usuario, mostrando el usuario y el titulo de sus commits.
6. git log --graph --oneline --decorate y
7. git log --pretty=format:"%cn hizo un commit %h el dia %cd" - Muestra mensajes personalizados de los commits.
8. git log -3 - Limitamos el número de commits.
9. git log --after=“2018-1-2” ,
10. git log --after=“today” y
11. git log --after=“2018-1-2” --before=“today” - Commits para localizar por fechas.
12. git log --author=“Name Author” - Commits realizados por autor que cumplan exactamente con el nombre.
13. git log --grep=“INVIE” - Busca los commits que cumplan tal cual está escrito entre las comillas.
14. git log --grep=“INVIE” –i- Busca los commits que cumplan sin importar mayúsculas o minúsculas.
15. git log – index.html- Busca los commits en un archivo en específico.
16. git log -S “Por contenido”- Buscar los commits con el contenido dentro del archivo.
17. git log > log.txt - guardar los logs en un archivo txt

💫Dejo esto por aquí. Una nota que resume la clase.

¡Nunca pares de aprender! (Y practicar)🦄

Un resumen gráfico bastante útil!
Si consideran que le falta, avisen y lo mejoramos

Espero que a alguien le ayude.

¡Espero te guste! ❤️

@sebas.nop

Mi forma de estudiar y asimilar los videos de platzi es la siguiente:

1. Veo el video sin anotar ni codificar nada.
2. Veo el video nuevamente y voy codificando a medida que va reproduciendo el video, así asimilo lo nuevo. En caso de que el video vaya rápido y no me de tiempo de codificar lo mostrado, detengo el video, codifico y luego sigo.
3. Obviamente algunas veces, el contenido del video no se entiende o es dificil de asimilar. En este caso repito el video nuevamente o la parte del video que no entiendo.
4. Leo las notas del video y las copio en un archivito txt para consultar mas adelante por si se me olvida algo.
5. Leo los comentarios y anoto o copio lo más interesante.

Freddy debería dar más cursos!!

Un ligero resumen con dibujos de esta parte :3
link

Hola, les dejo mis apuntes de la clase.

"fredy es el mejor profesor,pero ustedes no estan listos para esta conversación"

Hola a todos , les comparto un resumen que monte de mas o menos el orden lógico del proyecto y uso de los comandos en GIT, espero les sea útil para imprimir y tener a la mano para dominar mejor todo.

Esta es la tercera vez que llego a esta clase y siempre tengo un sustillo cuando veo a freddy diciendo No veas esta clase a menos que hayas practicado todos los comandos de las clases anteriores.
Pero miro los videos dos veces uno tomando apuntes y el segundo para ver que entendí todo correctamente.

Recuerda que en la sección de recursos encuentras los slides que Freddy utiliza en esta clase!

Aquí dejo un mapa conceptual que hice:

Hola!

Me preguntaba porqué usar git fetch sobre git pull y bueno, encontré una muy buena respuesta aquí:

https://www.atlassian.com/git/tutorials/syncing/git-fetch

En una conclusión muy rápida, no está de más tener en cuenta que con pull llevas a cabo una actualización un poco más agresiva del repositorio local mientras que con fetch (y sus opciones) podrás hacer una revisión de lo que estás trayendo antes de afectar la copia local.

En palabras de Atlassian: “El comando git fetch es una pieza crítica del flujo de trabajo colaborativo de git. git fetch tiene un comportamiento similar a git pull aunque git fetch puede ser considerado como una versión más segura y no destructiva” [traducción propia].

Saludos!!

Apuntes

una historia de terror sobre control de versiones mientras van repasando…

https://www.xataka.com/cine-y-tv/como-pixar-recupero-toy-story-2-borrar-toda-pelicula-error-copia-seguridad

Mis anotaciones

#To config the user

$ git config --global user.name “johan7perez”
$ git config --global user.email "[email protected]"

#To see the current config
$ git config --list

#To see where the git configuration is stored
$ git config --list --show-origin

#To start a new empty project with git
$ git init

#To see the status of the current project
$ git status

#To add a new file/modificated file to the staging area
$ git add

#To remove a new file/modificated file from the staging area (cached, remove the file from the ram memory also)
$ git rm --cached

#To see the history of a file
$ git show

#To show the log of the commit or a file, stat is to see the changes at a bytes level
$ git log [–stat]

#To confirm the changes that we have in the staging area
$ git commit -m “Message”

#To see the differences of two files / if we do not pass any flag it will compare the current directory and the staging area
$ git diff [commit file code] [another commit file code]

#To back in the time, if it’s hard will delete everithing made, but if it’s not, will treat the file as a modificated/untracked file
$ git reset [commit code] [–hard]

#To see back in the pass and see the status of a file / for leave the file in the original state just use ‘git checkout master’
$ git checkout [commit code] [file name]

en los proyectos reales, es muy recomendable hacer Pull, antes de hacer un add, un commit y un** push**, ya que así vamos a tener la certeza que nuestro repositorio local, cuenta con todos los cambios y archivos que están en el repositorio remoto actuales. y evitaremos entrar en algún conflicto o error con nuestro repositorio local

la diferencia de freddy a otros maestros de platzi y otras plataformas es que el no anda con tecnicismos y se pone en el lugar de alguien que no conoce del tema, es muy buen maestro.

Mi resumen:

He buscado algunos playgrounds para poder practicar en otros computadores en los cuales no debo instalar nada. El mejor que me he encontrado es este: https://www.katacoda.com/courses/git/playground

<!-- basico -->
git init -> inicia un repositorio
git add $nombreArchivo -> añade un archivo al repositorio local
git add . -> añade todos los cambios al repositorio local
git commit -m “comentario” -> ejecuta un commit
git commit -am “comentario” -> ejecuta un commit y ejecuta el add al mismo tiempo (pero no agrega archivos nuevos, solo cambios a existentes)

<!-- rollback -->
git reset $idDeEstado --hard -> hace un rollback de un estado en repositorio local, elimina todos los commit hechos
git reset $idDeEstado --soft -> hace un rollback de un estado en repositorio local, No elimina los commits, estos quedan guardados en repositorio local
git checkout $idDelEstado --> hace un rollback a un estado

<!-- branch -->
git branch -> muestra todas las ramas
git branch $nombreDeLaNuevaRama -> crea un branch nuevos
git checkout $nombreDeBranch -> Cambia de branch
git merch $nombreDeBranch -> fuciona dos ramas

<!-- comandos para traer data del repositorio remoto -->
git fetch -> descarga un estado del repositorio remoto al repositorio local
git merge -> ejecuta en los archivos de un repositorio local
git pull -> descarga un estado del repositorio remoto al repositorio local y a los archivos (osea combina un fetch y un merge)

<!-- comandos para ver estados -->
git status -> muestra el estado del commit antes de enviarse
git log -> muestra un registro de los commits ejecutados

Me gusta esta metodología, que cada tantas clases del curso hagan un repaso con algunas láminas indicando que es lo próximo que se va a ver y como se supone que se utiliza y que entra dentro de la ruta de aprendizaje. Es un mejora sustancial respecto al curso anterior de Git

Estupenda manera de motivar el aprendizaje Freddy, le agradezco nuevamente por los vídeos.
Por cierto, para aquellos que tienen problemas para borrar los repositorios que ya no usan, acá les comparto un post donde explican como hacerlo para los distintos sistemas operativos.

►https://stackoverflow.com/questions/1213430/how-to-fully-delete-a-git-repository-created-with-init◄

lo divertido que te digan que no sigas hasta que practiques es que cuando de verdad practicas y entiendes te das cuenta porque el te dice “alto no sigas y practica” en el mundo necesitamos mas profesores y profesionales como Freddy y todo platzi.

Venía haciendo el curso con Leonidas y me quedaron conceptos claros. Lo que hago es ver las clases 2 veces:

La primera, la escucho mientras estoy trabajando o haciendo alguna otra labor para familiarizarme con los temas.

La segunda, cuando estoy frente a mi máquina y aplico todo.

Si no se practica, no se aprende.

Flujo de trabajo en GIT:

Carpe diem:
En general la explicación es buena, pero IO, estoy utilizando linux con sus típicas terminales espartanas que ponen bello plateado en tu pecho. Por tanto hay que utilizar comandos para saber la rama y el HEAD, para lo primero están dos comandos, a saber:
git branch
git show-branch
El segundo da un poco más de información. Para saber el HEAD está
git show HEAD
Si, hay que escribirlo con mayúsculas, sino tira un error.
Bueno todo este trámite si te decides a utilizar la terminal a pelo, pero si no quieres esto puedes utilizar editores como vi, que es el que le sale a Freddy cuando no pone texto en los commit, en mi linux me sale el editor nano por defecto, pero realmente el editor más recomendado es NEOVIM con sus míticos plugins. Hay una enorme ventaja en utilizar un editor embebido en la teminal, ya que podrías desarrollar código sin utilizar ningún ambiente de ventanas (como a menudo están configurados los servidores) o utilizar un ambiente de baldosas (un ejemplo es Qtile) relevando tu compu de utilizar muchos recursos. Se puede correr un linux con todos los jugetes de desarrollo en 250 MB de RAM!
Saluti,
Fabricio

Los cursos con Freddy son demasiado interesantes.

Me convenciste, voy a practicar y vuelvo 😛

Gracias por recordarnos que debemos practicar y no sólo ver las clases como locos!

Nadie se había preocupado tanto por mí.

Platzi ❤️

El premio al mejor maestro de Platzi es para: Freddy Vega.

Más profesores como Freddy por favor!

Esta entendible mi resumen?

Comandos para mover archivos entre los estados de Git:

• $ git init - Inicializa un repositorio local.
• $ 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 archivos del estado Staged para devolverlos a su estado anterior. Si los archivos venían de Unstaged, vuelven allí. Y lo mismo se venían de Untracked.
• $ git commit: Nos ayuda a mover archivos de Unstaged a Staged. Esta es una ocasión especial, los archivos han sido guardado o actualizados en el repositorio. Git nos pedirá que dejemos un mensaje para recordar los cambios que hicimos y podemos usar el argumento -m para escribirlo (git commit -m “mensaje”).
• $ git rm: Este comando necesita alguno de los siguientes 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).
• $ git show nos muestra los cambios que han existido sobre un archivo y es muy útil para detectar cuándo se produjeron ciertos cambios, qué se rompió y cómo lo podemos solucionar. Pero podemos ser más detallados.
• $ git reset. Hay dos formas de usar git reset: con el argumento --hard, borrando toda la información que tengamos en el área de staging (y perdiendo todo para siempre). O, un poco más seguro, con el argumento --soft, que mantiene allí los archivos del área de staging para que podamos aplicar nuestros últimos cambios pero desde un commit anterior.
• $ git checkout + ID del commit nos permite viajar en el tiempo. Podemos volver a cualquier versión anterior de un archivo específico o incluso del proyecto entero. Esta también es la forma de crear ramas y movernos entre ellas. PELIGRO

COMANDOS DE GIT UTILIZADOS AL MOMENTO

**$git init
**Inicia un repositorio Git en el directorio actual.

**$git add
**Añade al stage area la nueva modificación.

$git commit -m "un mensaje"
Añade la nueva versión al repositorio.

$git status
Muestra el estado del repositorio para dicha carpeta, especificando qué archivos han recibido modificaciones y cuáles necesitan guardarse.

**$git log **
Muestra el historial de commits realizados a dicho archivo.

**$git show **
Muestra las diferencias entre la versión actual (HEAD) y la versión anterior.

$git diff Index1 Index2
Muestra las diferencias entre la versión del Index1 y la versión del Index2

$git reset ID --hard
TODO vuelve a la versión de dicho ID, borrando el resto. Ahora el HEAD será esa nueva versión.

$git reset ID --soft
Vuelve a la versión de dicho ID pero lo de staging ahí permanece para su próximo commit. En el directorio es donde se vuelve a la versión anterior.

$git reset HEAD
Este es el comando para sacar archivos del área de Staging.

$git diff
Muestra las diferencias entre lo que está en staging y como lo tengo en mi directorio actual.

$git log --stat
Me muestra más información sobre los cambios.

$git checkout ID archivo.txt
Ahora en el directorio actual estaré viendo dicha versión.

$git checkout master archivo.txt
Para volver al archivo más nuevo.

$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 fetch = nos trae al repositorio local peor no lo copia en los archivos
• git merge = mezcla los archivos de tu local al directorio de trabajo.
  -git pull = baja todos los cambios del repositorio, en realidad este es un git fetch con un git merge.

Hice una lista de comandos usando como referencia la el post del amigo Roberto Ocando Morales (publicada más abajo):

# Pequeña lista de comandos Git (usando Markdown 🙃)

En este documento Markdown voy a enumerar algunos comandos de Git.

## Pasos para crear un repositorio de [Git]

![Imagen de git](https://git-scm.com/images/logo@2x.png)

* **git init**
* **git add .** (o git add archivo.txt)
* **git commit m- 'Agregar un mensaje sobre el commit'**
* **git config --list**: muestra la configuración del repositorio.
* **git show archivo.txt**: muestra los cambios de un archivo, y hace una comparación entre los cambios.
* **git diff 'codigo viejo 'codigo reciente'**: hace una camparativa entre esos 2 commits, los cambios entre cada uno.
* **git diff**: es para ver todos los cambios, trae los 'trae los codigo hexadecimales de los cambios'
* **git reset 'codigo hexadecimal' -hard/soft**: para volver a una versión anterior. Con -hard se pierden todos los commits hechos hasta ese punto. Con -soft se mantienen los cambios en el staging, se les pueden volver a hacer commit.
* **git checkout 'codigo hexadecimal' 'archivo.txt'**: trae una version vieja a la versión actual.
* **git checkout master 'archivo.txt'**: trae el master.

*Esta lista la tomé de referencia de los apuntes del amigo Roberto Ocando Morales.*


[Git]:https://git-scm.com/

El comando “git clone” agrega el repositurio remoto a tu area de trabajo.
El comando “git push” agrega los cambios a tu repositorio remoto.
el comando “git fetch” toma cambios del repositorio remoto y lo agrega a tu area de trabajo.
El comando “git merge” toma los cambio y lo combina con tu respositorio remoto.
El comando “git pull” es lo mismo que utilizar el comando fetch y merge al mismo tiempo, ya que agrega y envia al repositorio remoto los cambios realizados.

Para llegar aqui tuve que crear como tres repositorio nuevos xD, para poder hacer como ha dicho Freddy en las clases.

me encanta el intro y el final ajajjaa, nos motivas a no solo ver y ya 😄

Resumen hecho gracias a los aportes de los demás compañeros. 😃
Si alguien desea agregar algo, por favor déjenme su comentario.

Me pasé dos días practicando con Git y me siento como Doctor Stange con el ojo de agamoto

Comparto mi diagrama de esta clase. Las lineas verdes representan el trabajo de manera local y las azules de manera remota.
Perdón por el git add con la “G” que se me fue ahí. 😅

Practica, Practica, Practica, Practica y Practica.

Un resumen gráfico enfocado sólo en algunos de los tópicos más importantes y algo confusos. El resto no son tan complicados si logramos visualizar este orden.

Freddy tiene una gran tecnica de enseñansa. Sabe como mantenerte enganchado y a su vez utiliza comparaciones para hacer las explicaciones que hacen el aprendizaje más facil.

He practicado asi que me siento preparado para seguir si no cualquier cosa vuelvo para atras nuevamente 😃

![](

Muy buena explicación. A mí siempre me sirven los dibujos, los conceptos me entran mejor. Y sí, ya venía pausando y practicando lo que se iba haciendo, así que a seguir nomás.

Mis Apuntes:
**git init: **iniciar una carpeta como repo

**git add “nombre del Archivo”/ git add . ** : agregar archivos que se encuentran en el repositorio, pero no se estan trackeando. (Sin este comando git no va a trackear el archivo. Una vez que se aplica este comando los archivos entran a un estado denominado “staging”.

git rm –cached “nombre del archivo: Mueve el archivos al estado sin trackear.

git commit -m “mensaje del commit para saber de que se trata el comit”: con este comando se agregan los cambios a la rama master.

git log: muestra el historial de cambios del repositorio

git config --list: muestra la información de configuración del repo

git config --global user.name “nombre de la persona”: configura el repo local para que se sepa quien hace los cambios.

git config --global user.email “email”: configura el email del usuario

git show “nombre del archivo”: mira los cambios de un archivo entre lo que se modifica y lo que se incluye

git diff “codigo hexa decimal del commit mas viejo” “codigo hexadecimal mas reciente” Compara commit.

git diff: puede ver los cambios

git reset “codigo del commit al que queremos volver” –hard/–soft: sirve para volver a una version de commit que teniamos anterior.

git log –stat: visualizar la información de los cambios de manera especifica.

git checkout “codigo hexa del commit 1” “ nombre del archivo”: trae lo Viejo a la version actual

git checkout master “nombre del archivo”: trae el master.

Les comparto lo que llevamos, creo que no se me ha olvidado ningún comando.
una vez veamos lo del repositorio remoto la idea es subir el archivo y tenerlo como archivo de consulta…

Ubicado dentro de un folder, se inicia el directorio de trabajo
git init

Ver el estado del folder
git status

Agregar un archivo al staging
git add PrimerArchivo.txt

Remover un archivo del staging
git rm PrimerArchivo.txt

Removerlo completamente del staging
git rm --cached PrimerArchivo.txt

Removerlo completamente del staging y el disco
git rm --force PrimerArchivo.txt

Enviarlo al master
git commit -m "Primer commit del archivo"

Ver la configuración de git
git config
git config --list
git config --list --show-origin

Agregar usuario y email

git config --global user.name "Camilo Ortiz"
git config --global user.email "[email protected]"

Ver cambios o historia de un archivo
git log PrimerArchivo.txt

Mostrar más información de las modificaciones del archivo 
git show NOMBREARCHIVO

Devolver un archivo a un punto en la historia
- Tener mucho cuidado porque este comando borra todos los cambios adicionales que se hicieron
git reset  -alfanumerico-   --hard o --soft

Permite visualizar los bits por commit
git log --stat

Permite visualizar un archivo con la información de ese momento
se debe tener cuidado de no hacer commit en ese momento,
porque se perderia la información
git checkout -alfanumerico- NOMBREARCHIVO

si quiero volver al archivo
git checkout master NOMBREARCHIVO

La diferencia entre “Git rm --cached y git reset HEAD” es que:

git rm --cached

Elimina el archivo de staigin, es decir le quita el seguimiento, como si nunca le hubieras hecho el “git add”, pero te deja el archivo como esta en la carpeta.
Te pongo un ejemplo:
yo tengo un archivo “prueba.php” que acabo de crear, y index.php que ya llevo usando y le hecho add y commit. Si le hago un “git status” me diría esto:

git status

Changes not staged for commit:
  (use"git add <file>..."toupdate what will be committed)
  (use"git checkout -- <file>..."to discard changes in working directory)

        modified:   index.php

Untracked files:
  (use"git add <file>..."toincludein what will be committed)

        prueba.php

Para indes.php me dice:
“Changes not staged for commit:” Esto te dice que: hay cambio pero no han sido preparados para realizar un commit, y te da las opciones de prepararlos con “add” o descartarlos con “checkout”

En cambio para prueba.php, me dice:
“Untracked files” Quiere decir que no lo esta siguiendo para ver los cambio, es decir el archivo esta ahí, se que es nuevo pero no hago nada.

y si le hago un "git rm --cached index.php este sria el resultado:

git rm --cached index.php
rm 'index.php'

Oscar Yaniuk@CTYA MINGW64 ~/admin (admin)
$ git status
On branch admin
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        deleted:    index.php

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        index.php
        prueba.php

Ves en el código te muestra que paso de estar en seguimiento a decir que existe pero que no hace nada, es decir lo quito del (indice, seguimiento, staigin) como te sea mas fácil, el asunto es que no sigue sus cambios.

En cambio “git reset HEAD index.php” lo que hace es quitarlo del estado de preparado, es decir cuando hace un “git add index.php” se queda en verde (preparado para el commit), esta comando lo deja en el estado anterior al “git add” es decir, se le esta haciendo el seguimiento esta modificado pero no preparado para el commit…

Espero que se haya entendido. y que te sirva.

Saludos.

📌 git fetch permite obtener los metadatos del repositorio remoto u original y comprueba con tu repositorio local y te muestra si en el repositorio original existen cambios.

Ojala Freddy diera todas las clases8)

No me saque la lengua Freddy, no le hice nada, no sea grosero. 😦

Pensé que odiaba ** GIT** pero era porque no lo entendía. Freddy vuelve algo complicado a algo sencillo. 😃

Yo pongo la clase ocupando solo media pantalla (tecla de windows + flecha) y en la otra mitad visual studio code, git o lo que sea.

Clase 14. Flujo de trabajo básico con un repositorio remoto

• git clone url_del_servidor_remoto: Nos permite descargar los archivos de la última versión de la rama principal y todo el historial de cambios en la carpeta .git.
• git push: Luego de hacer git add y git commit debemos ejecutar este comando para mandar los cambios al servidor remoto.
• git fetch: Lo usamos para traer actualizaciones del servidor remoto y guardarlas en nuestro repositorio local (en caso de que hayan, por supuesto).
• git merge: También usamos el comando git fetch con servidores remotos. Lo necesitamos para combinar los últimos cambios del servidor remoto y nuestro directorio de trabajo.
• git pull: Básicamente, git fetch y git merge al mismo tiempo.

Desde https://platzi.com/clases/1557-git-github/19935-flujo-de-trabajo-basico-con-un-repositorio-remoto/

RETOMANDO LAS CLASES ANTERIORES

• Git init: Cuando ejecutamos el comando git init creamos tres capas de trabajo:
	○ Directorio de trabajo (Disco duro).
	○ Preparación o Staging (Espacio en memoria).
	○ Repositorio Local.
	
• Git add: Cuando se ejecuta este comando se le hace un rastreo al archivo enviándolo al Staging. (Temporal).
• Git commit: Cuando se ejecuta este comando, se envía todo lo que está en Staging (Memoria temporal) al repositorio local para ser guardado y no perder nada.

TRABAJAR EN EQUIPO

Cuando se trabaja en equipo se tiene otro repositorio pero esta vez es un repositorio REMOTO alojado en un servidor REMOTO.

Ejemplo: GitHub - GitLab - BitBucket

Para traer los datos de un repositorio remoto se ejecuta el comando:
• Git clone (url) : Este comando se trae los archivos a dos lugares -> Trae una copia del Master al directorio de trabajo (Disco duro). Y crea la base de datos de todos los cambios históricos en el repositorio local y deja el Staging quieto.

El flujo de trabajo sigue siendo el mismo (git add - git commit) para enviar al repositorio local, pero para enviar los cambios al repositorio remoto se debe usar el comando git push.

Para traer una actualización de un archivo del repositorio remoto al local (Porque alguien realizó un cambio), se debe usar el comando git fetch.

git fetch: Me trae la actualización del archivo pero solo al repositorio local y no a mis archivos del directorio de trabajo (Disco duro), para que se copie en mis archivos se tiene que fusionar la ultima versión del repositorio local con la versión actual y para eso se usa el comando git merge.

git merge: Lo que hace básicamente es copiar la actualización bajada del repositorio remoto a mi directorio local (Disco duro) para poder trabajar sobre ellos.

Pero existe otro comando que evita tener que usar git fetch y git merge al mismo tiempo, este comando se llamada git pull.

git pull: Este comando hace las dos funciones a la vez, copia la base de datos de cambios al repositorio local y copia el directorio en el disco duro.

Hola. Aquí dejo este diagrama que me pareció interesante. Le hice captura a la pantalla de un vídeo de YouTube que hizo Freddy en 2018: “10 errores comunes de programadores junior | PlatziLive”. El enlace es: https://youtu.be/YJ0u-MpYpM4. Espero le sirva a alguien. Saludos.

Excelente! qué explicación tan al detalle, amo las clases de Freddy! nos dice que practiquemos y así mismo le agarramos cariño a lo que hacemos porque afianzamos las bases. Ya había visto estos conceptos en otras clases pero ahora sí me queda super claro!!

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' 
  

Ligero resumen de los comandos que hemos visto hasta ahora. Si he olvidado alguna comenta👇

Comparto mis apuntes de la clase 😄

Si eliminaste un archivo con git rm <nombre_del_archivo>

Puedes Volver atras con

git restore --staged <nombre_del_archivo>
git restore <nombre_del_archivo>

Espero que le sirva a alguien 😄

Compartiré mi forma de aprender, la cual al menos a mi me resulta a la perfeccion y solo tengo que ver 1 vez el video.

Una vez que pasamos a otro video nuevo o “clase”.

1. Leo la descripcion del video y/o apuntes que deja el profesor.
2. Leo los comentarios… ya que muchos siempre dejan apuntes o links importantes.
   3)Apunto todo esto en dos archivos a uno le llamo “Repaso_Rapido.txt” en donde apunto un resumen de todo y al otro Importante.word/pdf, en donde apunto cosas a mas fondo.
   #Al ya saber mas o menos de lo que trata la clase, me es mas facil entender el video#
   4)Reproduzco el video y hago todo lo que hace el profesor, en el caso que se me ocurra algun experimento, lo hago por mi cuenta mientras pauso el video, ademas, si hay alguna cosa relevante que el profesor diga y no se habia mencionado antes en los comentarios o la descripcion lo apunto en los archivos que mantengo abiertos dependiendo de la importancia que tenga dicha mencion.

Bien eso es basicamente lo que hago yo y me ayuda a comprender todo lo que pasa en la clase.

Ojalá alguien que no haya definido aun su metodo de aprendizaje le sirva.

Cabe recordar que no reproduzco el video hasta el paso 4).

Es la 4ta vez que llego hasta aquí, casi siempre me rindo y dejo los cursos, pero por alguna razón pago platzi el siguiente mes y lo vuelvo a comenzar, eso se acabo, quiero continuar y terminar todo lo que venga, se que no tiene nada que ver pero así espero recordarme x q tengo que continuar.

Tengo la costumbre de pausar los videos para hacer todo lo que hacen los maestros, es una buena práctica. Usando mis propias variables y textos.

Aunque no está muy relacionado con el tema en especifico, como dicen en Platzi “Nunca pares de aprender”: Dejando el cursor encima de la zona del vídeo se puede subir o bajar el volumen mediante el scroll del mouse (en caso de los que tengan la ruedita del medio del mouse). Hasta por accidente aprendemos ja ja !

Ahí les va una breve historia de cómo cagué una cosa y luego la arreglé en el video anterior:

Le dí:

git checkout id

Sí, así a lo salvaje sin ponerle el nombre del archivo y noté que me cambió al branch de ese commit y los cambios no iban al branch master, entonces dije bueno y cómo salgo de acá?

Pues así:

git checkout master

Resulta que todos los cambios hechos en ese checkout no afectan pero estás cambiando lo que sucedió en ESE LOG al que le estás cambiando cosas y le puedes hacer el commit de toda la vida y cambiarlo y estaba que brincaba del gusto porque no sabía qué estaba haciendo hasta que sí supe y entonces comprendí que amo git

Después de la indicación, me puse a practicar con nuevos ejemplo y de verdad que ayudar a entender mejor los comandos (sobretodo los reset)

Aquí les va mi resumen por si a alguien le sirve:

ls: ver archivos en la carpeta
ls -al: ver archivos (incluido los ocultos)

git status: estados de los archivos en la carpeta. En “staging” o “not staged”

git add .: Agregas todos los archivos modificados al staging
git rm --catched nombreArchivo.extensión: Borras el archivo del staging pero no de tu carpeta
git commit -m “comentarioEntreComillas”: Guardas los cambios del staging al repositorio git

git config --list: Ves configuración por defecto de tu git
git config --global user.name “tuNombre”: Agregas tu nombre para que aparezca en el log. Lo mismo se puede hacer para email

git log nombreArchivo.extension: Ver todos los commits de un archivo

git show nombreArchivo.extension: Muestra los últimos cambios de un archivo
git dif codigo1DelCommit codigo2DelCommit: Muestra los cambios entre 2 archivos

git reset codigoXDelCommit --hard: regresa en el tiempo hasta el commit señalado (modifica el git y borra todos los demás archivos de la carpeta (Cuidado con este, borró mi html y la carpeta css)
git reset codigoXDelCommit --soft: regresa en el tiempo hasta el commit señala (modifica el git pero no modifica ni borra ningún archivo en la carpeta)
git reset HEAD: lo que estaba en staging, pasa a not staged

Hace 20 minutos quería dar play pero escuche a Freddy y me ha hecho razonar.
Ya le estoy cogiendo el ritmo a Git 😄
Continuemos …

entonces me regreso a practicar más :V

Ya repetí varias clases y he estado leyendo el libro de Git Pro y me siento listo para continuar.

Que buen consejo!

No hay nada mejor y simple para apoderarse del conocimiento que tomando notas a mano, recomiendo mucho las notas de Cornell

print("EXCELENTE COMO EXPLICA ");

Yo voy viendo los vídeos y tomando apuntes los voy leyendo y me queda todo mas claro, ademas voy haciendo los pasos al tiempo que Freddy cuando termino un vídeo vuelvo a leer los apuntes y practico un poco y me quedan los cosas claras.

Por clases como esta Freddy es mi profesor favorito en Platzi!!!

Súper bien explicado hasta el momento.
Seguiré pausando y regresando los vídeos las veces que sea necesario para ir entendiendo los conceptos e ir a la par en los ejercicios!

En nuestro entorno de desarrollo personal el flujo de trabajo era:
-git init
-git add
-git commit
Si trabajamos con otros desarrolladores necesitaremos un repositorio remoto, por tanto el flujo de trabajo cambia:
-git clone url (nos traemos una copia del master al directorio de trabajo y el repositorio local)
Luego el flujo continua muy parecido al anterior
-git add
-git commit
-git push (envíamos la ultima versión de los commits al repositorio remoto)
Si ya estamos conectados al remositorio remoto y queremos traer una actualización entonces usamos
-git fetch
Ojo: solo lo trae al repositorio local, no lo copia en los archivos, para que se copien en los archivos se usa
-git merge
Sin embargo, podemos usar
-git pull
Este comando combina los dos conceptos anteriores.

# Configuración global de Git
git config --global user.name "nombre" # Establece el nombre del usuario
git config --global user.email "email" # Establece el correo electrónico del usuario

# Inicializar un repositorio Git
git init # Inicializa un repositorio Git vacío

# Clonar un repositorio remoto
git clone url_repositorio # Clona un repositorio remoto

# Verificar el estado del repositorio
git status # Muestra el estado de los archivos en el repositorio

# Añadir archivos al área de preparación (staging)
git add archivo # Añade un archivo al área de preparación
git add . # Añade todos los archivos al área de preparación

# Hacer un commit
git commit -m "mensaje del commit" # Guarda los cambios en el repositorio con un mensaje

# Ver el historial de commits
git log # Muestra el historial de commits

# Cambiar a una rama o commit específico
git checkout nombre_rama_o_commit # Cambia a una rama o commit específico

# Crear una nueva rama
git branch nombre_rama # Crea una nueva rama

# Fusionar ramas
git merge nombre_rama # Fusiona una rama con la rama actual

# Eliminar una rama
git branch -d nombre_rama # Elimina una rama

# Actualizar el repositorio local con cambios remotos
git pull # Trae los cambios del repositorio remoto y los fusiona con la rama actual

# Enviar cambios al repositorio remoto
git push # Empuja los cambios al repositorio remoto

# Ver las diferencias entre el área de preparación y el último commit
git diff # Muestra las diferencias entre el área de preparación y el último commit

# Revertir un commit
git revert commit_id # Revierte un commit específico

# Reajustar el área de preparación al último commit
git reset # Reajusta el área de preparación al último commit

# Ignorar archivos o carpetas
.gitignore # Archivo para especificar archivos o carpetas a ignorar por Git

Me senti un poco identificado y me di un break de un dia para estar practicando jajaja

• https://learngitbranching.js.org/
  Comparto este juego te ayuda a entender un poco mas los conceptos y a practicar, es de gran ayuda !

Encontré este tutorial para reforzar conocimientos

¿Entonces cual es la diferencia clone y pull?
Ambos traen los archivos a nuestro repo local y al directorio de trabajo.
¿O es que se utiliza en situaciones diferentes por contexto?

He vuelto despues de repasar todos lo videos anteriores, saludos

cuenta si los practique mientras los veiamos?

Usando el comando

git merge 

Fusiono mi versión de código en el repositorio local con la de mi compañero de equipo en el directorio de trabajo activo para crear la versión master final.

Estoy haciendo la escuela de Desarrollo Web, ya vi este curso y recién terminé el curso práctico de Frontend Developer (está 3 cursos más adelante). Lo que quiero comentar es que con los archivos de los ejercicios prácticos de Frontend Developer volví acá para aplicar todo lo de git y github, y definitivamente practicando es que se entiende y se aprende mejor 🚀. Así que los invito a seguir la recomendación de Freddy 😎.