Introducción a Git

1

¿Por qué usar un sistema de control de versiones como Git?

2

¿Qué es Git?

3

Instalando Git y GitBash en Windows

4

Instalando Git en OSX

5

Instalando Git en Linux

6

Editores de código, archivos binarios y de texto plano

7

Introducción a la terminal y línea de comandos

Comandos básicos en Git

8

Crea un repositorio de Git y haz tu primer commit

9

Analizar cambios en los archivos de tu proyecto con Git

10

¿Qué es el staging y los repositorios? Ciclo básico de trabajo en Git

11

¿Qué es branch (rama) y cómo funciona un Merge en Git?

12

Volver en el tiempo en nuestro repositorio utilizando reset y checkout

13

Git reset vs. Git rm

Flujo de trabajo básico en Git

14

Flujo de trabajo básico con un repositorio remoto

15

Introducción a las ramas o branches de Git

16

Fusión de ramas con Git merge

17

Resolución de conflictos al hacer un merge

Trabajando con repositorios remotos en GitHub

18

Cambios en GitHub: de master a main

19

Uso de GitHub

20

Cómo funcionan las llaves públicas y privadas

21

Configura tus llaves SSH en local

22

Conexión a GitHub con SSH

23

Tags y versiones en Git y GitHub

24

Manejo de ramas en GitHub

25

Configurar múltiples colaboradores en un repositorio de GitHub

Flujos de trabajo profesionales

26

Flujo de trabajo profesional: Haciendo merge de ramas de desarrollo a master

27

Flujo de trabajo profesional con Pull requests

28

Utilizando Pull Requests en GitHub

29

Creando un Fork, contribuyendo a un repositorio

30

Haciendo deployment a un servidor

31

Hazme un pull request

32

Ignorar archivos en el repositorio con .gitignore

33

Readme.md es una excelente práctica

34

Tu sitio web público con GitHub Pages

Multiples entornos de trabajo en Git

35

Git Rebase: reorganizando el trabajo realizado

36

Git Stash: Guardar cambios en memoria y recuperarlos después

37

Git Clean: limpiar tu proyecto de archivos no deseados

38

Git cherry-pick: traer commits viejos al head de un branch

Comandos de Git para casos de emergencia

39

Git Reset y Reflog: úsese en caso de emergencia

40

Reconstruir commits en Git con amend

41

Buscar en archivos y commits de Git con Grep y log

Bonus sobre Git y Github

42

Comandos y recursos colaborativos en Git y GitHub

43

Tu futuro con Git y GitHub

No tienes acceso a esta clase

¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera

Flujo de trabajo básico con un repositorio remoto

14/43
Recursos

Cuando empiezas a trabajar en un entorno local, el proyecto vive únicamente en tu computadora. Esto significa que no hay forma de que otros miembros del equipo trabajen en él.

Para solucionar esto, utilizamos los servidores remotos: un nuevo estado que deben seguir nuestros archivos para conectarse y trabajar con equipos de cualquier parte del mundo.

Estos servidores remotos pueden estar alojados en GitHub, GitLab, BitBucket, entre otros. Lo que van a hacer es guardar el mismo repositorio que tienes en tu computadora y darnos una URL con la que todos podremos acceder a los archivos del proyecto. Así, el equipo podrá descargarlos, hacer cambios y volverlos a enviar al servidor remoto para que otras personas vean los cambios, comparen sus versiones y creen nuevas propuestas para el proyecto.

Esto significa que debes aprender algunos nuevos comandos

Comandos para trabajo remoto con GIT

  • 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 merge 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.

Adicionalmente, tenemos otros comandos que nos sirven para trabajar en proyectos muy grandes:

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

Aporte creado por: HellenBar

Aportes 753

Preguntas 105

Ordenar por:

Los aportes, preguntas y respuestas son vitales para aprender en comunidad. Regístrate o inicia sesión para participar.

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

Hay un concepto que a lo largo del curso esta mal. “El staging area esta en memoria”, y eso es absolutamente incorrecto. El staging area esta en el disco. Es persistente. Podes apagar o resetear la computadora, dejarla prendida 1000 años y no se va a borrar ya que esta en el disco, es persistente.
https://git-scm.com/book/en/v1/Getting-Started-Git-Basics
"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."

Espero que a alguien le ayude.

¡Espero te guste! ❤️


@sebas.nop

Freddy debería dar más cursos!!

Un ligero resumen con dibujos de esta parte :3
link

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.

Hola, les dejo mis apuntes de la clase.

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

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.

Aquí dejo un mapa conceptual que hice:

Me recuerda cuando un profesor me dijo " la practica no es lo que uno hace cuando se es bueno, es lo que uno hace para volverse bueno"

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

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!!

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.

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

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

LOL ya me voy a practicar, regreso pronto.

Apuntes

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]

Mi resumen:

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.

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

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

<!-- 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

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◄

Los cursos con Freddy son demasiado interesantes.

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.

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

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.

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.

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 😄





Practica, Practica, Practica, Practica y Practica.

Me convenciste, voy a practicar y vuelvo 😛

Esta entendible mi resumen?

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

Nadie se había preocupado tanto por mí.

Platzi ❤️

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í. 😅

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.

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.

<h1>Curso de Git en Platzi</h1>

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

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 [email protected] 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)

Más profesores como Freddy por favor!

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

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👇

Flujo de trabajo en GIT:

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

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

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

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!!!

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.

Bueno señor. Me devuelvo. Bai.

si uno no sabe utlizar bien los comandos anteriores hay conflictos al intentar utlizar git pull,me ha pasado.

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

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

Les recomiendo mucho a medida que van avanzando por el curso de Freddy, checar también está página, la cual te enseña de una manera muy visual como funcionan los comandos en Git 😃
https://learngitbranching.js.org

Sentí como si Freddy literalmente me dijera:

Deja de darle play a todo y practica!
😅😅😅

En mi trabajo utilizamos bitbucket como repositorio y yo hacía las cosas automaticamente porque así me las habian enseñado ahi pero en realidad no entendía por qué. Ahora siento que se me iluminó la vida!!

Comparto mis apuntes de la clase 😄

Estoy confundido, ya vi dos veces los videos previos y no me queda claro. Empecé a ver estos videos de Git en el canal de youtube “makigas: tutoriales de programación”. Veré si me ayuda a dominar estos conceptos de Git.

https://www.youtube.com/watch?v=9AkcsMpKYhI&ab_channel=makigas%3Atutorialesdeprogramación

¿Qué diferencia hay entre git clone y git pull? ¿por cada vez que haga un git clone creo un nuevo directorio de trabajo y un nuevo repositorio local? y ¿con git pull se actualiza? Me da la impresión que ocurre eso, pero igual tengo la duda.

¿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?

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!

Una vez que ya entre a un checkout, para regresar al master era tan sencillo como

git checkout master

Ayer sábado 13 de marzo estaba muy confundido con lo visto de Git, me puse a buscar información, encontré un canal en youtube que tal vez te pueda servir. Y no es que este curso sea malo o insuficiente, pero no lo había entendido del todo bien.

El canal en youtube es “makigas: tutoriales de programación”. Los videos correspondientes hasta este punto es del 1 al 7.

https://www.youtube.com/watch?v=rmO7t35l1XI&ab_channel=makigas%3Atutorialesdeprogramación

Ahora sí, sigamos con platzi.

pues yo no tenia de git y hasta ahora no se ha roto nada eso no se si es bueno o malo

cuenta si los practique mientras los veiamos?

Que GRANDE Estel esta clase, resolvió algunas dudas que tenia, increibleeee! (Me he enamorado de git)