Fundamentos de Git y control de versiones

1

¿Qué son Git y GitHub?

2

Configuración Inicial de Git: init y config

3

Comandos Básicos de Git: add, commit y log

4

Ramas y Fusión de Cambios: branch, merge, switch y checkout

5

Volviendo en el Tiempo en Git: reset y revert

6

Gestión de versiones: tag y checkout

7

Cómo Resolver Conflictos de Ramas en Git

8

Usando Git desde Visual Studio Code

Quiz: Fundamentos de Git y control de versiones

Introducción a GitHub

9

Por qué GitHub es clave para los Desarrolladores

10

Creación y configuración de cuenta de GitHub

11

¿Cómo integrar Git y GitHub en un flujo de trabajo profesional?

12

Gestión de Repositorios en GitHub

13

Productos de GitHub: precios, planes y apps

14

Cómo configurar SSH para GitHub: Guía paso a paso

15

Clone, fork y estrellas a repositorios

16

Trabajo con repositorios remotos: push, pull y fetch

17

Gestión de Issues y Discussions en GitHub

18

Colaboración sin errores: Pull Requests en GitHub

Quiz: Introducción a GitHub

Herramientas de colaboración en GitHub

19

Introducción a GitHub Projects

20

Automatización y Gestión de Proyectos en GitHub

21

Documentación en GitHub con Markdown

22

Personaliza tu Perfil de GitHub con Markdown

23

Uso de Wikis

24

Cómo usar GitHub Gist

25

Cómo usar GitHub Pages

Quiz: Herramientas de colaboración en GitHub

GitHub Codespaces

26

Cómo usar GitHub Codespaces: Configuración y Desarrollo en la Nube

27

Cómo configurar entornos de desarrollo avanzados en GitHub Codespaces

28

Pair Programming con Codespaces y Visual Studio Code

29

Cómo usar GitHub.dev Editor

Quiz: GitHub Codespaces

Seguridad y buenas prácticas en GitHub

30

Cómo Usar Tokens en GitHub para Acceso Seguro a Repositorios Privados

31

Gestión de Dependencias y Seguridad con Dependabot en GitHub

32

Mantenimiento de repositorios seguros

33

Gestión de datos sensibles y políticas de seguridad

Quiz: Seguridad y buenas prácticas en GitHub

Administración de GitHub

34

Administración de organizaciones en GitHub

35

Cómo personalizar tu perfil de GitHub con GitHub Actions

36

GitHub CLI para administración

Quiz: Administración de GitHub

Gestión de Cambios con Pull Requests

37

Importancia de los Pull Requests y Ramas en GitHub

38

Revisión y Fusión de Pull Requests

39

Git Rebase

Quiz: Gestión de Cambios con Pull Requests

GitHub Releases

40

Introducción a los GitHub Releases

41

Publicación de paquetes en GitHub y PyPI

Quiz: GitHub Releases

Cierre

42

ProTips: Mejora tu productividad diaria en GitHub

No tienes acceso a esta clase

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

Comandos Básicos de Git: add, commit y log

3/42
Recursos

Aprender a utilizar Git desde los primeros pasos puede parecer desafiante, pero es esencial para registrar cambios y manejar versiones de cualquier proyecto. Siguiendo un flujo de trabajo sencillo y utilizando los comandos adecuados, puedes dominar el control de versiones y llevar un seguimiento preciso de tus archivos.

¿Cómo inicia el control de versiones con Git?

El primer paso es iniciar un repositorio con el comando git init, que crea una carpeta oculta llamada .git en el directorio de trabajo. Esta carpeta actúa como una bitácora, almacenando cada cambio y movimiento de los archivos que se manejan en el proyecto.

¿Cómo se crean y agregan archivos a Git?

Para crear un archivo desde la terminal, utiliza un editor como nano. Una vez creado, puedes verificar su existencia y estado con git status, que te mostrará el archivo como no registrado. Para incluirlo en el área de staging, donde estará listo para el commit, usa git add nombre_del_archivo.txt. Esta área de staging es un “limbo” donde decides qué archivos entrarán en el control de versiones.

  • Ejemplo de comandos:
    • nano testing.txt para crear el archivo.
    • git add testing.txt para agregarlo al área de staging.

¿Qué es el área de staging y cómo funciona?

El área de staging permite revisar los cambios antes de que se registren oficialmente en el repositorio. Los archivos en staging aún no forman parte del historial de versiones; están en espera de que se realice un commit o de ser devueltos a su estado original con git rm --cached nombre_del_archivo.txt.

¿Cómo realizar el commit de los archivos en Git?

Una vez en staging, se ejecuta git commit -m "mensaje descriptivo" para registrar los cambios en el repositorio. El mensaje en el commit es crucial porque indica la acción realizada, como “nuevo archivo de testing”. Este mensaje permite identificar los cambios de forma clara y ordenada en el historial del proyecto.

  • Ejemplo de commit:
    • git commit -m "nuevo archivo de testing"

¿Cómo gestionar múltiples archivos en Git?

Para trabajar con varios archivos a la vez, utiliza git add . que agrega todos los archivos sin registrar en el área de staging. Puedes decidir entre realizar commits individuales o múltiples en función de la cantidad de archivos y los cambios realizados en cada uno.

¿Cómo visualizar el historial de cambios en Git?

El comando git log muestra el historial de commits, proporcionando una vista completa de cada cambio realizado en el proyecto. Esta bitácora permite ver el estado de cada archivo y la información de cada commit.

¿Qué sucede al modificar un archivo en Git?

Cuando un archivo se edita, Git lo detecta como “modificado”. El flujo de trabajo para registrar este cambio es el mismo que para un archivo nuevo: git add para llevarlo a staging y git commit para guardar la modificación. Esto asegura que Git mantenga un registro detallado de cada cambio, actualización o eliminación en el proyecto.

¿Cómo maneja Git diferentes tipos de archivos?

Git trata cualquier archivo de igual manera, sin importar su extensión o tipo, ya sea de texto, código o imagen. Con git add y git commit, cualquier cambio en estos archivos se registra, facilitando el control de versiones sin importar el tipo de contenido.

Aportes 39

Preguntas 3

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad?

Terminos basicos * cd → cambiar directorio y/o regresar al directorio raiz * cd .. → retroceder 1 carpeta dentro del directorio * mkdir → crear directorio * rmdir → remover directorio * ls → contenido de un directorio * .. → volver 1 carpeta atrás * mkdir repo → crear repo * rmdir repo → eliminar repo * git init → iniciar repositorio * git add → añadir archivos * git status → estado del repo * git rm —cached → eliminar archivo añadido al repositorio * git commit → subir todo al repositorio
me quedo con esta imagen de la clase ![](https://static.platzi.com/media/user_upload/image-fc0def57-f39f-40db-8431-3e238242b51f.jpg)
Excelentes diagramas para explicar el ciclo de staging a git
Y yo que pensaba que cuando agregabas un archivo con 'git add', no los podías quitar, sino que sí o sí debían ir a 'git commit'. He aprendido mucho hoy
los invito a ver esta respuesta que generó ChatGPT sobre cómo Git asigna los IDs a los commits: Git asigna los **IDs** a los commits utilizando un **hash SHA-1** (Secure Hash Algorithm 1). Este ID es una cadena de 40 caracteres que actúa como identificador único para cada commit. El proceso funciona de la siguiente manera: ### 1. **Cálculo del hash** Git utiliza SHA-1 para generar el ID basándose en el contenido del commit. Esto incluye: * **Metadatos del commit**: * Nombre y correo del autor. * Fecha y hora del commit. * Mensaje del commit. * **Referencia al padre del commit** (si no es un commit inicial). * **Hash del árbol** (que representa el estado del repositorio en ese momento). El comando interno que ejecuta Git toma todos estos datos, los serializa en un formato específico y calcula el hash SHA-1. ### 2. **Formato del hash** El hash SHA-1 es una cadena hexadecimal de 40 caracteres. Por ejemplo: `4b825dc642cb6eb9a060e54bf8d69288fbee4904` ### 3. **Propiedades del ID** * **Único**: Gracias a SHA-1, cada commit tiene un identificador único basado en su contenido. Si el contenido de dos commits es diferente en cualquier aspecto (incluido el autor o la fecha), sus hashes serán diferentes. * **Inmutable**: Una vez creado, el ID no puede cambiar porque depende directamente del contenido del commit. ### 4. **Ventajas del uso de SHA-1** * **Integridad**: El hash garantiza que cualquier cambio en el contenido del commit resultará en un ID diferente, lo que ayuda a detectar alteraciones no autorizadas. * **Compatibilidad**: SHA-1 es ampliamente utilizado y eficiente para calcular y verificar hashes. ### Ejemplo del flujo Supongamos que haces un commit con el siguiente contenido: * Autor: Alice * Fecha: 2024-12-06 * Mensaje: "Inicializar el repositorio." * Cambios: Un archivo `README.md` con el texto "Hola mundo." Git combina esta información, calcula el SHA-1 y genera un ID único como: `9fceb02c9b50f0b2935f90f98bc9c3efb5c9a552` Cada vez que creas un nuevo commit, el ID será recalculado en función del nuevo contenido y la información asociada. **Nota**: Aunque Git usaba SHA-1 originalmente, versiones recientes están adoptando **SHA-256** para una mayor seguridad, debido a posibles vulnerabilidades en SHA-1.
hola! yo uso normalmente <git add -p> qué me enlista todos los cambios, y voy aceptandolos uno a uno. esto me ayuda bastante para hacer un doble check y no se me pase algún log o comentario que no deba commitear
<question> Para evitar problemas con los finales de línea en Git, puedes configurar la conversión utilizando el comando: ```bash git config --global core.autocrlf true ``` Esto hará que Git convierta automáticamente LF a CRLF al clonar y commit en Windows. Para sistemas Unix, usa `false` para que no haya conversión. </question>
![](https://static.platzi.com/media/user_upload/GIT-45c05d0d-7044-4119-861b-1e415d89da39.jpg)
## **Comandos Básicos de Git:** `add`**,** `commit` **y** `log` Una vez que tienes Git configurado e inicializado, puedes comenzar a gestionar cambios en tu código. Tres de los comandos más importantes son `git add`, `git commit` y `git log`. ## **1. Agregar Archivos al Área de Preparación:** `git add` Antes de confirmar los cambios en el historial de Git, debes agregarlos al **staging area** (área de preparación). ### **Sintaxis:** git add \<archivo> # Agrega un archivo específico git add . # Agrega todos los archivos modificados git add \*.txt # Agrega solo archivos con cierta extensión 🔹 **Ejemplo:** Si creas un archivo `index.html` y lo modificas, puedes agregarlo al área de preparación con: git add index.html Esto indica a Git que este archivo será parte del próximo commit. ## **2. Confirmar Cambios:** `git commit` El comando `git commit` guarda una **instantánea permanente** de los archivos en el historial de versiones. ### **Sintaxis:** git commit -m "Mensaje descriptivo" 🔹 **Ejemplo:** git commit -m "Agregada la estructura inicial del proyecto" Después de este comando, los cambios se guardan en el historial de Git, pero aún no se han enviado a un repositorio remoto. **Opción avanzada:** Si quieres escribir un mensaje más detallado en varias líneas, usa: git commit Esto abrirá el editor de texto configurado (como `nano` o `vim`), donde puedes escribir una descripción más extensa del commit. ## **3. Ver el Historial de Commits:** `git log` Para ver el historial de confirmaciones en el repositorio, usa `git log`. ### **Sintaxis básica:** git log 🔹 **Ejemplo de salida:** commit 1a2b3c4d5e6f7g8h9i (HEAD -> main) Author: Mario Alexander Vargas Celis \<[email protected]> Date: Wed Jan 30 12:00:00 2025 -0500 Agregada la estructura inicial del proyecto ### **Opciones útiles:** * **Mostrar commits en una línea resumida:**git log --oneline 🔹 **Ejemplo de salida:**1a2b3c4 Agregada la estructura inicial del proyecto * **Ver cambios en cada commit:**git log -p * **Filtrar por autor:**git log --author="Mario" * **Ver commits de los últimos 7 días:**git log --since="7 days ago" ## **Flujo de Trabajo Básico con Git** 1️⃣ **Crear o modificar archivos:** echo "Hola Mundo" > archivo.txt 2️⃣ **Agregar cambios al área de preparación:** git add archivo.txt 3️⃣ **Confirmar los cambios con un mensaje:** git commit -m "Primer archivo agregado" 4️⃣ **Ver el historial de commits:** git log --oneline
cuando pongo "ls -a" y "nano" sale un error y no me deja continuat
Ambos comandos manejan el área de staging en Git, pero tienen propósitos diferentes: - `git restore --staged archivo.txt`: devuelve el archivo al estado anterior en el área de staging sin eliminarlo del directorio de trabajo. - `git rm --cached archivo.txt`: elimina el archivo del área de staging y lo mantiene en el directorio de trabajo, pero lo marca para ser eliminado en el próximo commit. Estas diferencias son clave para gestionar tus cambios de manera efectiva en Git.
Muy buenas animaciones hacen que la clase sea bastante interactiva
El comando para remover un archivo del área de staging en Git es: ``` git rm --cached <nombre_del_archivo> ``` Reemplaza `<nombre_del_archivo>` con el nombre del archivo que deseas quitar del staging. Este comando permite que el archivo regrese al estado original sin ser eliminado del disco, manteniendo así su contenido.
Los comandos utilizados en esta clase son: 1. `git init` - Inicializa un repositorio Git. 2. `git status` - Muestra el estado de los archivos en el repositorio. 3. `git add <archivo>` - Agrega un archivo al área de staging. 4. `git commit -m "mensaje"` - Realiza un commit de los archivos en el área de staging con un mensaje descriptivo. 5. `git rm --cached <archivo>` - Elimina un archivo del área de staging. 6. `git log` - Muestra el historial de commits. Estos comandos son fundamentales para trabajar con Git y gestionar versiones de archivos.
Si usan windows pueden crear los archivos con notepad( no se podra desde la interfaz)
En términos más sencillos, esta clase me recordó a un chequeo de aeropuerto. 1. El pasajero sería el archivo.txt, que aún está en su país (es decir, es un archivo local). 2. Luego, pasa por el chequeo (staging), donde se verifica si está listo. 3. Dependiendo de si pasa este chequeo, el archivo se envía al repositorio (sube al avión). Si no pasa el chequeo, se queda en la máquina local.
En Git se manejan 4 zonas: **Directorio de trabajo** - En el ejemplo sería la carpeta llamada "Proyecto". En esta carpeta es donde escribimos código. **Staging** - Es el lugar a donde se envía el código que escribimos en el Directorio de trabajo. El código llega a esta etapa mediante `git add` **Repositorio local** - Aquí llegan todos los archivos que se encuentren en *<u>staging</u>* y hayan sido confirmados mediante `git commit` **Repositorio remoto** - Es aquí donde todo el equipo puede ver tu código, es la fase en donde el archivo o archivos que hayas desarrollado están listos para ser presentados y llega a esta zona utilizando `git push`
buenos días algún compañero me puede ayudar
Explicación de las treas áreas en el flujo de trabajo en **Git**, mostrando cómo un archivo pasa por tres estados principales: 1. **Directorio de trabajo** (Working Directory) * Es donde se encuentran los archivos de tu proyecto. * Aquí puedes crear, modificar, mover o eliminar archivos usando comandos como:`cp, mv, touch, rm, delete` * Un archivo en este estado aún no está bajo control de Git hasta que lo agregues. 2. **Área de staging** (Staging Area o Index) * Es una zona intermedia donde preparas los archivos antes de confirmarlos en el repositorio. * Para mover archivos del directorio de trabajo al área de staging, usas:`git add <file>` * Para eliminar un archivo del staging sin borrarlo del directorio de trabajo:`git rm --cached <file>` * Para eliminarlo completamente (del staging y del directorio de trabajo):`git rm --force <file>` 3. **Repositorio Git** (Git Repository) * Es donde Git almacena de manera permanente los cambios confirmados (commits). * Para enviar los cambios del área de staging al repositorio, usas:`git commit -m "Mensaje del commit"` * Para modificar el último commit:`git commit --amend` * Si necesitas deshacer cambios, tienes tres opciones de `git reset`: * `--soft`: Mantiene los cambios en staging. * `--mixed`: Mueve los cambios al directorio de trabajo sin confirmarlos. * `--hard`: Borra los cambios completamente (¡cuidado con este!). Este diagrama muestra el flujo de trabajo básico en Git y cómo moverse entre estos tres estados. 🚀 *Cortesía Gpt*
buenos dias busco alguien que me ayude
Cuando recibes el mensaje de advertencia "Permission denied" al ejecutar `git status`, significa que Git no tiene permisos para acceder a las rutas mencionadas. Esto puede deberse a que estás intentando acceder a directorios protegidos o de sistema. Para resolverlo, asegúrate de que estás ejecutando Git con los permisos adecuados. Intenta lo siguiente: 1. Abre la terminal como administrador. 2. Verifica que estés en el directorio correcto ejecutando `cd path/to/your/repo`. 3. Intenta de nuevo el comando `git status`. Si persiste el problema, verifica los permisos de las carpetas en cuestión o considera cambiar la ubicación de tu repositorio a un directorio donde tengas acceso completo.
Los comandos básicos para un flujo estándar en Git son: 1. `git init`: Inicializa un nuevo repositorio. 2. `git add <archivo>`: Agrega un archivo al área de staging. 3. `git status`: Muestra el estado de los archivos en el repositorio. 4. `git commit -m "mensaje"`: Realiza un commit de los cambios en staging con un mensaje descriptivo. 5. `git log`: Muestra el historial de commits. Este flujo te permite gestionar tus cambios de manera ordenada en el repositorio.
Buenas noches :) Les comparto mi repo remoto de git con anotaciones de los comandos. <https://github.com/dr1602/git> Saludos.
El profe Espinosa explica muy bien. he entendido muy bien, explica despacio y se entiende muy bien. gracias profe..
Hola Les comparto los comandos vistos en clase ```python git init ls -a nano testing.txt git status git add testing.txt git status git rm --cached testing.txt git status git add . git status git commit -m "New testing file" nano testing2.txt git status git add . git status git commit -m "Second test file created" git log clear ```
cuando escribo el comando `nano testing.txt` me genera un error, no reconoce la sentencia
![](https://static.platzi.com/media/user_upload/image-50c219bb-834c-4180-bd47-de9c85ea0dfc.jpg)Les recomiendo utilizar Cmder temrinal les funciona todo Linux y Windows en el, pueden utilizar nano, ls, clear y al igual los comandos de DOS para Windows.
En este caso, cual comando se tendria que utilizar para poder crear el archivo en Windows? Debido a que estoy colocando nano y me sale esto. ![](https://static.platzi.com/media/user_upload/image-d7680f87-cff3-46ab-919d-106cdf4af745.jpg)
Gracias por los comandos y los recursos
Sí, si ya creaste tu archivo `.gitignore` y aún no has subido las imágenes a un commit, al subir el `.gitignore` Git tomará en cuenta las reglas que definiste en él. Esto significa que las imágenes mencionadas en el `.gitignore` serán ignoradas y no se agregarán a los futuros commits. Recuerda que el archivo `.gitignore` solo afecta a archivos que no han sido seguidos por Git.
Para estructurar un archivo `.gitignore` que excluya imágenes, se pueden usar patrones específicos. A continuación, algunos ejemplos que puedes incluir: ``` # Ignorar todas las imágenes *.jpg *.jpeg *.png *.gif *.bmp *.svg # Ignorar carpetas de imágenes específicas /images/ ``` Este archivo le indica a Git que no rastree los archivos con las extensiones mencionadas y cualquier archivo dentro de la carpeta `images`. Recuerda que la estructura puede variar según tus necesidades.
Con las gráficas de Staging y señalado por colores me quedó más que claro! de lujo
El proceso para hacer un commit en Git incluye los siguientes pasos: 1. **Crear o modificar archivos** en tu proyecto. 2. **Agregar archivos al área de staging** usando `git add <nombre-del-archivo>` o `git add .` para agregar todos. 3. **Realizar el commit** con `git commit -m "mensaje descriptivo"` para registrar los cambios en el repositorio. Este flujo asegura que tus cambios estén documentados y organizados. ¡Continúa practicando y mejorando tus habilidades en Git!
### CREAR O ABRIR UN ARCHIVO `nano` funciona para editar o crear un archivo ### ESTADO DEL REPOSITORIO `git status` > muestra el estado actual del repositorio y se identifica si está trabajando en una rama e indica en que rama se encuentra y si tiene commits pendientes de ser enviados. ### MOVIMIENTO DE ESTADO STAGING * `git add` y nombre del documento el cual quieres mover al staging ![image.png](https://prod-files-secure.s3.us-west-2.amazonaws.com/cdbe61c5-02a1-4b14-8119-58ae33c07213/31c94427-bb06-4313-a63e-6b11f594eb84/f37bed49-3f44-4e7e-b1ea-b8bc1367068a.png) ### MOVIMIENTO DE ESTADO DE STAGING A REPOSITORIO DE GIT * `git commit` > se utiliza para configurar los cambios que has preparado en el área anterior llamada staging * `git commit -m 'ARGUMENTO EN COMILLAS'` > la (m) indica que se le agrega un comentario![image.png](https://prod-files-secure.s3.us-west-2.amazonaws.com/cdbe61c5-02a1-4b14-8119-58ae33c07213/6b49b0a2-dc31-4cd3-b1b6-33287706713a/cba65217-fb4d-426f-89c2-7804e0a539c6.png) ### MOVIMIENTO PARA SACAR LOS ARCHIVOS DE STAGING * `git rm --cached documento` > con este comando podemos sacar el archivo que se necesita del staging ### COMANDO PARA MOSTRAR EL HISTORIAL DE COMMITS git log > Funciona para identificar el historial de commits en el repositorio de git y se ve el identificado o hash, autor del commit, fecha del commit y mensaje del commit
Excelente! Muchas gracias, ha sido muy ilustrativo tu forma de explicarlo.
Hola amigos. @Amin y todos. en esta clase se habló de archivos y todo está muy claro. me surge la curiosidad.... git funciona igualmente para el manejo de carpetas en un proyecto??
Hola... tengo una pregunta, resulta que me salio este error al ingresar el comando git add testing.txt $ git add testing.txt warning: in the working copy of 'testing.txt', LF will be replaced by CRLF the next time Git touches it ¿Es un error? ¿Que deberia hacer? Mi versión de git es: git version 2.47.0.windows.1
![](https://static.platzi.com/media/user_upload/image-3681a500-d51d-436b-86f9-597e453b7f62.jpg)![](https://static.platzi.com/media/user_upload/image-f2f084fe-2ffd-44de-a40e-4dff1071cb82.jpg)
El comando; ***nano testing.txt*** Significa que desde la terminal puedes crear un archivo de texto sin tener que ir al blog de notas, y la terminal simulara ser un blog de notas para editarlo desde la terminal misma. =) Profe, estos detalles son muy obvios pero importantes para los que estamos empezando. un fuerte abrazo!