Curso Git
Curso de Git y Github
- Starring
- Genres
Trailer
Episodios
- 01 ¿Por qué usar un sistema de control de versiones como Git?
- Un sistema de control de versiones como Git nos ayuda a guardar el historial de cambios y crecimiento de los archivos de nuestro proyecto. En realidad, los cambios y diferencias entre las versiones de nuestros proyectos pueden tener similitudes, algunas veces los cambios pueden ser solo una palabra o una parte específica de un archivo específico. Git está optimizado para guardar todos estos cambios de forma atómica e incremental, o sea, aplicando cambios sobre los últimos cambios, estos sobre los cambios anteriores y así hasta el inicio de nuestro proyecto. El comando para iniciar nuestro repositorio, o sea, indicarle a Git que queremos usar su sistema de control de versiones en nuestro proyecto, es git init. El comando para que nuestro repositorio sepa de la existencia de un archivo o sus últimos cambios es git add. Este comando no almacena las actualizaciones de forma definitiva, únicamente las guarda en algo que conocemos como “Staging Area” (área de montaje o ensayo). El comando para almacenar definitivamente todos los cambios que por ahora viven en el staging area es git commit. También podemos guardar un mensaje para recordar muy bien qué cambios hicimos en este commit con el argumento -m "Mensaje del commit". Por último, si queremos mandar nuestros commits a un servidor remoto, un lugar donde todos podamos conectar nuestros proyectos, usamos el comando git push. Comandos básicos de git git init: inicializa un repositorio de GIT en la carpeta donde se ejecute el comando. git add: añade los archivos especificados al área de preparación (staging). git commit -m “commit description”: confirma los archivos que se encuentran en el área de preparación y los agrega al repositorio. git commit -am “commit description”: añade al staging area y hace un commit mediante un solo comando. (No funciona con archivos nuevos) git status: ofrece una descripción del estado de los archivos (untracked, ready to commit, nothing to commit). git rm (. -r, filename) (–cached): remueve los archivos del index. git config --global user.email [email protected]: configura un email. git config --global user.name : configura un nombre. git config --list: lista las configuraciones. Analizar cambios en los archivos de un proyecto Git git log: lista de manera descendente los commits realizados. git log --stat: además de listar los commits, muestra la cantidad de bytes añadidos y eliminados en cada uno de los archivos modificados. git log --all --graph --decorate --oneline: muestra de manera comprimida toda la historia del repositorio de manera gráfica y embellecida. git show filename: permite ver la historia de los cambios en un archivo. git diff : compara diferencias entre en cambios confirmados. Volver en el tiempo con branches y checkout git reset --soft/hard: regresa al commit especificado, eliminando todos los cambios que se hicieron después de ese commit. git checkout : permite regresar al estado en el cual se realizó un commit o branch especificado, pero no elimina lo que está en el staging area. git checkout – : deshacer cambios en un archivo en estado modified (que ni fue agregado a staging) git rm y git reset git rm: Este comando nos ayuda a eliminar archivos de Git sin eliminar su historial del sistema de versiones. Esto quiere decir que si necesitamos recuperar el archivo solo debemos “viajar en el tiempo” y recuperar el último commit antes de borrar el archivo en cuestión. git rm no puede usarse por sí solo, así nomás. Se debe utilizar uno de los flags para indicar a Git cómo eliminar los archivos que ya no se necesitan en la última versión del proyecto: git rm --cached : elimina los archivos del área de Staging y del próximo commit, pero los mantiene en nuestro disco duro. git rm --force : elimina los archivos de Git y del disco duro. Git siempre guarda todo, por lo que podemos acceder al registro de la existencia de los archivos, de modo que podremos recuperarlos si es necesario (pero debemos aplicar comandos más avanzados). git reset Con git reset volvemos al pasado sin la posibilidad de volver al futuro. Borramos la historia y la debemos sobreescribir. git reset --soft: Vuelve el branch al estado del commit especificado, manteniendo los archivos en el directorio de trabajo y lo que haya en staging considerando todo como nuevos cambios. Así podemos aplicar las últimas actualizaciones a un nuevo commit. git reset --hard: Borra absolutamente todo. Toda la información de los commits y del área de staging se borra del historial. git reset HEAD: No borra los archivos ni sus modificaciones, solo los saca del área de staging, de forma que los últimos cambios de estos archivos no se envíen al último commit. Si se cambia de opinión se los puede incluir nuevamente con git add. Ramas o Branches en git Al crear una nueva rama se copia el último commit en esta nueva rama. Todos los cambios hechos en esta rama no se reflejarán en la rama master hasta que hagamos un merge. git branch : crea una nueva rama. git checkout : se mueve a la rama especificada. git merge : fusiona la rama actual con la rama especificada y produce un nuevo commit de esta fusión. git branch: lista las ramas generadas.
- 03 Instalando GitBash en Windows
- Al implementar Git Bash, podrás tener una terminal de Git en el sistema operativo Windows. Esto te ayudará a acceder a tus repositorios al conectarte desde GitHub. Descubramos más acerca de esta integración. ¿Qué es Git bash? Git Bash es una aplicación en línea que une las utilidades de Git y Bash en un sistema operativo de Windows. Mejora la experiencia de la línea de comandos y se comporta como una especie de intérprete para un sistema operativo Unix, pero adaptado para funcionar en Windows. Además, el programa permite a los usuarios acceder a las herramientas de Git,y realizar tareas de control de versiones a través de comandos de texto en lugar de una interfaz gráfica de usuario. Incluye otros comandos de Unix y herramientas como ssh , scp y rsync
- 04 Instalando Git en OSX
- En Mac, Git está instalado en el sistema operativo por defecto. Este instalador no es realmente necesario. Puedes verificar que tienes instalado Git desde el terminal usando el comando: git --version Esto deberia generar una respuesta similar a esta: git version 1.9.3 (Apple Git-50)
- 05 Instalando Git en Linux
- Cada distribución de Linux tiene un comando especial para instalar herramientas y actualizar el sistema. Aquí veremos un ejemplo de los comandos para instalar Git en Linux
- 06 Editores de código para trabajar con Git y archivos de texto
- Un editor de código o IDE es una herramienta que nos brinda muchas ayudas para escribir código, algo así como un bloc de notas muy avanzado. Los editores más populares son VSCode, Sublime Text y Atom, pero no es obligatorio usar alguno de estos para programar. Conoce más a fondo sobre qué es un IDE.
- 07 Introducción a la terminal y línea de comandos
- La línea de comandos nos permite interactuar con nuestro computador sin necesidad de utilizar una interfaz gráfica. Sin embargo, los computadores emplean distintos sistemas de archivos y manejan diferentes comandos, dependiendo del sistema operativo que utilicen.
- 08 Cómo crear un repositorio de Git y hacer tu primer commit
- Le indicaremos a Git que queremos crear un nuevo repositorio para utilizar su sistema de control de versiones. Solo debemos posicionarnos en la carpeta raíz de nuestro proyecto y ejecutar el comando:
- 09 Analizar cambios en los archivos de tu proyecto con Git
- El comando 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. Si queremos ver la diferencia entre una versión y otra, no necesariamente todos los cambios desde la creación del archivo, podemos usar el comando git diff commitA commitB. Recuerda que puedes obtener el ID de tus commits con el comando git log.
- 10 ¿Qué es staging_ Repositorios en git
- El staging es el lugar donde se guardan temporalmente los cambios, para luego ser llevados definitivamente al repositorio. El repositorio es el lugar donde se guardan todos los registros de los cambios realizados a los archivos. Para iniciar un repositorio, o sea, activar el sistema de control de versiones de Git en tu proyecto, solo debes ejecutar el comando git init.
- 11 ¿Qué es branch (rama) y cómo funciona un Merge en Git?
- Una rama o branch es una versión del código del proyecto sobre el que estás trabajando. Estas ramas ayudan a mantener el orden en el control de versiones y manipular el código de forma segura. En otras palabras, un branch o rama en Git es una rama que proviene de otra. Imagina un árbol, que tiene una rama gruesa, y otra más fina, en la rama más gruesa tenemos los commits principales y en la rama fina tenemos otros commits que pueden ser de hotfix, devlopment entre otros.ㅤ
- 12 Volver en el tiempo en nuestro repositorio utilizando reset y checkout
- El comando 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. También hay una forma de hacerlo un poco más “ruda”: usando el comando git reset. En este caso, no solo “volvemos en el tiempo”, sino que borramos los cambios que hicimos después de este commit. 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.
- 14 Cómo trabajar con repositorios remotos en GIT
- 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.
- 15 Qué son y cómo funcionan las ramas o branches de Git
- Las ramas (branches) son la forma de hacer cambios en nuestro proyecto sin afectar el flujo de trabajo de la rama principal. Esto porque queremos trabajar una parte muy específica de la aplicación o simplemente experimentar. La cabecera o HEAD representan la rama y el commit de esa rama donde estamos trabajando. Por defecto, esta cabecera aparecerá en el último commit de nuestra rama principal. Pero podemos cambiarlo al crear una rama (git branch rama, git checkout -b rama) o movernos en el tiempo a cualquier otro commit de cualquier otra rama con los comandos (git reset id-commit, git checkout rama-o-id-commit).
- 16 Fusión de ramas con Git merge
- La fusión en Git es la forma en que este sistema une un historial bifurcado. El comando git merge permite integrar líneas de desarrollo independientes generadas por git branch en una sola rama. Con este comando, podemos crear un nuevo commit que combina dos ramas o branches: la rama actual y la rama que se indica después del comando. Estos comandos de fusión del merge afectan solo a la rama actual y no a la rama de destino. Por lo tanto, te recomendamos utilizar git checkout para seleccionar la rama actual y git branch -d para eliminar la rama de destino obsoleta. Funcionamiento de Git merge Git merge fusiona secuencias de confirmaciones en un solo historial, generalmente para combinar dos ramas. Busca una confirmación de base común y genera una confirmación de fusión que representa la combinación de las dos ramas hasta el resultado final.
- 17 Resolución de conflictos al hacer un merge
- Git nunca borra nada, a menos que nosotros se lo indiquemos. Cuando usamos los comandos git merge o git checkout estamos cambiando de rama o creando un nuevo commit, no borrando ramas ni commits (recuerda que puedes borrar commits con git reset y ramas con git branch -d). Git es muy inteligente y puede resolver algunos conflictos automáticamente: cambios, nuevas líneas, entre otros. Pero algunas veces no sabe cómo resolver estas diferencias, por ejemplo, cuando dos ramas diferentes hacen cambios distintos a una misma línea. Esto lo conocemos como conflicto y lo podemos resolver manualmente. Solo debemos hacer el merge, ir a nuestro editor de código y elegir si queremos quedarnos con alguna de estas dos versiones o algo diferente. Algunos editores de código como Visual Studio Code nos ayudan a resolver estos conflictos sin necesidad de borrar o escribir líneas de texto, basta con hacer clic en un botón y guardar el archivo. Recuerda que siempre debemos crear un nuevo commit para aplicar los cambios del merge. Si Git puede resolver el conflicto, hará commit automáticamente. Pero, en caso de no pueda resolverlo, debemos solucionarlo y hacer el commit. Los archivos con conflictos por el comando git merge entran en un nuevo estado que conocemos como Unmerged. Funcionan muy parecido a los archivos en estado Unstaged, algo así como un estado intermedio entre Untracked y Unstaged. Solo debemos ejecutar git add para pasarlos al área de staging y git commit para aplicar los cambios en el repositorio.
- 18 Cómo funcionan las llaves públicas y privadas
- Las llaves públicas y privadas, conocidas también como cifrado asimétrico de un solo camino, sirven para mandar mensajes privados entre varios nodos con la lógica de que firmas tu mensaje con una llave pública vinculada con una llave privada que puede leer el mensaje. Las llaves públicas y privadas nos ayudan a cifrar y descifrar nuestros archivos de forma que los podamos compartir sin correr el riesgo de que sean interceptados por personas con malas intenciones. Cómo funciona un mensaje cifrado con llaves públicas y privadas Ambas personas deben crear su llave pública y privada. Ambas personas pueden compartir su llave pública a las otras partes (recuerda que esta llave es pública, no hay problema si la “interceptan”). La persona que quiere compartir un mensaje puede usar la llave pública de la otra persona para cifrar los archivos y asegurarse que solo puedan ser descifrados con la llave privada de la persona con la que queremos compartir el mensaje. El mensaje está cifrado y puede ser enviado a la otra persona sin problemas en caso de que los archivos sean interceptados. La persona a la que enviamos el mensaje cifrado puede emplear su llave privada para descifrar el mensaje y ver los archivos. Nota: puedes compartir tu llave pública, pero nunca tu llave privada. Aporte creado por: David Behar
- 19 Configura tus llaves SSH en local
- En este ejemplo, aprenderemos cómo configurar nuestras llaves SSH en local. Cómo generar tus llaves SSH 1. Generar tus llaves SSH** Recuerda que es muy buena idea proteger tu llave privada con una contraseña. ssh-keygen -t rsa -b 4096 -C "[email protected]" 2. Terminar de configurar nuestro sistema. En Windows y Linux: Encender el “servidor” de llaves SSH de tu computadora: eval $(ssh-agent -s) Añadir tu llave SSH a este “servidor”: ssh-add ruta-donde-guardaste-tu-llave-privada
- 20 Uso de GitHub
- GitHub es una plataforma que nos permite guardar repositorios de Git que podemos usar como servidores remotos y ejecutar algunos comandos de forma visual e interactiva (sin necesidad de la consola de comandos). Luego de crear nuestra cuenta, podemos crear o importar repositorios, crear organizaciones y proyectos de trabajo, descubrir repositorios de otras personas, contribuir a esos proyectos, dar estrellas y muchas otras cosas. El README.md es el archivo que veremos por defecto al entrar a un repositorio. Es una muy buena práctica configurarlo para describir el proyecto, los requerimientos y las instrucciones que debemos seguir para contribuir correctamente. Para clonar un repositorio desde GitHub (o cualquier otro servidor remoto) debemos copiar la URL (por ahora, usando HTTPS) y ejecutar el comando git clone + la URL que acabamos de copiar. Esto descargará la versión de nuestro proyecto que se encuentra en GitHub. Sin embargo, esto solo funciona para las personas que quieren empezar a contribuir en el proyecto.
- 22 Tu primer push
- La creación de las SSH es necesario solo una vez por cada computadora. Aquí conocerás cómo conectar a GitHub usando SSH. Luego de crear nuestras llaves SSH podemos entregarle la llave pública a GitHub para comunicarnos de forma segura y sin necesidad de escribir nuestro usuario y contraseña todo el tiempo. Para esto debes entrar a la Configuración de Llaves SSH en GitHub, crear una nueva llave con el nombre que le quieras dar y el contenido de la llave pública de tu computadora. Ahora podemos actualizar la URL que guardamos en nuestro repositorio remoto, solo que, en vez de guardar la URL con HTTPS, vamos a usar la URL con SSH:
- 23 Git tag y versiones en Github
- En Git, las etiquetas o Git tags tienen un papel importante al asignar versiones a los commits más significativos de un proyecto. Aprender a utilizar el comando git tag, entender los diferentes tipos de etiquetas, cómo crearlas, eliminarlas y compartirlas, es esencial para un flujo de trabajo eficiente.
- 24 Manejo de ramas en GitHub
- Si no te funciona el comando gitk es posible no lo tengas instalado por defecto. Para instalar gitk debemos ejecutar los siguientes comandos: sudo apt-get update sudo apt-get install gitk
- 25 Configurar múltiples colaboradores en un repositorio de GitHub
- Por defecto, cualquier persona puede clonar o descargar tu proyecto desde GitHub, pero no pueden crear commits, ni ramas. Esto quiere decir que pueden copiar tu proyecto pero no colaborar con él. Existen varias formas de solucionar esto para poder aceptar contribuciones. Una de ellas es añadir a cada persona de nuestro equipo como colaborador de nuestro repositorio. Cómo agregar colaboradores en Github Solo debemos entrar a la configuración de colaboradores de nuestro proyecto. Se encuentra en: Repositorio > Settings > Collaborators Ahí, debemos añadir el email o username de los nuevos colaboradores.
- 26 Flujo de trabajo profesional: Haciendo merge de ramas de desarrollo a master
- Para poder desarrollar software de manera óptima y ordenada, necesitamos tener un flujo de trabajo profesional, que nos permita trabajar en conjunto sin interrumpir el trabajo de otros desarrolladores. Una buena práctica de flujo de trabajo sería la siguiente: Crear ramas Asignar una rama a cada programador El programador baja el repositorio con git pull origin master El programador cambia de rama El programador trabaja en esa rama y hace commits El programador sube su trabajo con git push origin #nombre_rama El encargado de organizar el proyecto baja, revisa y unifica todos los cambios Aporte creado por: Alejandro Dubon.
- 27 Flujo de trabajo profesional con Pull requests
- En un entorno profesional normalmente se bloquea la rama master, y para enviar código a dicha rama pasa por un code review y luego de su aprobación se unen códigos con los llamados merge request. Para realizar pruebas enviamos el código a servidores que normalmente los llamamos staging develop (servidores de pruebas) luego de que se realizan las pruebas pertinentes tanto de código como de la aplicación estos pasan al servidor de producción con el ya antes mencionado merge request. Los PR (pull requests) son la base de la colaboración a proyectos Open Source, si tienen pensando colaborar en alguno es muy importante entender esto y ver cómo se hace en las próximas clases. Por lo general es forkear el proyecto, implementar el cambio en una nueva rama, hacer el PR y esperar que los administradores del proyecto hagan el merge o pidan algún cambio en el código o commits que hiciste.
- 28 Utilizando Pull Requests en GitHub
- Un Pull Request es una función de GitHub que permite a tu equipo solicitar la revisión y aprobación de sus cambios antes de fusionarlos en la rama principal de desarrollo, denominada “master” o “main”. Al crear un PR se genera una conversación en la que los demás miembros pueden seguir y comentar los cambios propuestos en el código del repositorio. Esto permite detectar cualquier error o problema potencial antes de integrarlos en la rama principal, lo que ayuda a mantener el proyecto más limpio y estable. Estructura de la incorporación de cambios El proceso para hacer un pull request consiste en indicar la rama y repositorio de origen y destino. De esta forma, un desarrollador podrá incluir tus cambios en su proyecto.
- 29 Creando un Fork, contribuyendo a un repositorio
- Los forks o bifurcaciones son una característica única de GitHub en la que se crea una copia exacta del estado actual de un repositorio directamente en GitHub. Este repositorio podrá servir como otro origen y se podrá clonar (como cualquier otro repositorio). En pocas palabras, lo podremos utilizar como un nuevo repositorio git cualquiera Un fork es como una bifurcación del repositorio completo. Comparte una historia en común con el original, pero de repente se bifurca y pueden aparecer varios cambios, ya que ambos proyectos podrán ser modificados en paralelo y para estar al día un colaborador tendrá que estar actualizando su fork con la información del original. Al hacer un fork de un poryecto en GitHub, te conviertes en dueñ@ del repositorio fork, puedes trabajar en este con todos los permisos, pero es un repositorio completamente diferente que el original, teniendo solamente alguna historia en común (como crédito al creado o creadora original). Los forks son importantes porque es la manera en la que funciona el open source, ya que, una persona puede no ser colaborador de un proyecto, pero puede contribuír al mismo, haciendo mejor software que pueda ser utilizado por cualquiera.
- 30 Haciendo deployment a un servidor
- Deploy es el proceso que permite enviar al servidor uno o varios archivos. Este servidor puede ser de prueba, desarrollo o producción. En el siguiente ejemplo veremos cómo se realiza el deployment de un documento en un servidor web básico. Pasos para hacer deployment en un servidor web: Entrar a la capeta de los archivos del servidor. Copiar link en clone, elegir entre HTTPS o SSH del repositorio a contribuir. -En la carpeta deseada se clona el repositorio:
- 31 Hazme un pull request
- Queremos que uses las habilidades ya aprendidas para aplicarlas en esta clase. Haz un fork de el repositorio de GitHub y realiza las tareas que te indicaremos en esta clase. Ojo, debes seguir las reglas e instrucciones que se dieron en el video. Regla a seguir: Dentro del ID “post” luego de “suscribete y dale like” agrega otra línea o párrafo con tu nombre o tu nombre de usuario en Platzi. ¡Suerte! Y #NuncaParesDeAprender
- 32 Ignorar archivos en el repositorio con .gitignore
- No todos los archivos que agregas a un proyecto deberían ir a un repositorio. Por ejemplo, cuando tienes un archivo donde están tus contraseñas que comúnmente tienen la extensión .env o cuando te estás conectando a una base de datos; son archivos que nadie debe ver. Por diversas razones, no todos los archivos que agregas a un proyecto deberían guardarse en un repositorio. Esto es porque hay archivos que no todo el mundo debería de ver, y hay archivos que al estar en el repositorio ralentizan el proceso de desarrollo (por ejemplo: los binary large objects, blob, que tardan en descargarse). Para que no se suban estos archivos no deseados se puede crear un archivo con el nombre .gitignore en la raíz del repositorio con las reglas para los archivos que no se deberían subir: Aquí puedes ver la sintaxis de los .gitignore. Las razones principales para tomar la decisión de no agregar un archivo a un repositorio son: Es un archivo con contraseñas (normalmente con la extensión .env) Es un blob (binary large object, objeto binario grande), mismos que son difíciles de gestionar en git. Son archivos que se generan corriendo comandos, por ejemplo la carpeta node_modules, que genera npm al correr el comando npm install Aporte creado por: David Behar.
- 33 Readme.md es una excelente práctica
- README.md es el lugar donde se explica de qué trata el proyecto, cómo utilizarlo y demás información que se considere que se deba conocer cualquier persona que vaya a trabajar de alguna forma con el proyecto. . Los archivos README son escritos en un lenguaje llamado markdown, por eso la extensión .md, mismo que es un estándar de escritura en diversos sitios (como Platzi, Wikipedia y el mismo GitHub). Aquí puedes ver las reglas de markdown. Los README.md pueden estar en todas las carpetas, pero el más importante es el que se encuentra en la raíz. Este documento ayuda a que los colaboradores sepan información relevante del proyecto, módulo o sección. Puedes crear cualquier archivo con la extensión .md pero solo los README.md los mostrará por defecto GitHub. Aporte creado por: David Behar.
- 34 Tu sitio web público con GitHub Pages
- GitHub tiene un servicio de hosting gratis llamado GitHub Pages. Con él, puedes tener un repositorio alojado en GitHub y hacer que el contenido se muestre en la web en tiempo real. Este es un sitio para nuestros proyectos donde lo único que tenemos que hacer es tener un repositorio alojado. En la página, podemos seguir las instrucciones para crear este repositorio Pasos para subir un repositorio a GitHub Pages Debemos tomar la llave SSH y hacer un git clone #SSHexample en mi computador local (Home). Luego, accederemos a la carpeta nueva que aparece en nuestra máquina local. Creamos un nuevo archivo que se llame index.html Guardamos los cambios, hacemos un git pull y seguido de esto un git push a master. Vamos a las opciones de settings de este repositorio y, en la parte de abajo, en la columna Github Pages, configuramos el source o fuente para que traiga la rama master Guardamos los cambios. Después de esto, podremos ver nuestro trabajo en la web como si tuviéramos nuestro propio servidor. Aporte creado por: Jhon Bangera.
- 35 Git Rebase: reorganizando el trabajo realizado
- Rebase es el proceso de mover o combinar una secuencia de confirmaciones en una nueva confirmación base. La reorganización es muy útil y se visualiza fácilmente en el contexto de un flujo de trabajo de ramas de funciones. El proceso general se puede visualizar de la siguiente manera.
- 36 Cómo usar Git Stash: guarda cambios temporalmente
- El comando git stash te permite almacenar temporalmente (o guardar en un stash), los cambios que hayas efectuado en el código en el que estás trabajando para que puedas trabajar en otra cosa y, más tarde, regresar y volver a aplicar los cambios. Guardar los cambios en stashes resulta práctico si tienes que cambiar rápidamente de contexto y ponerte con otra cosa, pero estás en medio de un cambio en el código y no tienes todo listo para confirmar los cambios. Git stash lo puedes usar sin necesidad de crear una nueva rama o hacer un commit. Además, no pierdes tus cambios. git stash: guarda los cambios temporalmente en memoria cuando no quieres hacer un commit aun git stash save “mensaje”: guarda un stach con mensaje git stash list: muestra la lista de cambios temporales git stash pop: trae de vuelta los cambios que teníamos guardados en el ultimo stash git stash apply stash@{n}: trae el stash que necesites con indicar su número dentro de las llaves git stash drop: borra el ultimo stash git stash clear: borra todos los stash
- 37 Git Clean: limpiar tu proyecto de archivos no deseados
- Mientras estamos trabajando en un repositorio podemos añadir archivos a él, que realmente no forma parte de nuestro directorio de trabajo, archivos que no se deberían de agregar al repositorio remoto. El comando clean actúa en archivos sin seguimiento, este tipo de archivos son aquellos que se encuentran en el directorio de trabajo, pero que aún no se han añadido al índice de seguimiento de repositorio con el comando add.
- 38 Git cherry-pick: traer commits antiguos al head del branch
- Git cherry-pick es un comando en Git que selecciona y aplica commits específicos de una rama o branch a otra. Todo, sin tener que hacer un merge completo. Así, podemos copiar un commit específico y aplicarlo de forma aislada en la rama de destino, conservando su historial. Escenarios de uso de Git Cherry Pick Este comando facilita la incorporación precisa de cambios, optimizando la colaboración y el mantenimiento en proyectos de desarrollo de software. Veamos sus casos de uso. 1. Colaboración en equipo Antes que nada, puede ser útil implementarlo cuando diferentes miembros del equipo trabajan en áreas similares del código, pues permite seleccionar y aplicar commits específicos a cada rama, facilitando el progreso individual. 2. Solución de bugs o errores Cuando encuentras un error o bug, es importante solucionarlo y entregar la corrección a los usuarios lo más rápido posible. Con Git Cherry Pick, puedes aplicar rápidamente un commit de verificación en la rama principal, evitando que afecte a más usuarios. 3. Deshacer cambios y recuperar commits perdidos A veces, una rama de funcionalidad puede ser obstoleta y no ser fusionada con la rama principal. O puede suceder que una solicitud de extracción (pull request) sea cerrada sin ser fusionada. Git nunca pierde esos commits y, a través de comandos como git log y git reflog, puedes encontrar y aplicar los commits utilizando Git Cherry Pick.
- 39 Git Reset y Reflog: úsese en caso de emergencia
- Git guarda todos los cambios aunque decidas borrarlos, al borrar un cambio lo que estás haciendo sólo es actualizar la punta del branch, para gestionar éstas puntas existe un mecanismo llamado registros de referencia o reflogs…La gestión de estos cambios es mediante los hash’es de referencia (o ref) que son apuntadores a los commits…Los recoges registran cuándo se actualizaron las referencias de Git en el repositorio local (sólo en el local), por lo que si deseas ver cómo has modificado la historia puedes utilizar el comando:
- 40 Reconstruir commits en Git con amend
- Git amend es una forma que tienes para hacer cambios a tu commit más recientes sin tener que hacer un nuevo commit. Recomendaciones en el uso de git amend El comando de git amend se usa para modificar el último commit. Es decir, te permite “revisar” o “corregir” el último cambio confirmado que hayas hecho en tu proyecto. Por ejemplo, imagínate que acabas de hacer un commit, pero te diste cuenta de que no querías enviarlo porque faltaba algo más. En lugar de hacer un nuevo commit, puedes usar git commit --amend para agregar esos cambios al commit más reciente. Esto es útil porque mantiene tu historial de commits limpio y organizado. Usar amend es considerado una mala práctica, especialmente después de haber hecho push o pull al repositorio remoto. Al hacer amend con algún commit que ya esté en remoto, se generará un conflicto que deberá resolverse con un commit adicional. En este proceso, se perderá el beneficio del amend. No utilizar --amend para reconstruir commits que ya se encuentran en el repositorio remoto. Esto sería una mala práctica. ¿Cómo hacer un git amend? Utilizar amend para remendar un commit puede modificar el commit más reciente (enmendar) en la misma rama. Se ejecuta de la siguiente manera:
- 41 Buscar en archivos y commits de Git con Grep y log
- A medida que nuestro proyecto en Git se hace más grande, vamos a querer buscar ciertas cosas. Por ejemplo: ¿cuántas veces en nuestro proyecto utilizamos la palabra color? Para buscar, empleamos el comando git grep color y nos buscará en todo el proyecto los archivos en donde está la palabra color. Con git grep -n color nos saldrá un output el cual nos dirá en qué línea está lo que estamos buscando. Con git grep -c color nos saldrá un output el cual nos dirá cuántas veces se repite esa palabra y en qué archivo. Si queremos buscar cuántas veces utilizamos un atributo de HTML lo hacemos con git grep -c "<p>".
- 42 Comandos y recursos colaborativos en Git y GitHub
- A continuación veremos una lista de comandos colaborativos para facilitar el trabajo remoto en GitHub: git shortlog -sn: muestra cuantos commit han hecho cada miembro del equipo. git shortlog -sn --all: muestra cuantos commit han hecho cada miembro del equipo, hasta los que han sido eliminados. git shortlog -sn --all --no-merge: muestra cuantos commit ha hecho cada miembro, quitando los eliminados sin los merges. git blame ARCHIVO: muestra quien hizo cada cosa línea por línea. git COMANDO --help:muestra como funciona el comando. git blame ARCHIVO -Llinea_inicial,linea_final: muestra quien hizo cada cosa línea por línea, indicándole desde qué línea ver. Ejemplo -L35,50. git branch -r: se muestran todas las ramas remotas. git branch -a: se muestran todas las ramas, tanto locales como remotas.
- 43 Tu futuro con Git y GitHub
- ¡Felicitaciones por terminar el Curso profesional de Git y GitHub! Aprendimos cómo usar Git y GitHub, hacer merge request, investigar quién hizo qué a través de la línea de comandos, cómo utilizar GitHub Pages, cómo revertir cambios, cómo usar git stash, git tags y mucho más. Ahora queda de tu parte experimentar, fallar, subir, borrar y por último hacer deploy de tu proyecto y compartirlo con la comunidad. Recuerda resolver los ejercicios, completar el examen, darle 5 estrellas al profesor y compartir tu proyecto, notas, todas tus dudas y comentarios en la sección de discusiones.