Aprende Git y Github desde cero 2026 [Forma fácil]

1. Clase magistral de introducción a Git: Bienvenido al curso ultimate it. En este curso, lo vamos a aprender desde cero hasta conceptos más avanzados. Empezamos con ¿qué es? Por qué a todas las empresas les encanta, cómo funciona realmente Git, configura Git en nuestro sistema. Conceptos básicos de Git como poner en escena los archivos y cometer el ignorar algunos archivos Después de eso, tenemos sección completa para navegar por el historial de commit. En eso, podemos comparar dos commits, volver a especificarlo, agregar textos. Después de eso, tenemos sección para sucursales y fusión, que es el tema más importante de kit También veremos probar los cambios, diferentes tipos de fusión, resolución de conflictos como Pro, tipos de reset, técnica de picking de cereza, después de eso, tenemos sección para trabajar en equipo en la que te mostraré prácticamente cómo los miembros del equipo trabajan juntos usándolo En eso, tenemos clonación, padging, pull, push. También algunas características adicionales de github como lanzamientos, temas, hitos, contribuyen en proyecto de código abierto Después de eso, veremos cómo organizar nuestro historial de proyectos para que nuestro proyecto se vea más profesional, Modificar los commits existentes, dividiéndolos y machacándolos mucho, mucho más cosas Entonces en este curso, aprenderemos Git en ambos sentidos. Primero, veremos Enfoque de línea de comandos, y luego te mostraré cómo podemos hacer lo mismo usando herramientas GI como Gitub desktop, código Visa Studio y Git Pero como sabrás, las herramientas GI tienen características poco limitadas. Entonces es por eso que aprender comandos de Git es muy importante para nosotros. Si no sabes nada de Git o estás confundido acerca de los conceptos de Git o quieres dominar kit y Github, entonces este curso es para ti. Ahora podría preguntarse, ¿quién soy? Soy ingeniero de software y además enseño programación en lenguaje fácil de explicar usando mi canal de YouTube, Dios los bendiga, y con mis cursos en línea. Y en este curso, también te voy a dar algunos proyectos en los que puedes practicar los comandos del kit por Como puedes seguir conmigo porque cuando escribes comandos de Git por tu cuenta y experimentas con ellos, entonces entenderás que ordena correctamente. Cometer errores, aprende de los errores y hazlo hasta que domines esa habilidad Después de completar este curso, comprenderás correctamente cómo funciona el kit y lo usarás con confianza sin confundirte y usando las mejores técnicas Sé que estás emocionado de aprenderlo y Github, así como saltar y sumergirte en este curso. 2. ¿Qué es Git y Github?: Entonces antes de empezar a aprender la marcha, veamos qué es Git Git es el sistema de control de versiones más popular. Ahora podría preguntarse a qué me refiero con Sistema de control de versiones. Sistema de control de versiones significa que nos ayuda a mantener un registro de diferentes versiones de nuestro proyecto. Déjame explicarte con un ejemplo del mundo real. Imagina que estás trabajando en una aplicación de comercio electrónico. Ahora después de algún tiempo, realmente te equivocaste con tu código y no puedes identificar errores y no puedes resolverlos. Tú decides empezar de cero. Ahora bien, ¿cuál es la solución de que esta situación no vuelva a suceder? Una solución es que puedes duplicar tu proyecto y darle un nombre como versión 1.0. Y guárdala en algún lugar como respaldo. Entonces si en el futuro, volviste a estropearte, puedes volver a ese código de la versión 1.0 Ahora, a medida que introduce nuevas funciones, sigue tomando copias de seguridad y creando versiones de su aplicación. Pero tomar copias de seguridad manualmente lleva a muchos problemas, como problema de almacenamiento. Además, crea mucha confusión, como en la versión 1.0, qué características agregamos o eliminamos. Además, imagina que tienes un miembro del equipo más trabajando en el mismo proyecto, entonces tienes que hacerlo así tus copias de seguridad y qué cambio en esos proyectos, no puedas rastrear. Crea mucha confusión y estrés para el equipo. En ese momento el kit viene en la imagen. Kit nos ayuda a almacenar diferentes versiones de nuestros proyectos de manera muy sistemática y sin necesidad de tener almacenamiento extra. Supongamos que está trabajando en el archivo SML de punto índice, desea tomar copia de seguridad de su código actual Dile a Git, guarda este código de archivo en la historia. G toma una instantánea de tu código y simplemente guárdalo en su almacenamiento. Ahora, a medida que tu aplicación crece, tomas múltiples captura de pantalla y las guardas en el almacenamiento Git. Cuando quieras ver una versión en particular, Git te mostrará el historial de tu proyecto y podrás restaurar fácilmente ese código. Ahora puedes decir que entendemos que Git rastrea nuestro historial de proyectos, y es por eso que no necesitamos preocuparnos por las copias de seguridad manuales, sino de cómo resuelve problemas trabajando en equipo. Es otro tema. Déjame explicarte eso rápidamente. Aquí usted y los miembros de su equipo trabajan individualmente en el mismo proyecto, y ambos usan kit para rastrear el historial de su proyecto. Ahora, cuando hayas terminado con tu única tarea, entonces puedes tomar tu instantánea de código en Kit y subir ese proyecto en el servicio Cloud, lo que nos permite subir proyectos de kit. Ahora el miembro de tu equipo consigue tu proyecto o carpeta Git de este servicio Cloud y empieza a trabajar en eso. Cuando haya terminado con el pantano, entonces puede tomar instantáneas y cambios actualizados en el servicio Cloud Y ¿puedes adivinar qué servicio Cloud más utilizado por los desarrolladores? Cierto, es Github. Git y Github es diferente. Git es un sistema de control de versiones, y Github se utiliza para alojar proyectos Git en la Nube y también Github proporciona más funciones. Al usar Git y GitHub, podemos trabajar fácilmente en equipo sin enviarnos correos electrónicos al frente. No te preocupes. Esto lo entenderemos muy profundamente en la próxima sección. De hecho, tenemos toda la sección donde prácticamente te muestro cómo los desarrolladores trabajan entre sí. Para tapar rápidamente, es el sistema de control de versiones más popular. Con Git, podemos rastrear nuestro historial de proyectos de manera muy efectiva. Por lo tanto, no necesitamos preocuparnos copia de seguridad y recuperación manual. También por Git, podemos saber cuándo se realizan cambios particulares con fecha y hora y también quién hizo esos cambios. Además, Git hace que colaborar con los miembros del equipo sea muy fácil y muchos más beneficios que veremos en este curso. Es por eso que casi todas las empresas quieren desarrollador que conozca muy bien a Git, y por eso cada desarrollador necesita aprender Git y Github. Aquí en este curso, vamos a aprender Git muy profundamente. Estoy muy entusiasmado con esto y espero que tú también lo estés. Nos vemos en la siguiente lección. 3. Varias formas de usar Git: Ahora, déjame mostrarte las diversas formas usar Git como desarrollador. Entonces, la primera forma es que puedes usarlo en Línea de comandos, que significa que abres tu terminal y comienzas a escribir comandos para acceder a Git. Esta es una de las formas simples y fáciles de usar gate, y muchos desarrolladores prefieren la línea de comandos. Ahora bien, si no te gusta usar el enfoque de línea de comandos, entonces puedes usar nuestros editores de código para acceder a la puerta. Por ejemplo, en código VS, por defecto, obtenemos el panel de control fuente. Usando este panel, podemos realizar operaciones básicas de git. Ahora podrías preguntar, ¿qué pasa con que queremos usar más funciones de git? No te preocupes por eso. Tenemos una extensión de código VS llamada Gitans que es la extensión Git más popular y más utilizada Se puede ver que esta extensión es descargada por casi 30 millones de usuarios. También puedes usar esta extensión. Ahora, otra forma de usar su mediante el uso de la interfaz gráfica de usuario o GUI. GI significa que podemos usar una aplicación que está especialmente hecha para usar Git. Hoy en día, la aplicación Git más utilizada y sencilla es Github desktop. La aplicación de escritorio Gitub hizo que el kit fuera tan simple para los principiantes de Gate pero es una estructura súper simple y fácil de entender, pero no tiene todas sus características Si quieres usar otra herramienta GI, que tenga más funciones que Github desktop, entonces puedes usar Gate gracon Esta también es una herramienta popular para Git, pero su interfaz de usuario es poco compleja que la aplicación de escritorio Github. Pero al final de este curso, definitivamente te gustará Gate gracon Te mostrará por qué en próximas secciones. Ahora podrías preguntar, ¿cuál es la mejor manera de usarlo? Y la respuesta es el enfoque de línea de comandos, y al 70% a los desarrolladores les gusta usar el enfoque de línea de comandos. La primera razón es esto todas las herramientas GI, ya sea Github desktop o Kraken, viene con algunas limitaciones, lo que significa que para alguna tarea, definitivamente necesitas usar Línea de comandos Al usar la línea de comandos, puedes realizar todas las tareas relacionadas con Git. Otra razón es que yo las herramientas no siempre están disponibles para ti. Por ejemplo, a veces el servidor no permite usar herramientas GI para Git por alguna razón. En ese momento, si no conoces los comandos de Git, entonces te quedarás atascado en esta situación. La mayoría de las veces, a muchos desarrolladores les gusta usar tanto las herramientas GI como la línea de comandos, y también soy uno de ellos. Eso es lo que te enseñaré en este curso. Primero aprenderemos el enfoque de la línea de comandos, y luego también veremos esos conceptos usando herramientas GI. Aprenderás en ambos sentidos y luego tendrás que elegir la herramienta adecuada para la tarea que estás realizando. Déjame contarte un incidente en mi empresa donde trabajé como ingeniero de software. Había un tipo que realizaba todas las tareas del kit usando la línea de comandos, incluso tarea compleja también. Cree que se ve genial usar la línea de comandos para cada tarea. Pero todos sabemos que podemos realizar esa tarea mucho más fácil usando las herramientas I. Así que no te vuelvas como ese tipo. Hay que pensar inteligente. De esa manera puedo completar esta tarea más rápido y sin confundirme. Pasaremos la mayor parte de nuestro tiempo usando la línea de comandos porque es más rápida. Pero cuando pienso que usar la herramienta I es más beneficioso, entonces te mostraré así la manera de herramienta GI. Además, muchos desarrolladores principiantes tienen mucho miedo de usar la línea de comandos, o puedo decir recordando los comandos para andar, pero no te preocupes, te enseñaré todo de manera sencilla paso a paso y fácil de lo que piensas Obtendrás la confianza para usar Git como profesional. Ahora en la siguiente lección, veremos cómo instalar Git en nuestro sistema. 4. Configurar Git en nuestro sistema: Así que vamos a instalar Git en nuestro sistema. Pero antes de eso, vamos a comprobar si Git ya está disponible en nuestro sistema o no. Y para ello, usamos terminal. Entonces, si eres usuario de Windows, entonces presiona la tecla Windows y escribe CMD Y si eres Mcuser, entonces presiona Comando más espacio y escribe terminal Estoy usando Windows, así es como se ve mi terminal o CMD Tu terminal podría verse diferente. No importa. Entonces antes que nada, aquí escribimos git version para saber qué persona Git está instalada en nuestro sistema. Ver aquí obtenemos Git no es reconocido como un comando interno o externo. Si está recibiendo el mismo mensaje, entonces no está instalado en su sistema, y si obtiene la versión, entonces tiene que asegurarse de que la versión no sea demasiado antigua como dos o mayor que dos. Asegúrate de actualizar tu gaiterson con eso, puedes seguirlo fácilmente Así que para instalar o actualizar Git, abrimos nuestro navegador y buscamos aquí Git descargar Abre este post it sitio web. Bonito. Así que la última versión de Git es 2.44 0.0 Si estás viendo este curso en el futuro, es posible que obtengas una versión diferente, pero no te preocupes, aún puedes seguir este curso. Confía en mí, no obtienes ningún error. Desde aquí, puedes ver como tu sistema operativo, o simplemente podemos hacer clic en este botón. Da click aquí para descargar y verlo comenzar a descargar g. encantador. Ahora, vamos a abrir esta configuración. Primero, va a pedir permiso. Así que permítelo, haga clic en siguiente. Aquí puede seleccionar Ruta de instalación, así que haga clic en siguiente, siguiente, siguiente, y desde aquí, podemos seleccionar nuestro editor de código predeterminado. Voy a usar código de Visual Studio o VSCode porque casi 90% los desarrolladores usan VSCode y Siguiente, y haga clic en siguiente. A continuación, haga clic en siguiente. Haga clic en siguiente hasta que obtenga Instalar e iniciar la instalación. Hecho y haga clic en Finalizar. Ahora abre el menú de inicio y busca en Git Bash, que es la interfaz de línea de comandos para proporcionar la interfaz de terminal para el sistema Windows Para el resto de este curso, usaremos la CLI base de Git para escribir comandos de Git Si eres Mguser, entonces tienes que usar tu terminal porque la base es solo para Windows Aquí escribimos Git dash dash versión y C, aquí obtenemos nuestra versión Git 2.42 0.0 Instalamos Git con éxito en nuestro sistema. 5. Configura los detalles del usuario para git: Ahora para comenzar a usar Git, antes que nada, tenemos que hacer algunos ajustes de configuración como nombre de usuario, EID, editor de código predeterminado, que ya establecemos al instalar Git y también configuración de fin de línea No te preocupes. Son muy simples. Ahora podemos establecer estos configuración en tres niveles, nivel de sistema, que es para todos los usuarios de esta computadora. segundo nivel es el nivel global, que es para todos los repositorios del usuario actual, y el tercer nivel es el nivel local, que es para el repositorio actual. No tengas miedo, solo haz lo que yo hago. Abre terminal o ITBashf de todos, lo escribimos config para nivel global, y agregamos nombre de punto de usuario Aquí, agregamos códigos dobles y aquí entro mi nombre. Déjame hacer zoom un poco usando Control y plus, o podemos usar Control y desplazamiento del mouse. Bueno. Ahora pulsa Enter. Aquí, utilizamos códigos dobles porque tenemos un espacio en nuestro valor. También tienes que escribir tu nombre correcto aquí. Sea cual sea el nombre que escribas aquí, puedes ver ese nombre en el historial del repositorio. Ahora agreguemos el correo electrónico de la misma manera. Presione la flecha hacia arriba que devolverá el comando anterior, y aquí en el lugar del nombre del punto del usuario, escribimos el email del punto del usuario. Y aquí no tenemos espacio en nuestro valor. Podemos eliminar estos códigos dobles y simplemente escribo aquí mi correo electrónico. Ahora vamos a establecer nuestro editor de código predeterminado. Como te dije, en este curso, vamos a usar código VS. Si no tienes código VS, entonces puedes descargarlo de code.visualstudio.com Ahora volvemos a nuestro Git pash y escribimos Git config dash global co dot Editor Aquí, también agregamos código de códigos dobles, que es código de visual studio, espera. Ahora podrías preguntar por qué agregamos aquí espera? Este peso le dirá a nuestro terminal que espere hasta que cerremos la ventana del código VS. Aquí, consigue almacenar todos nuestros ajustes de configuración en el archivo de texto y para ver o editar esa pila, escribimos config Global E. Hit Enter. Ver, aquí obtenemos el archivo de configuración en vía código. A partir de aquí, podemos cambiar los valores configurados y si volvemos a nuestro pase Git aquí podemos ver que está esperando que nuestro editor cierre el archivo y eso es porque agregamos aquí espera. Cerremos este archivo de configuración de Git y veamos que salimos de él. Ahora casi terminamos nuestra configuración de configuración. Solo tenemos que hacer una configuración que es para fin de líneas. Este es un escenario muy importante que muchos desarrolladores extrañan olvidar. Esta configuración es muy útil cuando se trabaja con plataformas cruzadas. Por ejemplo, estás usando Windows como sistema operativo y otro tu colega usando el sistema operativo Mac. Cuando agrega un archivo de texto a Git para Windows, ese archivo usa R N, que son caracteres especiales utilizados en TextFile para administrar el diseño y la estructura de las líneas en el documento Pero en macOS o Linux, textfile use solo N. Así que si no manejamos la propiedad de fin de línea, obtenemos algunos problemas raros en Git Ahora para solucionar este problema, tenemos configuración de configuración llamada AutoCRLF que es retorno de carro, y avance de línea Así que aquí en nuestro ejemplo, si añadimos nuestro código en el repositorio Git, G eliminamos todos los retornos de carro y lo reemplazamos con el avance de línea. Ahora, cuando volvamos a querer obtener el mismo código, entonces Git volverá a actualizar nuestro código con retorno de carro y alimentación de línea ambos. Así que aquí tenemos que establecer esta propiedad CRLF Tru que convierte automáticamente este código Ahora cuando un usuario de Mac o Windows agrega el código al mismo repositorio, entonces andar, no tienes que actualizar ese código porque ya está en el feed de línea Aquí, para Mac y Linux los usuarios necesitan establecer esta propiedad AutoCRLF a la entrada, que es el tipo original No te preocupes por esto. No hace falta que entiendas esto tan profundamente. Simplemente haz lo que yo hago y ya estás listo para ir porque establecer la configuración es un proceso de una sola vez. En nuestro Git Bach escribimos Git config Global. Co punto AtosRF a True. Si eres usuario de Mac o usuario de Linux, entonces aquí en el lugar de True, tienes que agregar entrada y presionar Enter. Aquí, nuestra configuración está hecha. Ahora podemos empezar a aprender Git. 6. Cómo hacer que Git Bash se vea bien: Ahora, actualmente, nuestro gdbash se ve así. Hagamos que nuestro Gitbash se vea genial. Es divertido. Si estás usando simple terminal en Windows, donde te sugiero abrir gtbash, haz clic derecho en el Gitbsh y aquí en la parte inferior, Aquí, podemos seleccionar colores o podemos seleccionar tema. Aquí, obtenemos muchos temas. Entonces estos son temas muy decentes. Personalmente me gusta el tema de Drácula. Ves, esto se ve bien. Después de eso, podemos cambiar la transparencia y el cursor y podemos seleccionar el cursor parpadeante Ahora vamos por el texto. Aquí, podemos seleccionar fuentes. Puedes intentar cambiar estas fuentes. Estoy contento con la fuente actual, así puedo venderla. Además, suavizo las fuentes al completo y aplico y guardo la configuración y veo nuestro Git pash verse así Si quieres probar cualquier otro tema o cualquier otra fuente, entonces puedes hacerlo también. Estoy contento con la configuración. Ahora comencemos a aprender git. 7. Sección 02 Fundamentos de Git: Bienvenido a la segunda sección del curso Ultimate Kit. En esta sección, vamos a aprender conceptos muy fundamentales de kit, que todo usuario del kit debe conocer. Entonces primero, comenzamos con la comprensión del flujo de trabajo del kit. Aprenderás cómo funciona realmente Git, cómo inicializarlo repositorios, grabar el historial de código, poner en escena , cometer, que son conceptos realmente importantes porque muchos desarrolladores no saben cómo funciona, y luego se confunden mucho Así que mira esta sección completa, aunque conozcas conceptos básicos de kit, porque muchos desarrolladores realmente malinterpretan estos conceptos y se quedan atascados con kit Así que mira cada lección de esta sección. Vamos a sumergirnos en esto. 8. Inicializa el proyecto de Git: Entonces para comenzar a trabajar con Git, antes que nada, necesitamos agregar Git en nuestro proyecto o carpeta. Si no agregamos Git en nuestro proyecto, ¿cómo debería saber Git qué carpeta tiene que rastrear? Aquí estoy en la carpeta del proyecto, y aquí creo una nueva carpeta, digamos, Pista de tareas. Este es el primer nombre de proyecto que creé en mi curso ultimate react JS. Además, no te preocupes por esto. No vamos a crear ningún proyecto específico. Aquí, nuestro enfoque principal es dominar Git. Ahora necesitamos abrir esta ruta de carpeta en nuestro terminal o Git Bash Si eres usuario de Windows, entonces haz clic derecho aquí y obtienes la opción de abrir Git Bash aquí Verás, abrimos nuestra carpeta en el Git Bash, y si eres Mcuser entonces haz clic derecho en tu carpeta y obtendrás la opción de abrir nueva terminal en Ahora inicialicemos Git en nuestra carpeta. Aquí, simplemente escribimos Git en él y golpeamos Enter. Mira aquí obtenemos mensaje inicializado repositorio Git vacío con nuestra ruta de carpeta También podemos ver aquí obtenemos master, lo que simplemente significa que nuestra carpeta está lista para ello. Ahora, si en nuestro directorio de seguimiento de tareas, directorio significa carpeta, obtenemos otro directorio llamado.it Si no obtiene esa carpeta aquí, vaya a la opción de ver y marque aquí los archivos ocultos. Por defecto, este directorio está oculto porque no necesitamos tocar eso. Pero déjame mostrar lo que hay dentro de esta carpeta? Básicamente, la carpeta Git almacena información sobre nuestro historial de proyectos. Mira, aquí tenemos un montón de carpetas como ganchos, info, objetos, referencias, y algunos otros archivos. Si lo estás usando, no necesitas preocuparte por todos estos archivos. Estos archivos son detalles de implementación al respecto, cómo almacena información. No te preocupes por eso. No es asunto nuestro. Nuestro objetivo es usar Git y hacernos la vida más fácil y es por eso que por defecto, el directorio dot Git está oculto. Haces algo en este directorio o borras todo este directorio it, perderás tu historial de proyectos. En mi compañía, uno de mis amigos quitó esta carpeta git de su proyecto y luego intentó usar todos los comandos, pero no funcionan porque la carpeta.it no está disponible Déjame mostrarte eso. Aquí en nuestro Git Bash, estamos obteniendo master entre paréntesis, lo que significa que Git está rastreando esta carpeta Ahora para eliminar directorio Git, podemos escribir RM para eliminar R para recursivamente F para force, y escribir punto Git Golpea Enter. C, Git se elimina de este directorio. Por eso es importante la carpeta.it. Ahora inicialicemos nuevamente a Git en nuestro proyecto y para eso, qué comando usamos derecho, usamos Git en él Ver, de nuevo, hacemos nuestra carpeta como repositorio Git. repositorio Git básicamente significa que Git está rastreando el historial de este proyecto. Tan simple como eso. Ahora en la siguiente lección, entenderemos profundamente cómo funciona Git. 9. ¿Cómo funciona realmente Git?: Así que aquí inicializamos nuestro repositorio Git. Ahora veamos cuáles son los pasos bastante comunes del día a día que los desarrolladores hacen con él. Entenderemos esto con un ejemplo de la vida real. Imagina que estás escribiendo un libro de cuentos como Harry Potter. Ahora aquí, no quieres escribir nada directamente en tu libro de cuentos, trabajas o escribes en otro archivo Ahora supongamos que escribes el primer capítulo, primero lo revisas, es correcto o no. Si no es correcto, entonces haces cambios o actualizas ese archivo, y si es correcto, solo entonces tomarás una captura de pantalla de ese archivo y lo agregarás a tu libro de cuentos Este es el flujo de trabajo de Git también. Déjame explicarte. Aquí en nuestro repositorio Git, que es nuestro libro de cuentos en ejemplo Ahora no queremos agregar directamente nuestro código porque sea lo que sea que agreguemos en nuestro repositorio de Git, git lo almacenará en la historia. Empezamos a trabajar localmente, que es nuestra carpeta de seguimiento de tareas. Ahora supongamos que creamos un archivo en esa carpeta y necesitamos guardarlo como historial como nuestro archivo de escritura. Ahora, en ese momento, recuerden, verificamos que esté bien o no antes de guardar nuestra historia. Aquí también hacemos lo mismo. Nosotros revisamos, ¿está bien o no? ¿Queremos agregar o eliminar algo? Esta área de verificación se denomina área de espera. Ahora podría preguntarse por qué necesitamos esta zona de espera. Sin esta área de preparación, haga lo que haga en nuestro código local, todo el código se almacenará directamente en nuestro repositorio y no podemos tener oportunidad de ver qué cambiamos o qué eliminamos en comparación con el código anterior. Es por eso que se necesita área de puesta en escena. Ahora después de agregar nuestro código al área de puesta en escena, si satisfacemos solo entonces tomaremos una captura de pantalla de nuestro código y lo almacenaremos en nuestro repositorio Git. Ahora podría preguntarse, ¿cómo podemos agregar nuestro código local al área de espera? O ¿cómo podemos agregar nuestro código de área de preparación al historial de git? La respuesta es muy simple usando comandos Git. Supongamos aquí agregamos un archivo más llamado index dot gs. Queremos agregar este archivo en el área de puesta en escena. Aquí escribimos comando, Git add, y aquí escribimos nuestro nombre de archivo index dot js. Aquí, también podemos agregar varios nombres de archivos. Al usar este comando, agregamos nuestro código en el área de puesta en escena. Una cosa que quiero dejar claro es área de puesta en escena no es ninguna carpeta. El área de puesta en escena es solo memoria temporal que Git nos da. Muchos desarrolladores llaman área de puesta en escena como índice. Aquí comprobamos que nuestro código es correcto o no. Si no es correcto, entonces podemos actualizarlo o corregirlo porque no queremos almacenar código en el historial que tiene errores. Ahora, si estamos listos para almacenar este archivo en nuestro historial, entonces tomamos una instantánea del área de preparación y lo almacenamos en el historial de Git usando Git GamTth es la abreviatura Aquí escribimos nuestro mensaje el cual queremos almacenar con esta instantánea. En el futuro, sabremos qué agregamos en ese Kummet. Commit significa guardar la instantánea en el historial de Git. Por ejemplo, en el futuro, si arreglamos errores o agregamos nuevas características, hacemos en para cada Camt agregamos mensaje Commit, que claramente dice lo que hemos hecho en ese kat Con eso, podemos echar un vistazo fácilmente a nuestro historial de códigos. Asegúrate de que cada vez que cometas algo, por favor agrega un mensaje significativo. Cada confirmación que hacemos se almacena con un ID único, fecha y hora, nombre del autor, correo electrónico y nuestro mensaje de confirmación. A partir de estos detalles, podemos ver cuáles son los cambios realizados por quién y cuándo. Ahora supongamos que agregamos aquí otro archivo llamado data dot TXT. Dime qué tenemos que hacer para almacenar este nuevo archivo en la historia. Derecha. En primer lugar, agregamos nuestro código al área de ensayo con Git add data dot TXT. Y después de eso, podemos tomar snapshot de esta área de ensayo actual y almacenarla en el repositorio de Git usando Git Commit, agregando data dot txdFle en project Aquí, quiero aclarar una cosa es que después comprometer el código del área de ensayo al repositorio git, nuestra área de puesta en escena no quedará vacía. Se quedará igual a lo que nos comprometemos. Si en el futuro, agregamos o eliminamos algo en nuestro código local y luego lo agregamos en nuestro área de preparación, entonces solo aquellas actualizaciones de archivos que modificamos. Para recapitular rápidamente para soring el código en nuestro historial de git, primero, agregamos nuestro código al área de ensayo, y después de eso, si satisfacemos con nuestro código actual, solo entonces ingresaremos ese código en nuestro repositorio Git y el repositorio Git almacenará todos los comandos con sus detalles Tan simple como eso. No te preocupes si te confundes o tienes muchas preguntas, obtendrás todas tus respuestas a medida que avancemos en este curso, y apuesto a que dominarás Git como P. En esta sección, prácticamente trabajaremos con este flujo de trabajo de Git. 10. Ejercicio: flujo de trabajo de Git: En la lección anterior, aprendes el flujo de trabajo básico. Ahora quiero que dibujes la figura aproximada o flujo de trabajo rudo de la marcha con los dos comandos Completa el pequeño ejercicio, pero la condición es que no puedas ver la lección anterior. Intenta recordarlo y luego dibujarlo en el papel o en cualquier lugar. Si dibujas en papel, entonces puedes tomar foto y subirla en la sección de preguntas y respuestas Voy a tratar de verificar y responder a su envío. Después de completar este ejercicio, podrás ver la lección anterior y asegurarte de que tu flujo de trabajo sea correcto o no. Es un pequeño juego. No te preocupes por perder o ganar. 11. Agregar archivos al área de puesta en marcha: Ahora, déjame mostrarte prácticamente cómo podemos agregar archivos al área de costura. Pero antes que nada, necesitamos agregar archivo en nuestro código local. Abro carpeta de seguimiento de tareas en el código VS, y antes que nada, aquí, creo un nuevo archivo llamado capítulo uno punto TXT. Y aquí escribimos Hola. Estoy creando aquí archivo XD, pero puedes crear cualquier archivo. Guarde este archivo. Ahora queremos agregar esta pila al área de espera. En nuestra base de Git déjame verificar el estado actual. Si quieres borrar los comandos anteriores, entonces podemos escribir aquí claro. Se despejará todos nuestros comandos anteriores. Verifiquemos el estado con el estado de Git. Mira aquí nos metemos en rama, maestro, aún no hay commits. Y obtenemos un archivo sin seguimiento, que es el capítulo uno punto TXT Y también nos está dando sugerencia con Command Git add, nombre de archivo. Entonces podemos escribir aquí, agregar Git, y aquí podemos escribir el capítulo uno punto TXT. Si queremos añadir otros archivos, entonces podemos editar aquí con espacio, capítulo dos punto TXT, etcétera También podemos usar aquí star dot TXT, lo que significa agregar todos los archivos con extensión TXT. Además, podemos usar aquí Git add period, lo que significa agregar todos los archivos. Por lo general, muchos desarrolladores usan de esta manera, por lo que podemos usar cualquiera de estos comandos. Aquí uso Git agregar capítulo uno punto TXT. Ahora aquí no vemos nada, pero ¿cómo podemos comprobar que este archivo se agrega o no en el área de espera? ¿Me puedes decir que solo lo usamos? Podemos usar el estado de Git. Mira aquí obtenemos cambios de mensaje para que se vuelvan y eso es todo. Agregamos nuestro archivo en el área de puesta en escena. Ahora supongamos que cambiamos algo en nuestro archivo. Aquí agrego mundo en la segunda línea. Y guarda este archivo. Ahora vamos a verificar el estado nuevamente, así que obtén el estado y presiona Enter. Ver ahora aquí recibimos mensaje de modificado. Actualmente, en nuestro área de puesta en escena, tenemos nuestro código de edición anterior, que es el archivo Chapter one con solo mensaje de saludo. Ahora cambiamos algo en nuestro código local, luego nuevamente necesitamos agregar esos cambios a nuestra área de puesta en escena porque para comprometer nuestro código en el historial de Git, necesitamos pasar nuestro código desde el área de puesta en escena. Aquí, podemos volver a escribir Git add Chapter one dot TXT. Si volvemos a verificar nuestro estado, entonces no obtenemos ninguna modificación pendiente. Así es como agregamos nuestro código en el área de puesta en escena. Además, quiero decirte si te gusta crear nodos, entonces puedes comenzar a crear tus nodos para comandos de puerta. También agregaré mis nodos, pero también puedes usar tus propios nodos. 12. Comprometámonos con tu primer archivo: Actualmente, tenemos nuestros archivos en el área de puesta en escena. Ahora vamos a comprometer nuestro archivo con el historial de it. Entonces en Git Bash, lo escribimos commit. Aquí podemos escribir para mensaje, y en códigos dobles, agregamos nuestro mensaje Commit. Digamos Commit inicial. Ahora aquí escribimos especie descripción de nuestro abrigo. Pero a veces queremos agregar más líneas de descripción. Por ejemplo, arreglamos el burg, luego podemos agregar en la descripción, qué era ese burg, y no podemos explicar eso en una sola línea. Para agregar múltiples líneas de descripción, escribimos aquí solo obtener abrigo. Y dale a Enter. Esto abrirá un editor de código predeterminado que agregamos en nuestra configuración. ¿Te acuerdas? Genial. Ahora aquí en la primera línea, tenemos que introducir nuestra breve descripción y para una descripción larga, tenemos que escribirla en la nueva línea. Para este commit, añadimos mensaje corto como commit inicial para descripción larga, podemos escribir, completar el primer capítulo. Hacer alguna modificación en la historia. Solo estoy escribiendo un mensaje aleatorio para demo. No te preocupes. No voy a crear un libro de cuentos aquí. Ahora podría preguntarse, ¿qué pasa con estas líneas? Estas líneas son comunes para explicar esta parte de descripción, no te preocupes por eso. Ahora vamos a guardar este archivo y cerrar este archivo desde aquí. Ahora si volvemos a nuestro kit dash, mira aquí conseguimos un archivo cambiado y dos de inserción. Enhorabuena. Hemos hecho con éxito nuestra primera omisión. Para verificar esto, podemos escribir estadísticas del kit y ver aquí no obtenemos nada que comprometer. Árbol de trabajo limpio, lo que simplemente significa que nuestro código de área de trabajo, código de área de ensayo y la instantánea en el repositorio de Git son todos iguales. Así es como cometemos nuestro código en git. Se puede ver que es muy sencillo y fácil. 13. Cuándo debes comprometerte: Ahora, muchos desarrolladores cometen un error al usar git. Si cambian algo en el área de trabajo, inmediatamente declaran el cambio al área de puesta en escena, lo cual es bueno, pero también comprometen todos esos pequeños cambios el repositorio git, lo cual es incorrecto. Y también, algunos desarrolladores cometen directamente grandes cambios en el repositorio git, y eso también está mal porque no queremos codificar durante cinco días y luego cometer código completo. No es la mejor manera. Podrías preguntar, ¿cuál es la mejor práctica para el abrigo? En primer lugar, quiero decirles que no se comprometan por cada cambio. Eso es inútil porque como sabemos, lo que sea que cometamos, se va a almacenar en la historia en la historia, si obtienes todos los pequeños cambios, entonces encontrar lo que quieres de la historia se volverá mucho difícil. El tamaño Camt no debe ser demasiado pequeño ni demasiado grande. Comprométete siempre cuando crees llegas a cierto estado que quieres grabar. Imagina que cometer código es como ciertos puntos de control que quieres hacer Si algo sale mal con tu implementación actual, entonces puedes ir al punto de control anterior y reiniciar tu implementación ¿Recuerdas el concepto de videojuego para puntos de control? A medida que completas con éxito algo duro, entonces obtienes el punto de control que asegurará tu juego Piensa así. Otra cosa es que cada commit debe representar un conjunto de cadenas lógicamente separado No mezcles las cosas. Ejemplo, estás resolviendo un error, y también encontraste algunas mejoras de estilo, entonces no tienes que comprometer ambos cambios en una sola commit. Puedes hacer dos commit por separado, uno para arreglar el bug XYZ y luego para mejorar los estilos de cartas. También, otra buena práctica para los comités, hay que escribir un mensaje de compromiso significativo porque por mensaje Commit, encontrará su punto de control en la historia Entonces estas son mis cintas para abrigo. Pero al final, eres el mejor juez de tus situaciones. No pienses en ello, no cometerás ningún error. Todos cometeremos algunos errores, pero podemos aprender de nuestros errores, ¿verdad? Intenta recordar estas cintas. Te ayudará en tu viaje de puerta. 14. Ejercicio para el compromiso: Ahora es el momento de poco ejercicio para controlar lo que hemos aprendido en lecciones anteriores Quiero que crees un nuevo archivo llamado capítulo dos punto TXT y escribas algo en ese archivo. Después de agregar texto, tienes que confirmar ese archivo en el repositorio kid. Sé que esto es bastante fácil y puedes completar este ejercicio, ir a por ello y luego ver la solución. Entonces espero que completes este ejercicio o al menos intentes resolverlo. Ahora veamos la solución. Yo creo aquí un nuevo archivo Capítulo dos puntos TXT. Y aquí simplemente agrego Learning Git es una experiencia divertida. Si sabes cómo funciona git, ¿estás de acuerdo con eso? Házmelo saber. Guarda este archivo, y aquí volvemos a nuestro Git Bash, primero, que estado Vea aquí obtenemos un archivo sin seguimiento que es el capítulo dos punto TXT Tenemos que poner en primer lugar estos cambios, y luego podemos comprometernos con esto. Entonces escribimos Git add Chapter two dot TXT. Aquí, si no quieres escribir un nombre de archivo completo, entonces escribiendo medio nombre, puedes presionar la tecla Tab, y devolverá nombres de archivo sin seguimiento o modificados Ese es un pequeño truco. Después de eso, simplemente nos comprometemos con Git, completamos el Capítulo dos y presionamos Enter. Mira aquí hacemos otro commit, para que veas lo simple y fácil que es cometer código. 15. Cómo omitir el área de Staging: Ahora bien, la pregunta común que muchos tiene el usuario es, ¿ podemos saltarnos el área de puesta en escena? La respuesta es sí. Realmente no saltando el área de puesta en escena, pero como sabemos para confirmar el código, tenemos que usar estos dos comandos Pero en la marcha, tenemos otro comando, que es la combinación de estos dos comandos, pero esa no es una buena práctica Hazlo solo cuando estés 100% seguro de que no necesitas revisar tu código porque ese es el propósito del área de puesta en escena. Recuerda nuestro ejemplo de libro de cuentos, déjame mostrarte cómo podemos saltarnos el área de puesta en escena En primer lugar, permítanme cambiar algo en el archivo del Capítulo Uno. Empecemos el Capítulo uno. Guarda los cambios, y vuelve a Git Bash. Vamos a verificar el estado. Ver, obtenemos un archivo modificado. Ahora para cometer estos cambios, como sabemos, tenemos que escribir dos comandos. Primero, tenemos que escatimar el archivo, y luego agregamos Commit. Pero aquí podemos escribir directamente Gate commit A, que es para todos los cambios modificados y luego para mensaje. O simplemente podemos hacerlo juntos por AM y después de eso, podemos escribir nuestro mensaje de compromiso, partir del Capítulo uno. Y dale a Enter. Ver que está comprometido con éxito con la puerta. Verifiquemos eso con git status. Verás, no tenemos nada que comprometer. Este comando también agregará todas nuestras modificaciones en el área de puesta en escena y también comprometerá ese código en el repositorio git. Pero como te dije, solo usa este comando si estás 100% seguro. 99% de tiempo, primero montamos nuestro código y luego lo comprometiremos a la puerta. 16. Eliminar archivos de áreas: Ahora, supongamos que en este punto descubrimos que no necesitamos el Capítulo dos, o queremos eliminar el archivo del Capítulo dos. Del código VS, elimino este archivo. Bueno. Ahora, vamos a verificar nuestro estado. Obtener estado. Ver, aquí podemos ver que nos borran archivo del Capítulo dos porque eliminamos nuestro archivo del directorio de trabajo, pero aún así ese archivo está disponible en el área de puesta en escena. Déjame mostrarte. Entonces aquí escribimos archivos de Gates. Este comando devolverá todos los archivos que están disponibles en el área de espera. Verás, obtenemos el capítulo uno y el capítulo dos. Ahora, como les dije, cada vez que hacemos algunos cambios, tenemos que agregar esos cambios en el área de puesta en escena con comando add. Entonces aquí escribimos Puerta, agregamos el Capítulo dos para agregar los cambios, o podemos decir eliminación del archivo del Capítulo dos. Ahora vamos a revisar los archivos del área de espera una vez más. Obtener archivos S. Aquí S significa lista. Ver, aquí obtenemos sólo el capítulo uno archivo. Ahora vamos a verificar nuestro estado usando el estado de Git. Ver, aquí nos preparamos para comprometernos. Podemos escribir cometa Git para mensaje, eliminar Capítulo dos. Y hecho. Eliminamos con éxito nuestro archivo del Capítulo dos de nuestra área local y área de espera ambos. Sea lo que sea que hagamos, crear un nuevo archivo o eliminar el archivo existente, primero tenemos que agregar esos cambios al área de espera, y luego podemos comprometernos. Tan simple como eso. Ahora podrías preguntar, hay algún atajo o eliminar nuestro archivo del área de trabajo y área de espera y ustedes corrigen? Sí, hay un comando que realiza estos dos pasos en un solo paso. Podemos escribir obtener RM RM significa eliminar. Y aquí agregamos nuestro nombre de archivo, digamos capítulo dos punto TXT. Además, podemos agregar aquí múltiples nombres de archivo y también podemos eliminar todos los archivos por punto estrella TXT, lo que significa eliminar todos los archivos con extensión TXT. Mediante el uso de este comando, podemos eliminar nuestro archivo tanto del área local como del área de espera. 17. Cómo ignorar archivos en git [GitIgnore]: Ahora, a veces en nuestro proyecto, tenemos una carpeta o archivo que acabamos de crear para nuestro uso. No queremos poner eso en el repositorio de Git. Por ejemplo, si estás usando paquetes de nodos, obtienes una carpeta de módulos de nodo con miles de archivos, por lo que no queremos agregarla en nuestro repositorio Git. Aumentará el tamaño de nuestro repositorio sin ningún valor. Otro ejemplo son los archivos temporales o archivos de registro que no son necesarios para agregar repositorio git. Déjame contarte una historia de mi amigo, yo y mi amigo trabajando en una empresa corporativa. Mi amiga, Harley, no sabía nada de Gate. Él solo Githd y Git se comprometen. Un día, comprometió su archivo de contraseña personal con el código. Todos los miembros del equipo vienen a su escritorio y le cuentan su contraseña y no sabe cómo todos los miembros del equipo conocen su contraseña. En ese momento, tenemos que ignorar ese archivo o también podemos ignorar toda la carpeta. Déjame mostrarte eso prácticamente. Aquí en nuestra carpeta de seguimiento de tareas, creamos una nueva carpeta llamada logs para almacenar registros de depuración o aplicaciones Aquí agregamos nuevo archivo llamado debug dot log en este archivo, añadimos algo de texto. Esto es registro de depuración Guardar los cambios. Aquí, si prestas poca atención, cuando creamos un nuevo archivo en nuestra carpeta, nuestro archivo o carpeta resaltada con el color verde en la esquina derecha del nombre del archivo, obtenemos el icono U. ¿Puedes adivinar cuál es el significado de esta U? ¿Escribir? U significa archivo sin seguimiento Básicamente, VSC diciéndonos que este archivo no está disponible en el área de espera No te preocupes por eso. Te voy a explicar todo esto en las próximas lecciones. Ahora volvamos a nuestro Gitbsh aquí si hacemos git status, entonces obtenemos archivos sin seguimiento Si escribimos aquí Git add, entonces esta carpeta de registro también se agregará en nuestra área de ensayo y no queremos eso. Entonces, ¿cómo podemos ignorar estos archivos? Muy sencillo. Apenas en nuestro proyecto, creamos un nuevo archivo llamado dot Git Ignore. Asegúrese de escribir el mismo nombre de archivo punto Git Ignorar también este archivo debería en nuestro directorio raíz del proyecto. En cualquier otra carpeta. Sólo entonces funcionará. Básicamente, este archivo Get ignore le dice Git qué archivos o carpeta queremos ignorar. Aquí, queremos ignorar la carpeta de registros completos. Escribimos logs slash. Si queremos ignorar la carpeta de módulos de nodo, entonces escribimos módulos de subrayado de nodo o si queremos ignorar un archivo específico, entonces también podemos escribir logs slash debug dot Aquí podemos hacer cualquier cosa. Ahora en el momento en que guardemos este archivo, podemos ver que el icono U se ha ido de nuestro archivo de registros. También nuestra carpeta y nombre de archivo está en el color gris, lo que significa que se ignoran todos los archivos en la carpeta de registros. Déjame mostrarte una vez más. Elimino estas líneas y la guardo. Ver aquí conseguimos U. Y si añadimos de nuevo logs slash y lo guardamos, entonces ignoramos estos archivos Verifiquemos estos con su estado y veamos, obtenemos solo uno en la pila de pista, que es Gino, que acabamos de crear Vamos a agregarlo con Git add dot gitignore y luego Git co ignore todos los archivos de registro, y Encantadora. Así es como podemos ignorar archivos en Git. Pero recuerda, de esta manera, solo podemos ignorar ese archivo o carpeta, que aún no están comprometidos. En palabras simples, si queremos ignorar nuestro archivo TXT de un punto del capítulo uno ahora, entonces no podemos simplemente hacer eso con el archivo Git Ignore porque nuestro archivo Chapter one ya está comprometido en el repositorio git. Entonces primero, tenemos que eliminar nuestro archivo del área de espera, y luego podemos ignorar este archivo. Déjame mostrarte ¿cómo podemos hacer eso? Aquí en nuestra carpeta de proyectos, creo una nueva carpeta llamada, digamos, Ben. Y dentro de esta carpeta, creamos un nuevo archivo llamado backup dot Ben. No te preocupes por estos nombres de archivo. Es sólo para demo. Aquí agregamos texto como hola. Guarde esto y vea. Aquí obtenemos el icono de archivo sin seguimiento. Ahora permítanme cometer accidentalmente este archivo. Entonces en nuestro Git Bash, escribo Git add period, lo que significa que todos los archivos y luego Git commit testing But Bin file y lo cometemos Ahora nuestro expediente ya está comprometido. Intentemos ignorar este archivo. Déjame mostrarte qué archivos están en el área de puesta en escena por git As files. Ver aquí podemos ver el archivo de Bup Bin ya está aquí. Entonces, ¿cómo podemos eliminar este archivo del área de espera? En la lección anterior, vimos Git RM para eliminar y agregamos nuestro nombre de archivo, digamos, sido slash backup dot Ben Pero al usar este comando, elimina este archivo del área de espera, pero también del área local. Pero aquí, queremos este archivo en local o en nuestra área de trabajo. Entonces, para obtener ayuda, escribimos H para obtener ayuda. Aquí podemos ver que tenemos opción dash dash cast, que solo eliminará del índice. Índice significa área de estadificación. Escribimos Git, RM, dacast y también tenemos que agregar aquí R para la eliminación recursiva porque queremos eliminar todos los archivos del directorio bin Si no escribimos aquí R, entonces obtenemos error. Y agregamos el directorio de Bin y nuestra carpeta Bin se elimina del área de espera. Comprobemos también nuestras pilas de área de espera con él Como archivos. Ver, archivo Bin se elimina de aquí y vamos a comprobar nuestro estado, él estado aquí obtenemos un archivo eliminado, pero también obtenemos archivo de seguimiento de Bin. Aquí, tenemos que añadir el directorio Ben en nuestro punto Getting nor file. Guarde esto y vea, aquí obtenemos leer el icono, lo que significa eliminado. Volvamos a verificar el estado. Ver, aquí obtenemos un archivo eliminado y además obtenemos ti no archivo modificado porque agregamos directorio bin en nuestro GTI ni archivo Vamos a confirmar estos cambios y a confirmar, eliminar el directorio bin que accidentalmente cometió. Ahora déjame modificar algo en el archivo Bin. Guarde esto y vea que no obtenemos ningún mensaje de modificación, pero el archivo gitignore permanece Me puedes decir por qué? ¿ Comprobemos esto con estatus? Ver, aquí obtenemos archivo gitignore modificado porque olvidamos agregar nuestro getI no hay cambios No te preocupes, me pasa muchas veces. Así que aquí simplemente escenificamos los cambios usando Git add period. Y luego Git se compromete ignorando el directorio win y hecho. Para que puedas ver lo difícil que es ignorar los archivos ya comprometidos. Entonces la mejor práctica para Git es, agregaremos el archivo Git Ignore desde el principio. Así que dirígete a github.com slash GitHub, slash Aquí obtenemos todas las plantillas para el Getting no files. Por ejemplo, si estás trabajando con la aplicación react, entonces puedes buscar aquí nodo. Y aquí obtenemos una plantilla para todas las aplicaciones que utilizan nodo. Simplemente copia esta plantilla y pegarla en tu archivo de nervio de Gating. Tan simple como eso. 18. Visualización de cambios entre áreas: Ahora, déjeme hacerle una pregunta. ¿Cómo podemos ver los cambios que hacemos con él? Se podría decir que podemos usar el comando Git status, y tienes razón. Pero este comando sólo devolverá el nombre del archivo. ¿Y si queremos ver qué cambiamos dentro de nuestro archivo? Déjame mostrarte. En nuestro archivo del Capítulo uno, elimino estas tres líneas y agrego aquí, este es el inicio de nuestra historia. Guarde este archivo y lleguemos aquí para su modificación. Ahora déjame mostrarte cómo puedes usar otro comando it, que es itivo para diferenciar Ver, esto se ve muy complejo para ver los intercambios en la terminal. Y si estás viendo esta primera vez, entonces puedes romper tu pantalla. Pero déjame tratar de explicarte. Aquí podemos verlo diferenciar entre A Chapter one file y B Chapter one file, lo que significa que está comparando mismo archivo con una versión diferente. Después de eso, tenemos índice y algunos metadatos, lo cual es realmente no importa para nosotros. Después de eso, obtenemos estas dos líneas, los cambios en el primer archivo indican con el signo menos y los cambios en el segundo archivo indican con más. No te preocupes por esto. Básicamente, está mostrando que eliminamos estas tres líneas rojas y agregamos esta línea verde. Tan simple como eso. Ahora, como les dije, ver los cambios en la terminal no es muy fácil. Déjame explicarte ¿cómo podemos usar nuestro editor de código para ver estos cambios? En primer lugar, tenemos que decirle a Kat, queremos usar código VS como herramienta TIF. Herramientas DIF significa diferenciar herramienta. Escribimos Kit, config dash global. Lo estamos configurando como global, así que no tenemos que configurarlo para cada proyecto. Después de eso, agrega la herramienta div dot y la configuramos al código VS. Con este comando, solo estamos dando nombre a nuestra herramienta DIV, que es VSCode No te preocupes, esta configuración es solo un proceso de tiempo. Ahora tenemos que decirle a Git cómo lanzar el código VS. Nuevamente escribimos la herramienta Git config Global DIV. Scode punto CMD. Códigos dobles. Ahora en mi máquina, agrego código como ruta de código VS, para poder ejecutarlo desde cualquier directorio. Si no lo agregas a tu camino, no te preocupes, te lo mostraré en solo un minuto. Aquí agregamos peso, que le dirá a nuestro terminal que espere. Y después de eso, usamos D, que es para diferenciar o comparar archivo, y luego tenemos dos argumentos más, que es dólar local con todo el espacio de letras mayúsculas dólar remoto. Estos son los marcadores de posición para la copia antigua y la nueva copia de nuestro archivo Ahora vamos a asegurarnos de que agregamos este comando en nuestra configuración o no. Así podemos ver todos nuestros ajustes de configuración por Git config, Global E, y golpear Enter. Aquí podemos ver toda nuestra configuración. Consulta aquí nuestro dólar local y dólar remoto no se agrega. Puedes agregarlos. Guarde este archivo, encierra este archivo de configuración de Git Ahora volvemos a Git Bash. Si queremos ver cambios en el código VS, en lugar de escribir Git Dev escribimos la herramienta Git DV. Esto comparará lo que tenemos en el directorio de trabajo y lo que tenemos en el área de puesta en escena. Y está pidiendo lanzar VSCode. Escribe sí e ingresa. Ver, aquí tenemos nuestro archivo del Capítulo uno. Ahora bien, si no entiendes los cambios en un solo archivo, podemos dividirlo en dos archivos. En la esquina derecha, tenemos tres puntos aquí, tenemos que D selacg la vista inline Si aún no obtienes archivos uno al lado del otro, entonces tienes que presionar Control más B o Comando más B para cerrar este panel del Explorador. Aquí, podemos ver claramente lo que hemos cambiado, que es que eliminamos estas tres líneas y agregamos esta línea verde. Este es nuestro antiguo código de etapa y hicimos cambios en este código local. Ahora, si en el futuro, quieres ver los cambios, entonces solo tienes que escribir la herramienta Git Div. Ahora podría preguntarse, ¿cómo podemos ver los cambios entre el código de área de ensayo y el código de compromiso? Cerramos esta vista comparativa y en nuestro tablero de Git, tenemos que simplemente escribir la herramienta Git Div, dash dash stage, y presionar enter. Aquí no conseguimos nada. ¿Me puedes decir por qué? Porque nuestro código de área de ensayo es el mismo que nuestro código de compromiso. Tenemos que escenificar nuestros nuevos cambios. Escribimos Git add dot. Ahora ejecutamos de nuevo la herramienta Git D. Escenario Dash Dash. Inicie vía código, escriba sí y vea, aquí obtenemos cambios entre área de etapa y el código Commit. Para resumir esta lección, si queremos ver los cambios entre nuestro código local y el código de etapa, entonces lo usamos la herramienta Diff, y si queremos ver los cambios entre stagecde y Commit code, entonces la usamos Di tool, dest Estás continuamente viendo este curso, entonces en mi sugerencia, tómate de diez a 15 minutos de descanso de tu pantalla. Escucha algo de música o pasa algún tiempo con tu familia. Cuida tus ojos y nos vemos en la siguiente lección. 19. Atajo para el estado: Ahora actualmente, si queremos ver el estado actual, entonces escribimos git status. Pero estos comandos devuelven estatus muy largo. Ahora hay otra forma de atajo para obtener el estado. Para ello, creamos un nuevo archivo, Chapter two dot TxD e ingresamos algún texto en él. También cambiamos algo en el archivo del Capítulo uno. Ahora volvamos a nuestro tablero de Git y en lugar de escribir git status, escribimos git status a para abreviar, y golpeamos Enter. Ver, aquí obtenemos poco estatus. Esto es mucho más fácil de ver. Ahora aquí obtenemos dos columnas, columna izquierda y columna derecha. Esta columna izquierda representa el área de espera y la segunda columna representa nuestro directorio de trabajo o área local. Actualmente, modificamos nuestro archivo del Capítulo uno en el área de puesta en escena y también en el área de trabajo. Por eso llegamos aquí tanto M, M para modificado. Déjame explicarte de manera sencilla. Nuestro archivo del Capítulo uno en el área de puesta en escena es diferente de lo que tenemos archivo del Capítulo uno en nuestro compromiso. Por eso llegamos primero. Y nuestro archivo de área de trabajo actual también se modifica a partir de lo que tenemos en nuestra área de puesta en escena. Por eso tenemos aquí también. Déjenme demostrarlo prácticamente. Aquí, escribimos Git add Chapter one dot TXT, si volvemos a escribir aquí, git status tiene, mira, aquí no obtenemos de la columna derecha, lo que significa que nuestro código de trabajo es el mismo que el código por etapas Y si nos comprometemos archivo uno, entonces esto también eliminará de aquí. Ahora podría preguntarse ¿por qué llegamos aquí doble signo de interrogación? Porque creamos un nuevo archivo. Por eso llegamos hasta aquí ambos interrogación. Agreguemos el archivo del Capítulo dos en el área de puesta en escena. Git add Capítulo dos TXT. Entonces volvemos a obtener estatus. C, aquí obtenemos A, lo que significa agregado. Así es como podemos ver rápidamente el estado. Si te gusta ver el estado completo, entonces puedes usar el estado de Git. Si te gusta este enfoque, entonces puedes usar este atajo. La elección es tuya, depende totalmente de ti. 20. Cómo ver el historial de confirmaciones: Ahora, actualmente, hemos comprometido código muchas veces. ¿Y si queremos ver todo lo que se compromete? Entonces para eso, aquí lo escribimos, registramos, y pulsamos Enter. Entonces aquí conseguimos todos los Camtes en orden de lechuga a la anterior Al principio, obtenemos nuestro último amit cada commit tiene su ID único que es auto generado por él Cuando queremos acceder a ese ácaro o queremos ver qué hay dentro ese amit entonces usando este ID único, podemos acceder a esa confirmación específica Ahora a continuación, obtenemos headpoint para dominar. Podría preguntarse qué es el punto de cabeza para dominar. No te preocupes por eso. Te explicaré sobre esto en las próximas secciones. Por ahora solo conoce este git master es un nombre de rama predeterminado. La sucursal es un área que creamos para nuestro propio uso y esta cabeza nos está diciendo que actualmente estamos trabajando en esta rama maestra. No te preocupes, te lo explicaré con mucho detalle en las próximas secciones. Ahora después de eso, obtenemos nombre del autor y aquí obtenemos el correo electrónico del autor. A medida que obtenemos fecha y hora en las que ocurre este compromiso. Aquí en la parte inferior, obtenemos aquí nuestro mensaje de compromiso. Al usar este mensaje de confirmación, sabemos lo que hay dentro de este compromiso, y por eso te digo escribas un mensaje de compromiso significativo, que tú y tu colega puedan entender. Ahora actualmente, solo obtenemos tres o cuatro detalles de commit porque estos commits se dividen en páginas. Si queremos ver otras páginas, entonces presione espacio. Ver, aquí obtenemos nuestros otros commits. Ahora para salir, solo necesitamos presionar Q. Ahora este comando log tiene opciones muy interesantes. Aquí podemos escribir Git log, dash dash one line. Esto devolverá la lista de Commit en una línea. Entonces aquí obtenemos su ID único, y solo nosotros obtenemos aquí una breve descripción o mensaje Commit. Tenemos otra opción, que es Git log dash dash one line, dass reverse Y mira, aquí obtenemos nuestra lista de commit en orden inverso, que es desde el primer commit hasta el último commit. Ahora el comando log es poderoso comando para el historial de navegación. Lo usaremos mucho en la próxima sección. De hecho, tenemos una sección completa para navegar por nuestro historial de códigos. Por ahora, vamos a marcar a lo básico. 21. Desfasando los archivos: Ahora actualmente, si verifico nuestro estado, entonces aquí nos modificamos para el archivo del Capítulo uno, y también agregamos nuevo archivo Capítulo dos. Ahora bien, como ya les dije antes, nunca debemos cometer dos tareas distintas en un solo commit. Entonces primero debemos comprometer nuestro archivo del Capítulo dos, y luego debemos comprometer nuestro archivo del Capítulo uno modificado. Para eso, aquí primero desmontamos el archivo del Capítulo uno. Entonces escribimos, obtenemos, restauramos das stage y aquí escribimos nuestro nombre de archivo, capítulo uno punto THD Aquí, también podemos escribir varios nombres de archivo, o podemos escribir patrón, o incluso podemos escribir punto, que desentrarán todos los cambios de nuestro código Por ahora, aquí, solo queremos descomponer el capítulo uno punto archivo THD Ahora bien, si revisamos de nuevo el estado aquí nos ponemos rojos, lo que significa que se modificó en el área local o de trabajo. Ahora bien, es importante que entiendas cómo funciona realmente este comando restore. El comando restore básicamente toma la copia del siguiente entorno. No te confundas. Déjame explicarte de manera sencilla. Así que cuando escribimos git restore stage, capítulo uno punto tHD básicamente, estás diciendo que queremos desarmar el capítulo uno archivo THD Git toma una copia del siguiente entorno. ¿Cuál es el siguiente ambiente después del ambiente escénico? Recuerda esa cifra. Commit es el siguiente entorno después del entorno de etapa. Así que simplemente toma copia de nuestro capítulo un archivo del último comando y simplemente agrega eso en el área de puesta en escena. Pero nuestra área de trabajo tiene eso cambios. Indirectamente, desmontamos nuestro archivo del Capítulo uno. Ahora bien, si te hago una pregunta, si ejecutamos este comando, Get restore stage Chapter two dot TXT. Entonces como te dije, este comando tomará la copia del siguiente entorno, que es el entorno Commit. Pero nuestro archivo del Capítulo dos no está disponible en el último commit porque acabamos de crear nuestro archivo del Capítulo dos, y es por eso que nunca comprometemos este archivo. Por lo que este comando eliminará nuestro archivo del Capítulo dos del área de puesta en escena. Verifiquemos estos estatus I. Ver, aquí obtenemos dos signos de interrogación, lo que significa que nuestro archivo es track. Entonces, para resumir rápidamente, si accidentalmente agregaste cambios al área de puesta en escena que no quieres incluir en el siguiente commit, entonces git restore d stage te ayuda a mover esos cambios nuevo a tu directorio de trabajo Y por eso, te está dando la oportunidad de volver a evaluar o hacer más modificaciones antes de comprometerlas. Así es como desmontamos nuestros archivos. 22. Descartar cambios en archivos locales: Ahora, a veces hacemos algunos cambios en nuestro directorio de trabajo, y queremos desechar esos cambios. En palabras simples, queremos restaurar nuestros archivos locales con los archivos de área escenificada Entonces aquí hemos modificado nuestro archivo del Capítulo uno. Supongamos que queremos deshacer estas modificaciones para que podamos restaurar este archivo local del Capítulo uno con nuestro archivo del capítulo uno del área de ensayo. Para eso, usamos el mismo comando que es Git restore. Y aquí escribimos nuestro nombre de archivo que es capítulo uno punto THD Ahora, anteriormente, escribimos comando, nos restauramos como por etapas, capítulo uno punto TXT, que toma una copia del siguiente entorno, que es commit Porque en este comando, mencionamos la etapa como nuestro entorno actual usando este guión como escenificado Ahora bien, si eliminamos staged de este comando, puedes adivinar cuál es el entorno actual Actualmente, estamos en el entorno laboral. Este comando tomará copia del siguiente entorno, y ¿cuál es el siguiente entorno? Tomará copia del entorno de puesta en escena. También podemos escribir este comando así. Obtener, restaurar múltiples archivos. También podemos restaurar todos los archivos con periodo. Nuestro archivo se restaura desde el área de estacionamiento. Podemos verificarlo por estado de Git. Ver, aquí obtenemos sólo archivo del Capítulo dos. Pero, ¿por qué Git no restaura este archivo? Simplemente porque Git no tiene su copia anterior en el área de puesta en escena. Git lo deja como está. Ahora podría preguntarse, ¿cómo podemos eliminar todos los archivos no rastreados? Para eso, tenemos que escribir comando de limpieza de puerta. Ver, aquí obtenemos un error. Nos está diciendo fuerza requerida, por lo que podemos escribir gate cleang para obtener ayuda rápida Aquí, podemos ver para forzar eliminar, tenemos que usar F y podemos limpiar todo el directorio. También usamos. Escribimos puerta limpia f, D. Asegúrese de que con este comando se eliminen todos los archivos sin escenificar de nuestra área de trabajo, y no podamos restaurar esos Así que asegúrate de qué pilas estás limpiando. Ahora, verifiquemos el estado. Mira, aquí no obtenemos nada, que significa que todos los archivos se restauran. 23. Restaurar a una versión anterior: Entonces ahora sabemos que una vez que comienza a rastrear cualquier archivo, almacena cada versión de ese archivo en la historia. Entonces si por error, nos equivocamos con nuestro archivo y también lo cometemos, entonces podemos restaurar nuestro archivo desde el historial de git Entonces para demostrar que, primero, eliminamos nuestro archivo Chapter one, y luego restauraremos ese archivo desde el repositorio Git. Entonces, ¿recuerdas qué comando usamos para eliminar el archivo del directorio de trabajo y también del área de puesta en escena? Correcto, usamos Git RM, capítulo uno punto TXT. Verifiquemos nuestro estado. Ver aquí en el área de puesta en escena, nos borran el archivo del Capítulo uno. Ahora, vamos a comprometer estos cambios. Entonces Gitt eliminar, Capítulo uno archivo para restaurar. También revisemos esto en el código VS. Ver, nuestro archivo del Capítulo uno se elimina. Ahora supongamos que queremos recuperar ese archivo. Así que vamos a restaurar este archivo desde el repositorio Git o el historial de Git. Revisemos nuestro historial con Gitlog one line. Aquí, queremos restaurar nuestro archivo del Capítulo uno del segundo último commit, lo cual hicimos. Entonces para eso, escribimos git restore H para obtener ayuda rápida. Aquí podemos ver después de Restaurar, podemos agregar múltiples opciones. Y después de eso, tenemos que mencionar nuestra fuente. Fuente básicamente significa commit, y después de eso, tenemos que mencionar nuestra ruta de archivo. Ahora déjame volver a revisar el historial, Git registra una línea. Ahora podemos escribir Git, fuente restaurada es igual a aquí escribimos nuestro ID de commit desde el que queremos restaurar. Escribimos aquí este ID de compromiso. Si queremos restaurar archivo desde otro historial de commit, entonces tenemos que escribir ese ID de commit y después de eso, escribimos nuestro nombre de archivo, capítulo uno punto TXT Ahora vamos a verificar el estado. Ver, aquí obtenemos archivo sin seguimiento y si lo comprobamos en el código VS, mira, aquí nuevamente obtenemos nuestro archivo del Capítulo uno Así es como restauramos el archivo desde el historial de commit. 24. Operaciones básicas de Git en código VS: Así que hasta ahora en esta sección, realizamos cada tarea con una línea de comandos, y espero que despeje tus dudas sobre las operaciones básicas de Git. Ahora en nuestro código VS, también podemos realizar algunas operaciones básicas para Git. Entonces aquí vamos al panel de control de fuente, y aquí obtenemos este tipo de interfaz. En esta lista de cambios, obtenemos la lista de cambios. Aquí, obtenemos los mismos resultados que obtenemos del comando git status. Aquí tenemos un cambio, que es en este Capítulo un archivo. Si hacemos clic en este archivo, aquí podemos comparar nuestro código actual con el código anterior. Además, podemos ver aquí este archivo es un nuevo archivo sin seguimiento. Ahora para escenificar este archivo, podemos hacerlo muy fácilmente. Solo tenemos que hacer clic en este botón más. Ver, aquí tenemos cambios de etapa. También podemos desempañar este archivo muy fácilmente. Simplemente haga clic en este botón menos. Ahora tenemos cambios locales en nuestro directorio de trabajo. Vamos a escenificar estos cambios. Ahora podrías preguntar, ¿ podemos comprometernos desde el código VS? Y la respuesta es sí. Entonces aquí escribimos nuestro mensaje de compromiso. Vamos a agregar de nuevo, Capítulo uno archivo del código VS. Ahora vamos a hacer clic en este Commit, y nos comprometemos con éxito este código. Ahora déjame mostrarte algo realmente genial. Vayamos al panel del explorador, y de este fondo, aquí tenemos la línea de tiempo. Déjame acercarme un poco. Vea aquí obtenemos el historial de nuestro archivo abierto actual. Aquí obtenemos todos los cambios que hemos realizado en nuestro código. Si queremos ver el historial del kit, entonces usamos aquí esta opción de filtro. Simplemente elimine el cheque de la historia local y aquí obtenemos el historial de este archivo actualmente abierto, que es el Capítulo uno. Podemos verlo dando click sobre él. Así es como podemos usar nuestro código VS para operaciones simples. Ahora podría preguntarse, ¿por qué no le muestro esta forma de hacer las operaciones básicas? ¿Por qué enseño línea de comandos? Solo imagina si te muestro directamente esta lección sin explicar todos los comandos anteriores, entonces definitivamente te confundirás mucho y nunca entenderás lo básico de git. Por eso primero te enseño la línea de comandos. Ahora definitivamente sabes lo que estás haciendo en tu panel de control de fuentes. 25. Introducción a Github Desktop: Ahora, déjame mostrarte la interfaz gráfica de usuario de usar Git, que es Github Dktop Esta es una de las mejores y amigables herramientas GI para principiantes para usar Git. Otra herramienta popular es Git Kraken, pero es poco compleja para principiantes. Entonces en este curso, aprenderemos Github desktop, que es amigable para principiantes y además te mostraré Git Kraken, que es mi recomendación Así que dirígete a desktop.github.com y descarga la aplicación Github Dktop e instálala Aquí cómo se ve cuando abrimos por primera vez esta aplicación. Es pedir iniciar sesión con cuenta de Github, o si no tienes cuenta de Gitub, entonces puedes crear una nueva cuenta gratis Ya tengo cuenta de Github, así que rápidamente me conecto con eso. Aquí está pidiendo mi nombre y correo electrónico. Asegúrate de verificar estos detalles. Ver aquí puedo cambiar mi correo electrónico también y confirmar. Ahora aquí, podemos crear un nuevo repositorio Git y también podemos abrir el repositorio Git, y también podemos clonar el repositorio existente. Por ahora, no te preocupes por la clonación. Eso lo veremos en la próxima sección. Así que aquí abrimos repositorio Git. Vamos a la carpeta del proyecto y seleccionamos nuestro proyecto de seguimiento de tareas. Ver, aquí obtenemos este tipo de interfaz. Si cambiamos algo en nuestro archivo, agreguemos algo de texto. Estoy escribiendo este Capítulo uno para introducción. Y guardar los cambios. Ahora bien, si cambiamos algo en nuestro archivo en nuestra aplicación de escritorio Github, aquí obtenemos esos cambios. Desde este icono de configuración, podemos seleccionar el tipo de división. Ahora bien, aquí hay una cosa sobre esta aplicación. Esta aplicación comprometerá directamente nuestro código. Si no queremos confirmar este archivo, entonces podemos desmarcar este archivo de esta lista Esta lista es área de puesta en escena. Bien. Ahora veamos cómo comprometer nuestro código a Git. Entonces aquí escribimos nuestra descripción de tipo. puede ver por defecto, se muestra Commit messagon podemos escribir Update Chapter one para degustación Github desktop Y si queremos escribir una descripción incorrecta, entonces también podemos escribirla aquí. Y después de eso por amit simplemente damos clic en este Kammit a nuestra sucursal que es maestra. Y ya está hecho. Comprometimos con éxito nuestro código. Ahora también podemos ver la historia de nuestras amidas desde esta pestaña. Aquí, obtenemos la lista de todas nuestras amidas. Al seleccionar cada medio, podemos ver el contenido de su archivo. Para que puedas ver la aplicación de escritorio iTu hace que Git sea tan simple. Si te gusta usar la línea de comandos o el código VS, o te gusta el escritorio iTB, todo está bien Pero como ves con la línea de comandos, podemos controlar más en Git. Podemos hacer variedad de tareas mediante comandos de kit. Honestamente, me gusta usar comandos kit y código VS, pero la elección es tuya. Puedes elegir herramienta en la que te sientas seguro. Depende totalmente de ti. 26. Introducción a GitKraken: Entonces, en la lección anterior, vemos nuestra primera herramienta GI, GitHub Desktop. Tenemos otra herramienta que es el kit Kraken, que es poco complejo, pero una vez que entiendas y estés familiarizado con el kit, entonces usarás más esta herramienta Además, Kit Kraken tiene más funciones que la aplicación de escritorio GitHub Personalmente me gusta usar Kit Kraken. Verás el motivo en próximas secciones. También instalemos TKraCon en nuestro sistema. Dirígete a kitcracon.com, y aquí tenemos un Simplemente haga clic en eso y comenzará Descargar. Después de completar la descarga, abrimos una configuración y podemos instalar fácilmente Git Kraken Ahora cuando abrimos Git Kraken por primera vez, aquí obtenemos vamos a abrir una opción de repositorio y podemos iniciar sesión usando Github Por ahora, abramos un repositorio. Ver, automáticamente fez los detalles de mi cuenta de Git porque acabo iniciar sesión en la lección de escritorio anterior de Github Para que pueda filmar esto. Aquí obtenemos este tipo de interfaz. Podemos abrir el repositorio o podemos clonar repositorio desde Internet, o podemos crear un nuevo repositorio. Actualmente, queremos abrir repositorio desde local, así que vamos al repositorio abierto y abrimos nuestro proyecto actual. Mira así es como se ve nuestro repositorio. Esto es un poco complejo para los principiantes porque esto está muy desordenado Siento lo mismo cuando uso Git kraken por primera vez. Pero créeme, a medida que nos familiarizamos con Git, todo esto hace súper fácil. Aquí están todos los cometas y podemos ver más detalles sobre esa Camt seleccionándolos y en el lado derecho, obtenemos los Ver aquí obtenemos ID de confirmación, mensaje de confirmación. Después de eso, obtenemos detalles sobre el autor que compromete esta fecha y hora y por debajo de eso, obtenemos una lista de archivos que eliminamos, agregamos o modificamos. Básicamente, obtenemos los cambios que hicimos en este commit. Aquí, podemos abreviar estos archivos y también podemos ver los archivos en estructura de carpetas de árbol. Cuando hacemos clic en ese archivo, vea, aquí obtenemos el archivo y podemos ver este archivo en el modo split usando este icono. Por ahora, eso es todo sobre eso Kraken. No te preocupes. Veremos a Git Kraken más detalles en las próximas secciones Nos vemos en la siguiente sección. 27. Sección 03 Observa el historial del código: Bienvenido a la tercera sección del curso ultimate it. En esta sección, veremos cómo podemos navegar por nuestra historia de Cami con más detalle Primero, veremos cómo podemos ver todos los commits, filtrar los commits por nombres de autor, fechas, mensaje de commit. Además, veremos ¿cómo podemos establecer comandos de acceso directo para comandos largos? A continuación, veremos amidas específicas, compararemos dos amidas, volveremos al commit específico, detectaremos bug commit, culpas, dando etiqueta al gummit y muchas más cosas Sé que estás emocionado, así que comencemos esta sección. 28. Proyecto local de clonación: Ahora para navegar por el historial, necesitamos un proyecto en el que tengamos pocos commits. Entonces, debajo de este video, obtienes la carpeta de recursos, y en esa carpeta, agregué el proyecto de seguimiento de tareas que creé en SDML y CSS Déjame mostrarte cómo puedes clonar cualquier proyecto Git existente en tu máquina. Así que juego de palabras carpeta de recursos, y aquí tenemos curso Tarea pista Zip Podemos descomprimir esto simplemente podemos copiar esta carpeta desde aquí y pegarla en la carpeta de nuestro proyecto Ahora podemos empezar a utilizar este proyecto. Tan simple como eso. 29. Explora el comando Log en detalle: En primer lugar, abramos nuestro proyecto en Git Bash. En la sección anterior vimos para ver la historia de nuestro proyecto Git, usamos el comando Git clock. Este comando nos dará todos los detalles de commit sobre cada commit como Commit tiene detalles del autor, fecha y hora, y mensaje de commit. Además, conseguimos estos commits en orden, lo que significa que primero obtenemos el último commit y al final, obtenemos nuestro primer commit. Tenemos más de una página, entonces podemos presionar espacio o podemos movernos hacia arriba y hacia abajo usando las teclas de flecha. Para salir de este comando, presionamos Q. Ahora bien, ¿recuerdas por qué comando obtenemos este registro con menos detalles? Correcto, podemos escribir aquí Git log dash una línea. Ver aquí obtenemos solo poco tiene y cometemos mensaje. Ya hemos visto estos dos comandos. Ahora veamos este comando log con más detalles. ¿Y si queremos que los archivos cambien en cada comando? Por ejemplo, en el segundo comando, qué archivos se modifican o qué cambiamos en el último comando? Para ello, tenemos que simplemente escribir datat al final de nuestro comando log Este tat significa estadística. Mira, aquí obtenemos un archivo cambiado y lo conseguimos cambiado por nombre aquí. Después de eso, podemos ver 16 inserción. De igual manera, tenemos estos detalles para cada cometa. Ahora bien, si te confundes por muchos detalles, entonces también puedes hacer esto. Agrega aquí una línea y mira aquí obtenemos un poco menos detalles sobre Comet. Aquí solo obtenemos qué archivo cambia y el número de líneas que cambiamos. Pero, ¿y si necesitamos ver qué línea agregamos o eliminamos o actualizamos? No te preocupes, es realmente sencillo. Escribimos puerta, registro, una línea, Despatch. Mira aquí obtenemos las líneas en verde, que agregamos en el archivo. Y si quitamos algo de este archivo, entonces obtenemos esas líneas en rojo. Por estos comandos, podemos ver lo que pasó en nuestro proyecto muy rápidamente. Ahora para dejar esto, tenemos que golpear el espacio varias veces, y cuando lleguemos y presionamos Q. 30. Filtrar el historial: Ahora veamos cómo podemos filtrar nuestro historial de Commit y solo obtener los detalles específicos que queremos ver. Es lo mismo que filtramos productos en Amazon. Y además, también es súper divertido de hacer. Déjame mostrarte. Entonces primero, vemos cómo podemos filtrar nuestros amites usando nombre de autor Entonces aquí escribimos puerta, registro, una línea, autor es igual a aquí escribimos nuestro nombre de autor. Si el nombre del autor tiene espacio en su nombre, entonces tienes que envolver ese nombre en los códigos dobles. De lo contrario, se confunde. Aquí, este nombre de autor es tan sensible, hay que escribir exactamente el mismo nombre. Y si quieres ignorar sensible, entonces al final, simplemente escribe yo y consigue ignorar sensible. Mira aquí conseguimos gametos hechos por nombre Mt Patel. ¿Cómo podemos filtrar más estos ácaros? Correcto, podemos filtrar amidas usando fechas. Entonces Git log, dash one line, dash dash B four equals to here, tenemos que escribir nuestra fecha en códigos dobles como este. 2024 nuestro mes 01-30. Ver, aquí obtenemos todas las amidas antes de esta fecha. Ahora a veces cuando trabajamos en grandes proyectos, nos gusta ver Camids que se comprometieron después de una fecha específica Entonces tenemos aquí después, y aquí pasamos nuestra fecha en el mismo formato. También podemos pasar cuerdas como ayer, dos días, hace una semana, hace un año, etcétera Esto es muy útil. Yo uso mucho esto por qué me tomo uno o dos días de licencia. Ahora a veces queremos filtrar desde nuestro mensaje de compromiso. Por ejemplo, así solo aquellos commits, que tiene word task en el mensaje de commit. Lo escribimos, registro, guión una línea, guión agarrar es igual a en códigos dobles, escribimos tarea. Esto también distingue entre mayúsculas y minúsculas, así que asegúrate de escribir la palabra adecuada. Ver, aquí obtenemos kmtes que mensaje de commit tiene esta palabra de tarea, y por ignorar la sensibilidad entre mayúsculas y minúsculas, lo que agregaremos escribir, agregamos aquí I. C, aquí obtenemos kmtes que tiene palabra tarea en el Ahora a veces queremos encontrar un commit específico que agregue o elimine la función o variable. Por ejemplo, estamos trabajando en el proyecto Todos, queremos saber cuándo agregamos función Agregar todos o cuándo la eliminamos. Para que podamos hacer algo como esto. Git log, guión una línea, mayúsculas aquí en códigos dobles, tenemos que escribir nuestro nombre de función, addTDS Actualmente, en este proyecto, no tenemos esta función. Entonces busco aquí. Ver, aquí obtenemos los commits. Ahora imagina a veces queremos ver sólo los últimos tres cometas o cinco cometas. Entonces podemos escribir git log, dash una línea, cinco. Mira, aquí tenemos los últimos cinco cometas. También, a veces necesitamos ver el historial de archivo específico. Por ejemplo, queremos ver índice punto STMLFlehtory, cuando este archivo Entonces podemos hacer algo así. Git log, guión una línea. Index dot html, y ver aquí podemos ver el historial. Ahora bien, si tu nombre de archivo ya está registrado en la biblioteca Git como tu registro de archivos, entonces aquí, puedes separar este comando y nombre de archivo usando doble guión Ver, aquí obtenemos el mismo resultado. Ahora, déjeme hacerle una pregunta. ¿Y si en este comando queremos ver los cambios dentro de este archivo? Derecha. Tenemos que escribir dash dash page, pero tenemos que escribir página antes este doble guión porque este doble guión separa el comando del nombre del archivo y vemos aquí obtenemos los cambios de archivo. 31. Establecer alias para comandos: Ahora, a veces tenemos que ejecutar varios comandos de Git que usamos con mucha frecuencia, pero son poco largos o son difíciles de recordar. Podemos establecer un atajo para esos comandos. Por ejemplo, frecuentemente ejecutamos este comando Git log dash one line. Vamos a establecer atajo o en términos git, establecer un lias.Ellas simplemente significa otro nombre Escribimos Git config dash global Alias, period. Aquí, tenemos que escribir nuestro nombre de acceso directo para este comando. Entonces escribimos lg para log. Asegúrate de usar nombres significativos porque al final del día, tienes que recordar los nombres de acceso directo, y después de eso, tenemos que escribir nuestro comando original, que es log una línea. Aquí, tenemos que envolver nuestro comando con códigos dobles porque tenemos espacio en el medio y golpeamos Enter. Ahora, verifiquemos que lo configuramos correctamente o no. Entonces lo escribimos configs global E, y abrirá nuestro archivo Config en nuestro editor de código predeterminado Ver, al final, obtenemos nuestro Alias lg para registrar una línea. Quieres actualizar como o eliminar cualquier cosa, entonces puedes hacerlo desde aquí. Por ahora, no queremos cambiar nada, así que vamos a cerrar este archivo. Ahora, usemos nuestro alias. Escribe t lg, y mira aquí obtenemos la salida de nuestro comando, así es como podemos establecer como o atajos para ahorrar nuestro tiempo y memoria porque no necesitamos recordar todo el comando largo. Ahora para el resto de este curso, no uso este alias porque si alguien se une desde la mitad de este curso, entonces no van a entender cómo estoy usando alias. Pero definitivamente puedes usar eso para tu práctica. Depende totalmente de ti. 32. Consulta el compromiso específico en detalles: Hasta ahora hemos visto cómo podemos ver todos los commits. Pero a veces queremos ver los detalles específicos como el commit específico que tiene Bits Commit. Para eso, podemos escribir Git, show, y aquí escribimos nuestra referencia de commit. Consulta aquí obtenemos los detalles sobre este commit específico. Aquí podemos ver que solo tenemos un archivo cambiado y en la parte inferior, tenemos los cambios. Ahora bien, si queremos obtener el último commit reciente, entonces podemos escribir aquí, obtener como cabeza con todas las letras mayúsculas. Si queremos ir más abajo en la lista Commit sin escribir el commit entonces podemos escribir aquí hasta y podemos escribir aquí número, digamos dos. Entonces Git primero encuentra la cabeza y luego mueve dos escalones hacia abajo y danos detalles sobre este commit. Se puede ver que es muy fácil y sencillo. Ahora bien, si queremos ver el nombre del archivo que se cambian en nuestro commit específico, entonces aquí tenemos que escribir Git, show, head till two, name only. Ver, aquí tenemos sólo un archivo que cambia en esta commit. Ahora déjame darte una situación más. Y si queremos ver el contenido completo del archivo específico en commit específico. Entonces obtenemos nuestro comando anterior y simplemente agregamos aquí columna. Y aquí escribimos nuestra ruta de archivo como archivo punto TXT, o si tenemos carpeta, entonces podemos escribir Css detyle punto css Vea aquí obtenemos el contenido completo del archivo específico en nuestro último tercer comando. Así es como podemos ver el commit específico con más detalle. Ahora en la siguiente lección, veremos cómo podemos compararnos con los comandos. 33. Cómo comparar dos commits: Entonces, cuando necesitamos comparar A dos commits para ver qué agregó, eliminó o cambió en nuestro código. Entonces para eso, usaremos el comando Git di. Este comando nos dirá la diferencia entre nuestro directorio de trabajo y el último commit. Actualmente, no tenemos ninguna diferencia. Por eso no conseguimos nada. Aquí, también podemos comparar dos commits específicos. Digamos cabeza hasta dos cabezas espaciales. Aquí en ambos lugares, también podemos agregar referencia de commit. Ver, tiene múltiples archivos y múltiples cambios. Ahora bien, si queremos ver solo un archivo específico cambia entre estos commits, entonces ¿qué haremos? Simplemente, al final de este comando, agregamos nuestro nombre de archivo, estilo CSS punto CSS Ahora en la siguiente lección, veremos ¿cómo podemos restaurar nuestro código a la commit específica? 34. Volver a una versión específica: Ahora, a veces queremos restaurar nuestro código a uno de los mit específicos. Por ejemplo, esto omite. Queremos que nuestro código sea exactamente lo que cometamos en esta omisión. Entonces escribimos Git, echa un vistazo, y aquí agregamos nuestra referencia de omisión Mira, aquí cambiamos a este met. Pero aquí también recibimos esta advertencia, que nos está advirtiendo sobre el estado cabeza desapegada. Ahora muchos desarrolladores confundieron mucho sobre el estado, pero no es muy difícil. Déjame explicarte. Aquí tenemos nuestra estructura de compromiso. Estos son el número de cometas. Este es el primer commet y a la derecha, nos hemos visto por última vez Aquí podemos ver que todos estos commits están vinculados con su commit anterior. Ahora como podemos ver en nuestro Git Bash, actualmente, estamos en nuestra sucursal maestra Branch es el tema poco avanzado en git. Eso lo veremos en la próxima sección. Por ahora, solo entiende que la rama es como la línea que los desarrolladores crean para el trabajo de proyectos individuales. Al igual que si manager te da trabajar en un formulario de inicio de sesión, como desarrollador, creas una nueva sucursal para trabajar en el formulario de inicio de sesión. Master o main es una rama predeterminada en git. Aquí, este maestro es un referente que representa nuestro último kmt Ahora, cada vez que cometemos un nuevo código, este maestro se mueve al último kat. Ahora como sabemos en Git, podemos crear múltiples ramas. En ese caso, cómo git sabe actualmente en qué rama estamos trabajando. Para resolver esto, tenemos otra referencia llamada cabeza. Head señala la rama actual en la que estamos trabajando. Esto ya lo hemos visto antes. Ahora a medida que añadimos nuevos commits, este jefe y maestro también avanzará con nuestro último ácaro. Ahora cuando hacemos check out al commit específico, entonces nuestra referencia principal se mueve a ese commit. Y este es el estado cabeza desapegada. Idealmente, cuando estamos en el estado de cabeza desapegada, en ese momento, no deberíamos comprometer ahí un nuevo código. Si creamos un nuevo commit, entonces ese met se agregará aquí. Ahora, en algún momento, cuando movemos la cabeza hacia el maestro, entonces este cometa no puede acceder por ningún otro cometa Git declara este commit como dead commit, y después de algún tiempo, automáticamente eliminará este commit de su registro. Entonces es mejor no cometer el código cuando estamos en el estado de cabeza desapegada. Siempre podemos mirar nuestro código y experimentar con nuestro código. Ahora, como podemos ver aquí nuestro cambio de pase Git. Anteriormente, llegamos aquí maestro. Pero cuando comprobamos el comando específico, entonces aquí obtenemos el hash de commit de nuestro checkout commit. Ahora en el punto actual, si registramos todos nuestros comandos usando Git log one line, aquí, solo obtenemos cometas que están comprometidos antes de ese cometa específico Otros cometas son invisibles en este punto. No te preocupes, esos otros cometas no se eliminan. Simplemente es invisible. Además, nuestra referencia principal está aquí. Ahora, para ver esos cometas invisibles, tenemos que añadir aquí una variable más, que es todo Ver aquí obtenemos todos nuestros cometas y podemos ver nuestra referencia maestra está aquí y nuestra referencia principal está aquí Ahora para mover nuestra cabeza de nuevo a la referencia principal o maestra, podemos escribir aquí Gate, checkout master, y ver, nos movemos a master y vemos nuestro head point to master. Y ahora conseguimos todos los comads. De esta manera, podemos ver nuestro código anterior en nuestro editor de código o en el explorador de archivos. Y por eso es importante el comando checkout. 35. Detecta el commit con errores en Git Bisect: Ahora imagina si algo pasa en nuestro código y obtenemos nnn Berg en nuestra aplicación, entonces ¿cómo podemos identificar en qué bug de comando sucede Una solución es que podemos verificar todos estos comandos uno por uno usando el comando checkout, pero esto llevará mucho tiempo. En git, tenemos un comando para identificar rápidamente el comando bug, que es mediante el uso de Git by set. Para iniciar este proceso, tenemos que escribir puerta por conjunto, iniciar y golpear Enter. Aquí podemos ver que nuestro Gitbsh está en modo bisectriz. Ahora, después de iniciar el proceso de biseccion, tenemos que marcar primero nuestro commit actual como mal kommt Si quieres saber cuál es el ácaro activo actual, entonces podemos ver eso desde aquí, que es nuestro master commit. Aquí estamos marcando esto como mal abrigo porque nos encontramos con bichos en este abrigo. Git bisect mal. Además, si quieres marcar otro met como kit malo, entonces al final, tenemos que escribir su referencia de commit. Sé que esto es un poco confuso, pero en solo un minuto, entenderás esto. Ahora, después de eso, tenemos que decirle a la marcha, que es el último bien conocido que conocemos Por ejemplo, hasta que esto se cumplió, sabemos que nuestra aplicación no tiene ningún error. Entonces tenemos que hacer esto en tan bueno en. Entonces escribimos puerta, bisectamos bien, y aquí entramos en nuestra referencia Comite Ahora simplemente vamos a registrar nuestros cometas, mira, ahora nuestra cabeza se mueve a la mitad de nuestros cometas Ahora aquí está la parte lógica del comando bisec. Imagina que tenemos estos diez cometas. Marcamos nuestro último cometa como el cometa malo, y nuestro primer cometa es el En el momento en que establecemos nuestro primer amet como buen KumTo cabeza movernos al punto medio entre el bueno y Ahora, debido a que nuestra cabeza está en esto en, nuestro código de trabajo actual será reemplazado por este código amet Podemos consultar nuestra aplicación en este en. Si tenemos bicho en este abrigo, entonces marcaremos esto como malo. Si no tenemos bug en esto en, entonces marcaremos este comido como buen kamte Por ejemplo, encontramos que este amet no tiene ningún problema. Entonces marcaremos este met como bueno usando Git BSc good. Ahora como marcamos este comido como bueno, nuestra cabeza se mueve al punto medio entre nuestro kmt malo y el buen kat Ahora, nuevamente revisamos nuestro código. Si es bueno, entonces lo marcamos como un bien. Y si encontramos este kamete como malo, entonces lo marcamos como un mal cometa Este proceso continuará estrechando la lista, y en ese momento obtenemos el cometa que causa burg Esa es toda la idea del comando bisec. Entonces en nuestro commit, podemos verificar nuestro código en el código Vas y ver si tiene BG o no. Imagina que encontramos que esta confirmación tiene error. Entonces aquí marcamos obtener por sec malo. Ahora, nuevamente, revisaremos nuestra lista, veremos cómo se mueve a esta confirmación. Nuevamente revisamos nuestro código e imaginamos que este commit no tiene burg. Entonces lo haremos bueno usando Git Biseccd. Ver, aquí obtenemos este commit como el que agregó el burg en nuestra aplicación. Entonces así es como funciona el comando bisec. Puede parecer un poco confuso, pero si usas este comando una vez, luego de eso, lo entenderás tan fácilmente. Ahora aquí podemos ver que todavía estamos en el modo bisectriz. Para salir de este modo, tenemos que escribir get bisect reset y ver que estamos de vuelta a nuestro comando maestro Así es como podemos identificar errores en los metes sin verificar todos los metes en la fila 36. Obtener la lista de contribuidores: Ahora bien, si a veces queremos saber cuántos commits suceden por los usuarios para conocer la contribución. Entonces para eso, escribimos Git short log. Ver, aquí obtenemos el nombre de usuario y el número de commits por este usuario. Y también, obtenemos el resumen de los mensajes de commit. Aquí en este proyecto, soy el único colaborador. Entonces por eso está mostrando sólo mi nombre. Ahora incluso podemos modificar este comando usando más opciones. Aquí, lo escribimos log corto, H para ayuda rápida. Y mira aquí obtenemos todas las demás opciones. Por ejemplo, podemos escribir N o guión numérico para cortocircuitar la salida por número de commits realizados por cada usuario Ahora bien, si tenemos larga lista de commits, entonces para C cada colaborador, tenemos que desplazarnos. Después de este N, podemos escribir guión para ignorar el mensaje de commit de resumen. Ver aquí obtenemos solo el número de comas y el nombre de usuario. Ahora en la siguiente lección, veremos el historial del archivo. 37. Historial de navegación del archivo: Ahora ya hemos visto este comando antes. Solo lo estoy agregando aquí porque es la parte de navegar por la sección de historial. Entonces como sabemos, para ver el historial, podemos escribirlo, registrarlo, y para ver el historial del archivo en particular, podemos escribir el nombre del archivo que es índice punto HTML. Mira aquí obtenemos la lista de los cods en los que cambió este archivo Si queremos acotar esta lista, entonces podemos usar aquí guion variable una línea. Ver, ahora es legible. Ahora bien, ¿y si queremos que ocurran los cambios en este archivo? Podemos usar aquí datat para obtener la estadística, o podemos decir número de cambios en este archivo Ver, en el primer commit tenemos 150 cambios. De igual manera, tenemos 35 cambios aquí en los que 32 de inserción y tres de eliminación. Ahora bien, si queremos ver los cambios reales en el archivo, entonces lo que haremos justo en el lugar de este ds dat, escribimos despacho. Puedes ver que los comandos de Git no son difíciles. Es sólo cuestión de práctica, y confío en ti. Después de practicar este comando git en un proyecto, puedes usarlos en cualquier otro proyecto sin que te preocupes. 38. Consulta Autor de cada línea [Git Blame]: Ahora, a veces en nuestro archivo de proyecto, queremos saber quién es el autor de alguna línea en particular. Sucede en mi proyecto, un nuevo desarrollador se une a mi equipo y escribe un código muy malo. Si le pregunto a alguien que escriba este código, entonces nadie responderá, y ya sé quién escribe este código. Así que siempre le pido a ese desarrollador que compruebe quién escribe este código. No me estaba burlando de ese desarrollador al principio, todos estamos en ese nivel. No hay nada de malo en ello. Nadie se convierte en el perfecto al primer día de codificación. Es un viaje que lleva mucho tiempo. Volviendo a nuestro ejemplo de Git, si queremos conocer al autor de línea particular, entonces podemos escribir git culpa, y aquí escribimos nuestro nombre de archivo o ruta. Ver, aquí obtenemos todo el contenido del archivo línea por línea con los detalles. Aquí, primero llegamos a cometer referencia en la que regresa esta línea. Entonces obtenemos el autorame y también obtenemos la fecha y hora Ahora bien, si a veces nuestro archivo tiene muchas líneas y queremos saber solo una línea específica, entonces podemos escribir L aquí, y luego escribimos ese número de línea, el final del número de línea. Digamos que queremos ver sólo tres y cuatro. Entonces aquí escribimos 34. Si queremos ver la línea tres, cuatro y cinco, entonces escribimos 35. Mira aquí sólo conseguimos tres, cuatro, y quinta línea. Para que puedas usar el comando culpar para conocer al autor de cada línea. Ahora en la siguiente lección, veremos cómo podemos dar etiqueta para cometer. 39. Marcar compromisos con etiquetas: Ahora, imagina actualmente esta ayuda está lista para lanzarse en la producción, o queremos marcar este código de confirmación como la versión 1.0. Pero ya doy esto en la versión 1.0. Tengo que dar aquí la versión 1.0 0.1. Entonces para darle un nombre de versión al med se llama como dar etiquetas en Git. Marquemos este amet como la versión 1.0 0.1. Aquí escribimos git tag, versión 1.01. Aquí podemos escribir nuestra referencia de confirmación y aquí no agregamos ninguna referencia de confirmación, entonces por defecto, llegar a darle esta etiqueta a nuestra confirmación actual, que es la confirmación maestra. Ahora si registramos nuestros commits, mira, aquí obtenemos la versión 1.01 de la etiqueta después de esta referencia de commit Ahora bien, si queremos revisar nuestro código a esta confirmación, entonces no necesitamos escribir esta referencia de confirmación. Simplemente podemos usar Git, echa un vistazo a la versión 1.0. Igual que usamos este ID de confirmación, podemos usar esta etiqueta, versión 1.0. Ahora supongamos que quiero ver todas las etiquetas que le di a este proyecto. Entonces simplemente escribimos la etiqueta Git y vemos aquí obtenemos todas las etiquetas que asignamos. Ahora supongamos que agregamos esta etiqueta místicamente, y ahora queremos eliminar esta etiqueta Así que simplemente escribimos git tag D, escribimos nuestro nombre de etiqueta, que es la versión 1.01 Ahora podemos ver que la etiqueta se elimina de la lista. Aquí tenemos esta etiqueta versión 1.0, que llamamos como etiqueta ligera, lo que significa que le damos a nuestro amid solo una referencia como versión 1.0. Ahora en marcha, también hemos anotado etiqueta. Ahora podrías preguntar ¿qué son las etiquetas anotadas? Por lo tanto, la etiqueta anotada se usa para agregar más detalles como el nombre del etiquetador, fecha y la hora y el mensaje de confirmación En palabras simples, con etiquetas anotadas, simplemente podemos agregar más detalles con nuestras etiquetas Aquí está el comando para etiquetas anotadas. Escribimos la etiqueta de puerta A para la versión anotada 1.01 M, que significa mensaje Y en los códigos dobles, podemos ingresar nuestro mensaje como versión de lanzamiento 1.01 Conoce que este mensaje no es muy útil, pero solo te estoy mostrando si quieres agregar mensaje con esta etiqueta anotada, entonces puedes hacerlo de esta manera Ahora bien, si lo escribimos etiqueta, entonces obtenemos dos etiquetas. Si quieres ver mensaje de texto, entonces tenemos que escribir Git tag N. Ver, aquí obtenemos los mensajes de etiqueta. Si nuestra etiqueta es una etiqueta ligera, entonces obtenemos ese mensaje de confirmación como el mensaje de etiqueta. Así que no confundas con eso. Ahora si vemos nuestra versión 1.01 con ella Mostrar comando de la versión 1.01, entonces mira aquí en la parte superior, también obtenemos los detalles del tagger como nombre, correo electrónico, fecha y hora en que damos este mensaje de etiqueta y etiqueta Así es como usamos etiquetas para marcar versiones. 40. Historial de compromiso en Github Desktop: Entonces veamos la historia de nuestros CID en la aplicación Github Extra Así que vamos a abrir este proyecto de sección en la aplicación Github Extra. Ir al archivo, agregar Repositorio Local. Y aquí vemos el camino de nuestra carpeta. Y simplemente selecciona esa carpeta. En la lección anterior, vemos cómo ver los cambios en la aplicación de escritorio Github. Ahora veremos cómo navegamos por el historial de commit usando esta aplicación. Entonces aquí tenemos lista de commits en el lado izquierdo y también obtenemos aquí nuestro texto y aquí en la parte superior, obtenemos el mensaje de Commit, obtenemos el mensaje de Commit nombre del autor y la referencia de Commit. Ahora aquí obtenemos la lista de archivo cambiado. Si hacemos clic en ellos, entonces obtenemos los cambios aquí. Además, podemos cambiar nuestra visión desde esta configuración ahora aquí podemos ver que tenemos muy pocas opciones para navegar por nuestro historial de commits. Por ejemplo, no podemos filtrar nuestras commits, no podemos buscar una función o variable específica y muchas cosas extra. La aplicación de escritorio Github tiene una interfaz de usuario sencilla, pero no es la mejor para usar Git. Este es un artículo que me gusta. En ese artículo, veo que los desarrolladores están diciendo que solo les gusta la aplicación de escritorio Github cuando son principiantes de Git. Pero a medida que aprenden Git con más detalles, realmente no les gusta la aplicación de escritorio Github. Estoy un poco de acuerdo con eso, pero eso no significa que tengas que desinstalar la aplicación de escritorio Github. Puedes usar Github destra Publication si te encuentras cómodo. Depende totalmente de ti. 41. Historial de navegación en VS Code y GitKraken: Ahora veamos cómo podemos navegar por historial usando nuestro editor de código favorito VS code. Entonces como hemos visto en el apartado anterior, aquí podemos ver nuestros cambios en el código. Pero y si queremos ver la historia de nuestros mets y también la lista de cometas. Podemos verlo en el código VS, pero podemos verlo usando una extensión llamada Gitans Esta es una de las extensiones de Git más populares en VSCode, y la parte divertida es que esta extensión es de Git Usas Git Kraken en lugar de Github desktop, entonces verás la misma interfaz que vemos en esta extensión Mira aquí obtenemos dos opciones más en el lado izquierdo para git lens. Abre este primero déjame alejarme un poco, cerrar esto, también cerrar esto. Ahora en esto, tenemos muchas opciones. Ver, primero, tenemos gráfico Commit. Esta es una de las formas populares de ver omite la historia. Aquí, podemos ver, obtenemos una lista de nuestros commits y aquí también podemos obtener el texto que damos a los commits. A continuación, tenemos Commit message, nombre del autor, cambios en los archivos, tiempo y referencia de commit. En la parte superior, obtenemos también la barra de búsqueda para buscar a los cometas. Si buscamos aquí algo, entonces resaltará solo aquellos anuncios, que commit message tiene esta palabra. Ahora para más filtro de búsqueda, tenemos poco desplegable aquí. Primero, obtenemos mis cambios, que nos mostrarán sólo aquellos cometas que son cometidos por ustedes A continuación, tenemos mensaje para buscar el mensaje de commit. A continuación, tenemos autor por el cual podemos buscar commits por nombre de autor. Después de eso, tenemos commit SHA en el que podemos buscar commits por referencia de commit. A continuación, también podemos buscar en un archivo específico. Por ejemplo, escribimos aquí índice punto HTML. Ver, aquí obtenemos solo aquellos commits resaltados. Y por último, tenemos cambio por el cual podemos buscar funciones o variables. Ahora bien, si seleccionamos un comando en el lado derecho, podremos ver más detalles sobre este commit. En la parte superior, obtenemos la referencia de commit. Aquí, sacamos nuestro nombre, hora, y también cometemos mensaje. Ahora en la parte inferior, tenemos sección para archivo cambiado, y aquí obtenemos el número de archivos agregados, que es cero, número de archivos cambian, que es uno, y número de archivos eliminados, que es cero. Y debajo de eso, obtenemos la lista de archivos que se agregan, cambian o eliminan. Si seleccionamos ese archivo, entonces podremos ver la diferencia que hacemos en ese archivo. Muy útil. Ahora, después de las gráficas de commit, tenemos más opciones. Pero como podemos ver, hay muchas cosas que no podemos ver aquí, y por eso los comandos de Git son esenciales para aprender. Depende totalmente de ti lo que quieras aprender. En mi humilde opinión, aprender ambos es más beneficioso para ti. Déjame mostrarte cómo podemos navegar por historial usando la aplicación Git Kraken Abrimos nuestra carpeta de proyectos, que queremos abrir y simplemente haz clic derecho aquí y abrimos con Git Kraken Aquí está la interfaz de la aplicación Git Kraken. Es muy similar a la extensión de lente Git. Aquí obtenemos la lista de commits que hicimos en la parte superior, también tenemos opciones de búsqueda donde podemos buscar por mensaje de Commit. Aquí también podemos filtrar los commits por los autores. Ahora cuando seleccionamos el commit, obtenemos los detalles del commit en el lado derecho. Aquí, obtenemos la referencia de Commit, mensaje de commit, el autor, fecha y la hora, y los archivos modificados. Si seleccionamos Archivo, entonces obtenemos aquí los cambios. También podemos cambiar el tipo de vista a split. En la parte superior, también podemos culpar por ver al autor cometer. En el lado derecho, también tenemos estructura de carpetas de árbol, y también podemos ver todos nuestros archivos de proyectos. Para que puedas ver usándola aplicación Kraken, podemos navegar fácilmente por nuestro historial Usamos lente Git, entonces no obtenemos tanto espacio. Está muy congestionada. Así que usa lo que quieras usar, depende totalmente de ti. Ahora en la siguiente sección, veremos el tema más importante de git, que son las ramas, nos vemos en la siguiente sección. 42. Sección 04 Trabaja con ramas: Bienvenido a la cuarta sección del curso definitivo de Git. En esta sección vamos a aprender todo sobre ramas, cómo crear ramas, verlas, compararlas con ramas, cómo fusionarlas, resolver conflictos, y mucho, mucho más cosas. Este es uno de los temas más importantes de Git. Sé que estás entusiasmado con esto, así que comencemos esta sección. 43. Qué es la rama: Ahora, como sabemos, nuestro proyecto de seguimiento de tareas es el STMLNCSSPject, que creé Ahora imagina que estamos agregando nueva característica. Por ejemplo, arrastrar y robar característica en este proyecto. Entonces, en lugar de agregar esa característica en nuestra rama maestra, podemos crear una nueva rama. La rama Git es como una nueva línea en nuestros mets. Entonces, como sabemos cuando comprometemos nuestro código, obtenemos dar Master Pointer a nuestro último commit. Ahora que decidimos que queremos agregar nueva característica en nuestro proyecto, luego primero, creamos una nueva rama, digamos, función de arrastrar y soltar o función DND Ahora bien, esta sucursal tiene la misma instantánea de nuestro código. Aquí podemos comprometer nuestro nuevo código de función y cuando cometemos ese código no afectará a nuestro código maestro de sucursal. Podemos trabajar en nuestro código aislado. Ahora podrías preguntar por qué necesitamos crear sucursales. ¿Podemos incluso empujar nuestro código a la rama maestra? No, no podemos hacer eso porque si escribimos código, entonces no es el problema. Pero si nos equivocamos con nuestro código, entonces no queremos almacenar código descompuesto en nuestro historial de códigos Si creamos una sucursal y estropeamos nuestro código, entonces simplemente podemos eliminar esta sucursal por completo y no afectará a nuestra rama maestra Esa es la idea. Ahora podrías preguntarte, ¿cómo sabe Git en qué rama o abrigo estamos trabajando? Para eso, Git tiene otro puntero llamado head. Ya hemos visto ese puntero. Por defecto, nuestro puntero de cabeza es con puntero maestro o principal. Si trabajas en otra rama, entonces Git solo mueve el puntero de cabeza a esa rama commit. Así es como están funcionando las sucursales de Git. Por simplicidad, solo recuerda si vas a trabajar en algo diferente, entonces puedes trabajar en eso aislado creando ramas. En las grandes empresas, muchos equipos trabajan en diferentes sucursales, por lo que su código no causará problema con la rama maestra, y obtenemos un código estable en nuestra historia. 44. Crea una nueva rama: Ahora para practicar las sucursales, usaremos nuestro proyecto anterior, que es curso Tarea track. Si estás comenzando con esta sección, entonces puedes obtener esta carpeta de proyectos de seguimiento de tareas en los recursos de este video. En este proyecto, imaginaremos trabajando en la función Dragon drop. Para ello, crearemos nuestra primera nueva sucursal. Crear la rama en Git es muy sencillo. Sólo tenemos que escribir Git branch feature slash DND, lo que significa gota de dragón Aquí, puedes usar cualquier nombre. Estoy usando características las DND para aclarar que estamos trabajando en otra característica, no arreglando los errores Depende totalmente de ti como quieras llamarlo. Este estilo me pareció más útil, así que estoy usando esto. Ahora para ver las sucursales, podemos escribir, portón, sucursal, y echar un vistazo. Aquí solo tenemos dos ramas cuentan con slash DND y nuestra rama predeterminada, que es master Actualmente, estamos en la rama master, y por eso conseguimos estrella antes que rama Master. Y también podemos ver aquí el nombre actual de la sucursal. Ahora para trabajar en la sucursal DND, primero, tenemos que cambiar a esta sucursal DND Al principio para cambiar de rama, tenemos que usar el comando Git checkout. Pero como este comando es un poco confuso, así que consigue introducir un nuevo comando específico para cambiar ramas, que es Git switch. Aquí escribimos nuestro nombre de sucursal, que es característica slash DND Mira aquí nuestra marca cambió Lovely. Ahora, vamos a abrir este proyecto en el código VS usando código periodo. Ahora aquí, digamos que predecimos que agregamos una función de arrastrar y dibujar. Para demostrarlo, abro esta carpeta JS y en ese script punto archivo JS. Y en la parte superior, agrego comando usando Control Slash o Command Slash, agregando ag y draw feature En la parte inferior en el registro de puntos de la consola, esta es la función de arrastrar y soltar. Guarde este archivo y vea aquí obtenemos las modificaciones. Ahora podemos predecir, completamos aquí nuestra implementación de funciones Dragonrop Podemos agregar estos cambios al área de ensayo usando Git add period. Después de eso, Git comt y message implementan la función de caída de dragón Ver, aquí obtenemos un archivo cambiado y dos de inserción. Bonito. Ahora veamos los commits. Obtener registro, una línea. C, en la parte superior, tenemos características slash DND commit y nuestro headpointer se encuentra actualmente en la rama de características Entonces quiero aclarar una cosa es que los cambios que hicimos en esta rama sólo serán visibles en esa rama. Si volvemos a la rama master con kit switch master, mira, aquí obtenemos la versión antigua de nuestro código. Ahora bien, si registramos nuestros commits, aquí no conseguimos la característica granizada D y D capa porque eso en es un paso adelante de nuestra maestra Kate Si quieres ver todas las sucursales, entonces tenemos que escribir aquí, puerta, registro, d guión, una línea, d guión todo. Mira, aquí tenemos la sucursal. En el futuro, completamos con éxito esta implementación de características y queremos agregar ese código con nuestra rama maestra. Podemos fusionar ese código en rama master. Eso lo veremos en las próximas lecciones. Pero después de fusionar nuestra sucursal con la rama maestra, tenemos que eliminar nuestra sucursal Para la eliminación, escribimos Git branch D, aquí escribimos nuestro nombre de sucursal características D y D. Ahora bien, esto nos dará error o podemos decir advertencia, lo que nos está diciendo que esta rama no está completamente fusionada porque no fusionamos esta rama con la rama master. Ahora bien, si seguramente quiere eliminar esta rama, entonces podemos escribir el mismo comando con la D. mayúscula Actualmente, no estoy quitando esta rama porque en las próximas lecciones, te mostraré cómo trabajar con rama y fusionarla. Espero que entiendas sucursales. En palabras simples, conseguir que las sucursales ayuden a los desarrolladores a trabajar de forma aislada. 45. Mira los cambios entre ramas: Ahora, a veces en nuestro proyecto, realidad no podemos recordar lo que cambiamos en nuestra sucursal, sobre todo cuando tomamos dos, tres días de descanso. Entonces, ¿cómo podemos ver la lista de Komats que realizamos después de nuestra rama maestra Entonces para eso, usamos kit, log, master, dot dot. Aquí, escribimos nuestro nombre de sucursal, que es característica slash DND Mira, aquí solo obtenemos uno medio de lo que hicimos en la última lección. Si hicimos más de un commit, entonces también obtenemos todos esos commits aquí si queremos ver solo el mensaje de commit, entonces, por supuesto, podemos usar el guión una línea. Ahora podría preguntarse, y si quiero ver los cambios reales que hicimos entre nuestro maestro y el código de sucursal DND ¿Recuerdas qué comando usamos prevén la diferencia entre dos commits Usamos el comando Diff para eso. Escribimos Git, Dave, master, dot, dot, que son slash D y D. Por este comando, vemos la diferencia entre estas dos ramas Mira, aquí conseguimos que nuestro archivo JS punto de script se cambie, que está en la carpeta JS y podemos ver que se agregan estas dos líneas. Aquí, tengo un pequeño truco de atajo para ti. Si estamos trabajando en una de estas ramas, entonces solo podemos escribir la otra referencia de commit o nombre de sucursal. En palabras simples, aquí estamos actualmente en la rama maestra. Simplemente podemos escribir aquí así, Kate D y escribimos directamente el nombre de nuestra sucursal con la que queremos comparar. Característica slash D y D. Ver, aquí obtenemos la diferencia Ahora se podría decir que estas dos salidas son diferentes y eso es cierto. El caso es que aquí estamos comparando rama master con nuestra característica, slash DND branch, y por eso conseguimos que estas dos líneas se Ahora en la plataforma de atajo, estamos comparando característica, slash rama DND con nuestra rama master, y por eso tenemos aquí dos líneas Pero eso no importa porque sólo queremos ver la diferencia. A veces queremos ver solo los archivos que se cambian. Entonces para eso, podemos escribir Get did name only, o podemos usar n status, y escribimos nuestras características de la sucursal DND Ver, aquí solo cambiamos un archivo que es script dot archivo JS. Entonces, si fusionamos esta sucursal DND con nuestra rama maestra, entonces nuestro único archivo se modificará Usamos tu nombre solo opción dash, luego obtenemos solo los nombres de archivo. Pero a medida que usamos name dash status, entonces obtenemos los nombres de archivo con modificaciones, estado de inserción o eliminación. Ahora en la siguiente lección, veremos sassing git. 46. Domina el stashing: Ahora antes de que empecemos a aprender a esconder, déjame darte una condición Imagina que estás trabajando en tu importante proyecto y estás en la mitad de tu código. Ahora de repente tu manager viene a ti y te dice que corrijas el error en la función de caída de dragón en este momento. Ahora en esta situación, ¿qué vas a hacer? Una opción es que puede confirmar los cambios que realizó y luego trabajar en la función de caída de dragón. Pero como te dije, estás en la mitad de tu código. No se puede comprometer este código. Parece poco profesional. Ahora bien, ¿cuál es la solución en esta situación? En ese momento, podemos almacenar nuestros cambios actuales en la esquina de la puerta y cuando hayamos terminado con nuestra otra tarea, entonces podemos volver a esos cambios. De esta manera, nuestro medio código no se quedará en comas y tampoco perdemos nuestro medio código Este proceso por el que almacenamos nuestro medio código en la esquina se llama atsing Sas significa esconderlo en alguna parte Para mostrar el medio código, agrego en el script dot jslecs Esto es medio código. No quiero perder. Guarde los cambios, y si verificamos nuestro estado actual, aquí, obtenemos una modificación, y si tratamos de cambiar a la rama de características DND, entonces obtenemos el error que dice que sus cambios locales a los siguientes archivos serían sobrescritos por checkout Por favor, comprometa sus cambios o escalonarlos antes de cambiar de sucursal. Básicamente, es decir, si no nos comprometemos o escenificamos los cambios e intentamos cambiar a otra rama, entonces perderemos esos cambios. Entonces, para esconder el código, escribimos Git push A, y aquí escribimos nuestro mensaje de estrés para el resumen Digamos, trabajando en modificaciones del diseño de sitios web. Ver, nos guardamos directorio de trabajo e índice en Master. Ahora queremos ver todo el stass que hicimos en nuestro proyecto. Después escribimos la lista de estadísticas de Git. Mira, aquí obtenemos las Ss, marca como en el rojo en corchete cero en rama Master y nuestro mensaje SS. Ahora aquí hay una cosa. Este comando git stash push no agregará un archivo sin seguimiento en las Por ejemplo, aquí en la carpeta JS, creo un nuevo archivo llamado tamp dot js Y en ese archivo, agrego comando archivo temporal. Guarde esto. Y si escribimos Git status, aquí obtenemos el archivo tempt JS como archivo sin seguimiento Entonces, si ejecutamos aquí Git push, entonces Git no agregará este archivo en nuestro alijo por defecto Entonces para eso, tenemos que escribir aquí, o podemos escribir A, luego para mensaje de escondite Aquí también podemos combinarlos, y luego escribimos nuestro mensaje stash, que es agregar un archivo temporal Ahora bien, si volvemos a ejecutar git stash list, entonces aquí llegamos a stash Mira aquí nuestro primer guión, pasa a las estadísticas airear uno, y nuestro último guión agregado en estadísticas airear cero Aquí sash con éxito nuestros cambios actuales. Ahora podemos cambiar a la rama de función DND usando el conmutador Git, cuenta con rama DND Ver, aquí obtenemos el nombre actual de la sucursal, y en nuestro editor de código, nuestro archivo script también se cambia a la versión de características DND Recuerda, editamos esta línea de consola. Ahora imagina que completamos nuestro trabajo en esta rama, para que podamos volver a cambiar a la rama maestra. Ahora queremos obtener esos cambios que agregamos en el alijo Ahora antes de agregar esos cambios, queremos ver cuáles son esos cambios. Entonces para ver los cambios, escribimos Git show, y aquí escribimos el nombre de nuestro alijo que es iterar entre corchetes Ci, cero Ahora aquí, si no quieres escribir este nombre raro, entonces sólo podemos escribir este número cero. Mira aquí no obtenemos nada porque en esas estadísticas, agregamos solo untrackfle temp Por defecto, no muestre el archivo de pista en este comando. Así que para ver también UntrackFle, tenemos que agregar aquí U. Ver, ahora obtenemos Temp dot js file y Si quieres aplicar esos cambios en nuestro directorio de trabajo local, entonces podemos escribir Git apply zero. Ver, ahora obtenemos track file y además podemos verificarlo en nuestro editor de código. Bueno. Ahora como aplicamos esos cambios en nuestro directorio de trabajo, no necesitamos este cero. Para que podamos quitar el alijo y no queremos reunir demasiado alijo en nuestro proyecto Es muy buena práctica quitar alijo que ya no necesitamos. Podemos escribir Gates drop zero. Ahora bien, si vemos la lista de stache, entonces no obtenemos el alijo Ahora simplemente apliquemos este alijo nuestro directorio de trabajo. Escribimos Git, aplicamos, y lo que escribimos aquí, escribimos. Escribimos aquí de nuevo, cero porque quitamos el primer cero y conseguimos marcar nuestro uno a cero. Mira, obtenemos dos cambios en nuestro proyecto, uno en archivo script y otro archivo de seguimiento. Vamos a eliminar este estrés también. Para que podamos escribirlo caer otra vez, cero. O también podemos usarlo claro. Este comando eliminará toda estasis de nuestro proyecto. Ver, ya se han ido todas las estasis. 47. Comprende Merge en Git: Ahora aquí, imagina que hemos terminado con nuestra función de arrastrar y fila, así que queremos fusionar este código con nuestra rama maestra. Pero antes de hacer nada, primero tenemos que revisar la rama actual. Verás, estamos en la rama maestra. Entonces primero, tenemos que cambiar a la rama DND de barra característica Pero aquí tenemos algunos cambios en nuestro directorio de trabajo, y por eso nos ganó por cambiar. Pero aquí no queremos esos cambios, por lo que podemos cambiar con fuerza a nuestra rama DND de barra de características Para eso, tenemos que escribir puerta, switch, cuatro, característica slash rama DND Revisa tu código antes de ejecutar este comando en tus proyectos porque perderás tus cambios permanentemente. Ahora bien, en nuestro archivo de scrap dot js aquí en la Consola, escribo hecho con función de arrastrar y soltar y además eliminar este comando de la parte superior vamos a eliminar esta consola. Este archivo y también quitar este sello perros archivo. Eso no queremos. Ahora de vuelta a la terminal. Aquí, primero escenificamos nuestros cambios. Y entonces podemos simplemente Git Cate M, completa, función de arrastrar y soltar. Bueno. Ahora queremos fusionar nuestra sucursal de características DND con nuestra rama master Entonces hay dos tipos de fusión en Git. El primero es rápido para fusionarse y el segundo es el de tres vías Veamos cada tipo de fusión con ejemplo sencillo. Primero, veremos el ayuno para nuestra fusión. Entonces aquí tenemos múltiples amidas, y después de eso, creamos una nueva rama llamada característica D&D Ahora en esta rama, hicimos múltiples cometas. Ahora en esta rama, hicimos múltiples Ahora en esta etapa de la ayuda, terminamos con nuestra función, y decidimos fusionar nuestra rama de características con la rama maestra. Entonces en ese momento, podemos fusionar directamente estas dos ramas sin preocuparnos por nada. A esta fusión la llamamos como guerra rápida a la fusión. Ahora veamos la fusión de tres vías. Anteriormente, después de crear la sucursal, no cometimos nada en nuestra rama maestra. Pero en el mundo real, esto sucedió muy raramente porque como sabemos, hay muchos desarrolladores trabajando en una sola aplicación. Existe una posibilidad en la que otros desarrolladores se comprometerán en la rama master. En ese momento, nuestras sucursales se vuelven diversas. Entonces tenemos algunos cambios en rama master que no tenemos en nuestras características S D y D rama. Ahora bien, si ejecutamos merge aquí, Git no mueva nuestro maestro a la característica slash DND commit porque esto eliminará los cambios de la rama master Así que cuando ejecutamos aquí comando merge, Git crea un nuevo commit que combina los cambios de estas dos ramas. Ahora podrías preguntarte por qué llamamos a esta fusión como fusión de tres vías Porque depende de las tres commits. El primero es el punto común de unión de dos ramas. segundo es el último conocido en la rama maestra, que se llama como punta de la rama maestra, y el tercero es la punta de la rama DND de barra característica Git mira estos tres cometas y fusiona nuestro código de acuerdo a que este nuevo cometa que creó por la marcha se llama como Para recapitular, hay dos tipos de fusión. El primero es page for o merge si nuestras ramas no son divergentes o podemos decir que no agregamos nuevo cometa en nuestra rama maestra después de crear una nueva El segundo es la fusión de tres vías si nuestras ramas son divergentes o podemos decir que hicimos un nuevo commit en la rama master después de crear la Ahora en las próximas lecciones, veremos que estos dos se fusionan. No te preocupes, es realmente sencillo. 48. Aplicar la fusión rápida hacia adelante: Ahora, veamos el ayuno para nuestra fusión. Para recapitular rápidamente en rápido para la fusión, tenemos ruta de compromiso lineal y get mueve directamente el puntero maestro a nuestras características Veamos cómo podemos hacer eso. En primer lugar, vamos a registrar todos nuestros códigos, y como sabemos, si quieres ver las sucursales, entonces tenemos que usarlo log, dash one line, dash dash all. Y cuando estamos trabajando con sucursales, podemos escribir aquí opción de gráfico de guiones. Muy recomendable utilizar esta opción gráfica ya que nos mostrará que tenemos diversos cometas o no Además, no es necesario escribir este comando largo cada vez. Se puede utilizar como para eso. Ahora actualmente, no tenemos cometas diversos y por eso no podemos ver gráfica diversa, pero es así Ahora podemos ver actualmente estamos en la rama característica DND porque nuestro puntero de cabeza está aquí Ahora para fusionar esta característica de la rama DND en nuestra rama master, primero tenemos que cambiar a la rama master Bueno. Ahora podemos ver nuestro puntero de cabeza se mueve a la rama maestra. Ahora para fusionar estas ramas, escribimos git merge, y luego escribimos nuestro nombre de rama, que queremos fusionar en rama master. Mira, aquí nos ponemos rápidos para nuestra fusión. Ahora podemos volver a ver todos los cometas usando nuestro comando anterior Mira aquí no conseguimos nuevo cometa solo muévanse sobre Maestro puntero a la característica SS DND rama porque tenemos cometas lineales o podemos decir que no tenemos amidas diversas Y si a veces no queremos aplicar la fusión de avance rápido. Está totalmente bien. En git, también podemos aplicar la fusión no fast forward, y lo veremos en la siguiente lección. 49. Fusiona no hacia adelante rápido: Ahora, déjenme mostrarles cómo podemos evitar la fusión de avance rápido Entonces, para demostrarlo, tenemos que crear una nueva rama, y luego tenemos que cambiar a esa rama. Entonces estos son dos pasos diferentes. Déjame mostrarte un atajo para hacer estos dos pasos en un solo paso. Entonces podemos escribir el interruptor de puerta C para crear aquí escribimos nuestro nombre de sucursal. Digamos características Feedback. Mira, cambiamos directamente a la rama de retroalimentación. Ahora volvemos al código VS, y aquí abro index dot stmlfle Si te preguntas cómo estoy abriendo el archivo, solo presiona Control más P o Comando más P y escribe aquí el nombre del archivo. Ahora en la parte inferior, después de nuestra etiqueta principal, agrego un comentario para el formulario de comentarios. Imagina que agregamos aquí formulario de comentarios, guardamos los cambios y volvemos a nuestro Git Bash Aquí, primero escalonamos todos los cambios y luego los comprometemos como mensaje de confirmación realizado con la función de retroalimentación. Bueno. Ahora, vamos a revisar nuestro historial de comentarios. Mira, aquí conseguimos nuestro último compromiso. Ahora fusionemos esta rama de retroalimentación con nuestra rama maestra mediante una fusión no rápida Lo que haremos antes de fusionarnos, volvemos a la rama maestra Ahora aquí escribimos Gate, merge, Ff para ningún avance rápido y simplemente escribimos aquí el nombre de nuestra sucursal, que es Feature Slash Feature Feature Por este comando, le estamos diciendo a Git, si es posible avanzar rápido en esta fusión, todavía no lo hagas y haz un nuevo comando, que combinaba dos ramas. La diferencia fácil entre la fusión de avance rápido y la fusión avance no rápido está en la fusión de avance rápido, git no crea una nueva confirmación, pero en la fusión no rápida, Git crea Ahora, en el momento en que presionamos Enter aquí, Git pide un mensaje de confirmación de fusión. Por defecto, obtenemos aquí este mensaje de confirmación generado por git. Si queremos cambiarlo, entonces podemos cambiarlo aquí. Guarde el archivo y cierre el archivo. Ahora en nuestra terminal, podemos ver fusión hecha. Y si vemos historial con opción de gráfico, mira, aquí obtenemos la gráfica de nuestros commits. Podemos ver nuestro puntero maestro, pero nuestra rama de retroalimentación de características sigue ahí, y Git crea un cómico de fusión que combina los cambios de retroalimentación de características con la rama maestra Y obtenemos esta gráfica porque agregamos la opción graph en nuestro comando log. Ahora podría preguntarse ¿qué es lo mejor para fusionarse? Fusión rápida o deberíamos usar non fast for o merge. Veamos los pros y los contras para estos ambos fusionándose. En primer lugar, cuando usamos fast para fusionarnos, podemos ver nuestra historia muy claramente porque no hay divergencia en Pero si usamos no rápido para fusionarnos, entonces nuestra historia podría parecer un poco confusa Ahora mismo, podemos ver eso porque sólo tenemos una divergencia Pero en el mundo real, los grandes proyectos no tienen una sola rama. Son múltiples sucursales y muchas ramas diversas. Es por eso que no rápido para fusionar se ve poco confuso eso también significa rápido para fusionar tiene más claridad visual y por otro lado, tenemos menos claridad visual sobre nuestros Ahora, otra cosa es, si usamos fast forward merge, entonces podríamos saltarnos algunos contextos como cuando se integran cambios específicos. Pero si usamos non fast para fusionar, entonces no perdemos ningún contexto. Con cada cometas fusionados, tenemos detalles sobre cuándo y dónde hacemos los cambios Ahora después de eso, en rápido por fusión, no podemos aislar nuestro código de dos sucursales Pero en no rápido para nuestra fusión, podemos aislar nuestro código de dos ramas porque tenemos gomitas de fusión separadas Estos son los pros y los contras de estas dos fusiones. En mi opinión, estas dos opciones tiene pros y contras. Estás trabajando de manera individual, entonces puedes seleccionar cualquier tipo de fusión. Depende totalmente de ti. Pero muchas veces tu equipo te dirá que uses la fusión de avance rápido o no. Ahora, cuando estamos en flujo de nuestro trabajo, posible que olvidemos no usar ninguna opción de avance rápido, y su empresa le diga que use solo la opción de avance no rápido. Entonces la solución de esta situación es que podemos establecer opción de avance no rápido para nuestro repositorio actual, o también podemos configurarlo para todo el repositorio en nuestro sistema. Para eso, podemos escribirlo config, FF, no. Este comando deshabilitará avance rápido en nuestro repositorio actual. Además, si queremos desactivar avance rápido para todos los repositorios, entonces podemos simplemente addhee dads 50. Comprende la fusión de 3 vías: Ahora veamos la fusión de tres vías. Como sabemos si creamos una nueva rama, hacemos commit en esa rama, y luego también nos comprometemos en nuestra rama maestra, entonces podemos llamar a estas dos ramas o divergir entre sí Ahora en esta situación, mira ambas puntas de estas ramas y también mira al cometa común por donde estas dos ramas consiguen divergir Se da cuenta de la mejor manera de combinar estas dos ramas y aplicar esos cambios en el nuevo cometa. Para demostrarlo, nuevamente, creamos una nueva sucursal. Usando el interruptor de puerta C para Crear, y luego le damos nuestro nombre característica slash usuario Registrarse Ahora volvamos al código VS. Aquí en la carpeta del proyecto, creamos una nueva carpeta llamada registro de usuarios. Y dentro de esta carpeta, creamos un nuevo archivo llamado formulario registro punto SGML Y dentro de esto, rápidamente agrego fragmento HTML y cambio el título al registro como nuevo usuario Guarde este archivo y vuelva a nuestra terminal. Aquí, primero escalonamos todos los cambios y luego también los comprometemos en nuestra sucursal de registro de usuarios. Bueno. Veamos nuestro historial usando Git log, dash one line, dash all, Des dash graph. Ver, aquí tenemos nuestra nueva sucursal. Ahora, volvamos a cambiar a la rama maestra. En el archivo script dot js, agregamos aquí consola dot log line, y aquí consolamos aprendiendo la fusión de tres vías Guarda el archivo, y en el Git Bash, primero, montamos nuestros cambios, y luego simplemente cometemos los cambios Git, actualizar script dot js archivo para la fusión de tres vías. Bueno. Ahora volvamos a ver la historia. Aquí podemos ver la divergencia en nuestras ramas. Si estamos trabajando en esta rama, entonces podemos ir directamente aquí en la rama maestra. Esto se llama rama divergente. Ahora vamos a fusionar estas dos ramas. Aquí hay una buena noticia para ti. No tenemos comando separado para la fusión de tres vías. Es el mismo comando que usamos para la fusión de avance rápido Si tenemos ramas divergentes, lo que significa que teníamos viene en la rama maestra después de crear una nueva rama, luego obtener automáticamente aplicar fusión de tres vías ¿Cuál es el comando para fusionar? Derecha, git merge, y aquí agregamos feature slash user y presionamos Tab Completará automáticamente el comando. Aquí, pregunta por el mensaje merge commit. Lo dejo como está, cierro este archivo y vea aquí nuestras sucursales se fusionan. Y si vemos nuestra gráfica de historia, entonces podemos ver aquí tenemos nuestro cometa rama, y aquí tenemos en medio, que hicimos en nuestra rama maestra, y Gate fusionan estos dos cometas en esta fusión separada commit Así es como funciona la fusión de tres vías. Podrías pedir fusión de tres vías y no rápido para fusionar son los mismos, y tuve la misma pregunta cuando estaba aprendiendo fusión en La respuesta es no. No son iguales. Podrían verse similares, pero no son iguales entre sí. La diferencia es si en la fusión, tenemos cometas lineales y aún queremos combinar ramas en los nuevos cometas fusionados A esto se le llama fusión no rápida. Pero en la fusión de tres vías, siempre tenemos cometas divergentes, obtenemos automáticamente ramas combinadas en el nuevo Esa es la diferencia entre no rápido para la fusión y la fusión de tres vías. Ahora en la siguiente lección, veremos ¿cómo podemos eliminar merge branch de nuestro repositorio? 51. Borra la rama después de fusionar: Yo ahora cuando estamos trabajando con ramas en el git, si completamos trabajando en una rama y las fusionamos en el master, entonces no necesitamos esa rama. Creará confusión para nosotros y para los miembros de nuestro equipo también. Vamos a comprobar cuáles son las ramas que hemos creado usando git branch. Mira, aquí tenemos cuatro sucursales, y ahora quiero saber qué sucursales fusionamos en nuestra rama actual, cuál es la maestra. Escribimos git branch, dash merge. Vea, aquí obtenemos la lista de commits que están completamente fusionados en nuestro maestro de sucursal actual. Aquí obtenemos todas las sucursales porque fusionamos todas estas sucursales en nuestra rama maestra. Ahora podemos eliminar las ramas usando la rama Git, D, y escribimos nuestro nombre de sucursal, digamos característica D&D Ahora, si vemos el historial de nuestros ames, entonces característica DND eliminado de la historia. Ahora, si vemos el historial de nuestros ames, entonces característica DND eliminado de Aquí está el antes y el después de la historia. Ver, solo quita la sucursal de aquí. El medio se quedará ahí tal como está. Actualmente, no voy a retirar estas otras sucursales porque las necesito en el futuro. Ahora déjame darte un bono. En lugar de observar las ramas que se fusionan, es fácil ver directamente las ramas que no se fusionan, para que podamos fusionarlas en el futuro. Podemos tener en nuestra mente no dejar caer esa rama por error. Para eso, escribimos git branch, no, d fusionado. Mira aquí no obtenemos ninguna sucursal porque fusionamos todas las sucursales en nuestro maestro de sucursal actual. Ahora en la siguiente lección, veremos cómo resolver conflictos en git. 52. Cómo resolver conflictos en Git: Ahora antes de comenzar esta lección, quiero hacerle una pregunta sencilla. Imagina que tenemos dos ramas. Uno es maestro, y el segundo es el inicio de sesión de la función de barras. Ahora imagina que cambiamos el archivo SM de punto índice en nuestra rama master y cometemos los cambios. Y también en la rama de inicio de sesión de características, cambiamos algo en el índice punto stmlfle En definitiva, en estas dos ramas, archivo SML de punto índice es diferente Esa vez, si fusionamos estas dos ramas, entonces Git confundirá qué cambios debería tomar y qué cambios debería evitar. Y eso se llama como conflictos en Git. Entonces, cuando cambiamos el mismo archivo en diferentes ramas, y Git puede fusionar automáticamente esas dos ramas, eso se llama conflicto. Ahora podría preguntarse ¿cuáles son las posibles soluciones en las que ocurren los conflictos? Entonces primero es el cambio. Cambiamos la misma línea de nuestro expediente en ambas ramas. Después de eso, en una rama, eliminamos un archivo, y en la otra rama, cambiamos ese mismo archivo. También se producen conflictos. Además, renombramos el nombre del archivo en una rama y el mismo archivo en la otra rama. Además, agregamos archivo un punto TXT en la primera rama, y también agregamos archivo un punto TXT en la segunda rama, pero el contenido del archivo es diferente a que también se produzcan conflictos. Estas son las situaciones comunes en las que puede ocurrir un conflicto. Ahora bien, podría preguntarse ¿qué va a hacer en esta situación? ¿Y cuál es la solución para resolver el conflicto? Simplemente git nos preguntará y nos dará opciones qué cambios queremos hacer. No va a interferir en el conflicto. Simplemente nos preguntará ¿qué queremos hacer ante esta situación? Déjame mostrarte eso prácticamente. Para demostrar el conflicto, primero tenemos que crear un conflicto. Escribamos el interruptor de puerta C, sesión de funciones y lo que escribe este comando. Creará una rama de inicio de sesión de funciones y también cambiará a esa rama. Ahora déjame cambiar en el archivo ScrapTGS. La segunda línea, escribo aquí, consola dot log, consola para función, rama de inicio de sesión de slash Guarde este archivo, y permítame escenificar los cambios y también cometer estos cambios con el mensaje de compromiso, modificar script dot js archivo para características inicio de sesión. Hecho. Ahora cambiemos a la rama master y también en el código VS, también cambiamos la segunda línea y escribimos aquí, Consola para rama master. Guarde este archivo. Y probemos los cambios. Y además, nos comprometemos con mensaje, Modificar script dot js file for master. Ahora, intentemos fusionar estas dos ramas. Así que ejecutamos Gate merge, feature slash login. Ver, aquí obtenemos conflicto y puerta diciendo fusionar conflicto en script dot archivo JS. Y también, dice, fusión automática falla y soluciona el conflicto, y luego el resultado committer Entonces aquí tenemos que hacer manualmente los cambios y también podemos ver que estamos en medio de la fusión Déjame mostrarte el estado actual por git status. Ver, aquí tenemos camino sin fusionar. Déjame mostrarte algo genial. Abra el código VS y vea, aquí hemos cambiado la línea resaltada, lo que está causando conflicto. No te confundas con esta pantalla. Es realmente simple. Ver, primero obtenemos el puntero de encabezado, que está indicando la rama actual que es master, y debajo de eso, tenemos el cambio, nos comprometemos en la rama master. Después de eso, tenemos línea para la separación, y luego tenemos el cambio que hicimos en la característica ss login branch. ¿Ves? Aquí tenemos un par de opciones que nos da el código VS. El primero es aceptar los cambios actuales. Si seleccionamos, entonces acepta los cambios actuales, por lo que aplicará los cambios de la rama actual. Deshagamos esto usando Control plus set o Command plus set. Ahora bien, si seleccionamos aceptar los cambios entrantes, entonces se aplicarán los cambios de la segunda rama, y podremos aplicar ambos cambios, y la última opción es comparar ambos cambios. Comparará nuestros archivos uno al lado del otro. Entonces vamos a cerrar este comparativo. Aquí tenemos opciones por código VS. También podemos cambiar manualmente el archivo. Entonces, eliminemos esta característica, recortemos el puntero de inicio de sesión, y también eliminemos esta separación de líneas y también eliminemos este puntero de cabeza Si queremos mover estas líneas arriba y abajo, entonces también podemos hacerlo. Pero siempre recuerda aquí no agregamos un código nuevo porque el objetivo principal de la fusión es fusionar el código de dos ramas, no agregar un nuevo código, pero a veces debemos tener que agregar nuevos cambios. Si no es evitable, entonces puedes hacerlo también Ahora después de que hayamos terminado con nuestros cambios, servimos el archivo y volvemos a la terminal. Aquí, tenemos que poner en primer lugar los cambios por git add period. Ahora vamos a comprobar nuestro estado actual. Verás, no tenemos camino sin fusionar. Podemos escribir Git commit y obtenemos el mensaje de commit aquí. Lo dejo como está, cierro el archivo y veo, fusionamos nuestras dos ramas, y además el estado de fusión se ha ido 53. Interrumpe el conflicto en Merge: Ahora, a veces ejecutamos el comando merge y nos da conflicto, pero en ese punto, no queremos resolver ese conflicto porque los conflictos ocurren por error. Entonces, en lugar de seguir adelante en el estado de fusión, vamos sobre este comando merge Para eso, no voy a crear una nueva rama y crear conflicto. Te mostraré mi grabación de pantalla anterior antes de que resolvamos nuestro conflicto. Aquí ejecutamos el comando Git merge. Verás, tenemos conflicto. No queremos ir más allá, podemos escribir, computar, fundir, y ver que estamos un paso atrás del estado de fusión 54. Restablece el commit de fusión: A ahora a veces cuando fusionamos dos sucursales y nuestro código deja de estacionarse o se estrelló, puede suceder porque cometemos algún error al fusionar Por lo que hay dos soluciones para esta situación. En primer lugar, podemos restablecer nuestro commit de fusión a la anterior en medio antes de fusionar. Y la segunda opción es que podemos deshacer nuestro código merge y comprometerlo en el nuevo at. No confundas con esto, déjame explicarte cada escenario. Entonces primero, vemos el cometa reset merge. Entonces aquí en nuestro Caid, nuestro puntero de cabeza y maestro está en nuestra fusión se reunió Este es nuestro apuntador de sucursal. Ahora en este commit de fusión, obtenemos el problema. Así podemos restablecer nuestro cometa moviendo este tanto puntero al anterior en antes de que hagamos fusión Básicamente, estamos restableciendo la capa merge a la capa anterior Ahora podría preguntarse ¿qué pasará con este commit de fusión? Entonces a medida que movemos a nuestro maestro y apuntador de cabeza a la anterior en, esto en medio se vuelve inútil Después de algún tiempo, automáticamente eliminará esto en medio de nuestro repositorio. Ahora como podemos ver indirectamente estamos cambiando o reescribiendo el historial de commit, y eso está bien solo si tenemos repositorio localmente Pero si tenemos muchos miembros del equipo trabajando en este proyecto, entonces no consideramos esta opción. En esta situación, cuando tenemos miembros del equipo trabajando en un mismo proyecto, entonces tenemos que revertir nuestro código y comprometerlo en el nuevo comando Entonces nuevamente, tenemos nuestro historial de compromiso. Cuando revertimos nuestra fusión, entonces Git era la punta de las ramas Ahora, en lugar de mover este tanto puntero con el cometa anterior, Git toma los cambios del amet anterior, lo deshace y luego hace otro cometa que es el Podemos ver que este código de commit anterior es el mismo que este código de commit revert Este método es más conveniente porque aquí no reescribimos nuestro historial de Git Déjame mostrarte este método de ambos uno por uno. Primero, vemos la opción de reinicio. Entonces para eso, escribimos git reset, dash dash hard. Aquí escribimos duro. Te lo explicaré en tan solo un minuto. Y aquí escribimos nuestra referencia de compromiso, que podemos llamar como cabeza hasta una. Ahora antes de ejecutar este comando, asegúrate de escribir el commit a partir de este ammt merge en algún lugar de tus nodos Ahora, básicamente, este comando le dirá a Git que mueva el puntero master y head al commit anterior. Aquí podría preguntarse, ¿qué es esta opción difícil de hacer? Entonces cuando ejecutamos el comando reset, tenemos tres opciones, soft, mixed y hard. Déjame explicarte esto en detalle. Entonces aquí tenemos nuestro código de directorio de trabajo, código área de ensayo, y tenemos nuestro código Commit. Ahora cuando ejecutamos el comando reset con la opción soft, solo restablecerá nuestro código de commit al commit específico, pero no tocará nuestro código de área de ensayo código de directorio de trabajo. Por lo que nuestros cambios en el directorio de trabajo y el área de puesta en escena seguirán siendo los mismos que tenemos actualmente. Ahora, si usamos la opción mixta DSDs, que es la opción predeterminada, restablecerá el código de commit y también modificará el código del área de ensayo a esa commit específica Y ahora ¿puedes adivinar qué hace esta dura opción? Bien, restablecerá el código de commit, código del área de ensayo y también el código del directorio de trabajo al comando específico. Entonces es por eso que usamos la opción hard con el comando reset. Entonces ejecutemos este comando. Ver, aquí obtenemos la cabeza está ahora en este commit y también podemos ver el mensaje de commit. Volvamos a revisar nuestro historial. Consulta aquí nuestro jefe y maestro se mueve a la commit anterior en la rama master, y no vemos nuestra commit merge en esta lista, pero aún podemos movernos a esa commit porque Get elimina ese commit inmediatamente. Escribimos git reset dash had, y aquí escribimos ese merge commit, que es E siete, E siete, d ocho. Ver ahora nuestra cabeza se mueve a la fusión commit. Podemos ver en nuestra historia, obtenemos la misma fusión mit. Ahora en la siguiente lección, veremos la mejor manera de deshacer la fusión, que es por revertir 55. Revierte el compromiso de fusión: Ahora, déjame mostrarte la segunda opción para deshacer la fusión, que es revertir los cambios de fusión Entonces para eso, escribimos git revert, y aquí escribimos nuestro commit has, que queremos revertir En nuestro caso, es este compromiso de cabeza. Entonces escribimos aquí, cabeza y golpeamos Enter. Ver, aquí obtenemos error. Commit es merge, pero no se dio ninguna opción. Revertir fallar. Entonces, ¿cuál es la opción de que habla Kit? Entonces aquí está nuestro compromiso de fusión. Cuando decimos revertir a fusionar commit, Git tiene dos opciones Primero, G revertirá commit al último commit de la rama master, y nosotros llamamos a este commit como primer padre porque estamos en la rama master Ahora la segunda opción es que volverá al último cometa de la rama característica, que se llama como segundo padre Entonces escribimos aquí git revert M uno, que es el primer padre de nuestra rama actual, que es master, y que commit queremos revertir, queremos revertir head Queremos revertir los cambios como segundo comando padre, entonces podemos escribir aquí M dos, pero eso es raro Vamos a cambiarlo por el uno y darle a Enter. Ahora consigue pedir el mensaje de comando. No quiero cambiarlo, así que simplemente cierro el archivo. Ahora, veamos la historia. Ver en la parte superior, tenemos nuevo Commit, que es el commit revert de esta commit de fusión Así es como podemos revertir nuestra fusión sin reescribir el historial de commit Siempre prefiero elegir esta opción de revertir en lugar de reiniciar, pero en definitiva la elección es tuya. Si tu proyecto es local, entonces puedes usar lo que quieras. Pero al trabajar con equipo, revertir es mejor opción 56. Fusiona Squash en el historial de compromisos: Ahora, antes de aprender a fusionar squash, que es otra técnica de fusión, déjame darte una situación Entonces aquí está nuestro historial de compromiso, y tenemos una sucursal llamada Fix Bergh Login En esta rama, solucionamos errores en nuestra función de inicio de sesión. Entonces en esta rama, tenemos un par de commits F uno, F dos, y F tres. Terminamos con el error de corrección en el formulario de inicio de sesión. Podemos fusionar estas dos ramas. Ahora aquí, como podemos ver, este F uno, F dos y F tres es parte de nuestra historia de compromiso. Pero para arreglar el error, imagina que hicimos algunos malos commits, como cambiar este poquito y cometerlo. Estamos a la mitad de nuestro arreglo del error, y por solo puntos de control, hicimos estos cometas En este caso, no queremos agregar este F uno, F dos y F tres en nuestro historial de compromiso. Entonces la solución es antes de fusionar nuestras ramas, creamos un kami de squash, que es la combinación de este F uno, F dos y F tres todos en un solo cometa Y entonces simplemente podemos mover nuestro puntero maestro a este cometa. Pero recuerda, esto no es el fusionado en porque este cometa no tiene dos padres reunidos y también podemos ver que no está conectado con el cometa F tres Como aquí tenemos todos los cambios de esta rama, podemos dejar esta rama de nuestra historia met, y ahora tenemos historia lineal y no tenemos mala capa de rama. Este es el beneficio de usar la fusión de squash. Ahora podrías preguntar, ¿ deberíamos usar siempre técnica de fusión de squash? La respuesta es no. Solo usaremos fusión de squash cuando nuestros cometas de rama sean malos o no queramos mantener a los cometas en la historia Por ejemplo, me gusta usar la fusión de squash cuando trabajo para arreglar pequeños errores o característica muy pequeña, que puedo completar en una a 2 horas Las situaciones, no necesito esos puestos de control. Pero si la función o bug es grande, entonces no uso squash merge y mantengo los puntos de control en la historia Ahora veamos fusionarse squash en nuestro proyecto. Aquí, antes que nada, vamos a crear rápidamente una nueva rama usando Git switch, C Fix Bugs Login. Vamos al código VS para el cambio, elimino estas tres líneas de consola y adhiero newconsole dot log Corregir el error de inicio de sesión Checkpoint uno. Imagina aquí tu horario de oficina se acaba y quieres arreglar el error mañana. Entonces por eso CheckPoint uno. Guarde este archivo ahora de nuevo en nuestra terminal, y en lugar de stage y Comet en dos pasos, podemos usar aquí atajo que es Git AM y escribir mensaje de commit, bug pigs en función de inicio de sesión, checkpoint Bueno. Ahora para demostrarlo más claramente, haremos un commit más en esta rama. En nuestro caso, venimos al día siguiente en la oficina y arreglamos el error por completo. Entonces vis Cd, y aquí eliminamos el checkpoint uno porque arreglamos el bug completamente Ahora de nuevo, volvemos a la terminal, y aquí escribimos gate com amfigBug en función de inicio de sesión completa Bueno. Ahora veamos la historia. Consulta aquí en la parte superior, tenemos dos commits de rama. Pero como puedes ver se ve feo. ¿Qué es este punto de control? Aquí, aplicamos la fusión de squash. Es realmente simple. Básicamente, los comandos son muy simples, solo haciendo que esa situación tome más tiempo aquí. Pero es importante mostrarte el verdadero ejemplo. Ahora aquí se podría preguntar, ¿ podemos hacer aquí empujar por una fusión Porque no tenemos ramas divergentes Sí, podemos hacer aquí rápido para nuestra fusión, pero en este caso, no queremos salvar a estos dos cometas en la historia Solo queremos guardar los cambios, y por eso aquí hacemos fusión de squash, que combinará cambios de estas dos ramas cometa. En primer lugar, tenemos que cambiar a nuestra sucursal maestra. Ahora, anteriormente, escribimos para merge, Git Merge, Fixburg Login Pero para la fusión de squash, solo agregamos aquí opciones squash. Entonces aquí podemos ver que hicimos squash Kammit. Y aquí está la lista de archivos que cambiaron. En nuestro caso, solo tenemos un archivo porque solo cambiamos el archivo script dot JS, pero no agregaba directamente ese commit en nuestro historial. Estos cambios son solo en la zona de espera. Déjame mostrarte. Ejecutamos Gate status, C, aquí obtenemos script dot js file, el cual se modifica. Ahora podemos cometer estos cambios, gate commit. Aquí escribimos combine commit message, que siembra todos los cambios suceden en esta rama Digamos que se corrigió el error de la página de inicio de sesión arreglando el tipo de datos y el punto final en la solicitud de API. Bueno. Ahora, veamos la historia. Ver, en la parte superior, tenemos otro cometa, pero no está vinculado con la rama Fix buerg slash Así que cuando eliminamos esta corrección buurgs log in branch, entonces obtenemos un historial de commit claro y lineal Ahora bien, aquí podría preguntarse, ¿y si no retiramos esta sucursal? Idealmente, deberíamos eliminar la rama después de hacer squash merge porque esta rama no se declara como la rama fusionada. Déjame mostrarte a lo que me refiero. Si escribimos rama Ket, guión fusionado. Aquí, obtenemos la sucursal de inicio de sesión de FixBurg como sucursal no fusionada. Pero como sabemos, ya agregamos este código de sucursal en nuestra historia usando squash merge. Esto creará confusión en nuestra historia. Entonces es mejor dejar caer esta rama cuando hacemos fusión de squash. ¿Recuerdas qué comando usaremos para dejar caer la rama? No te preocupes. Si no te acuerdas, también puedes usar el set de trampas. Escribimos Git branch, D, y aquí escribimos el nombre de la sucursal que es Fixburg login Aquí nos sale el error, que es decir que las ramas no están completamente fusionadas. Entonces aquí tenemos que abandonar con fuerza esta rama. Traes el comando anterior y simplemente quitamos esta D y agregamos aquí D. C, nuestra sucursal eliminada con éxito. Ahora, si revisamos nuestro historial de compromiso, nos limpiamos en tu historial. Usamos squash merge cuando no queremos guardar malas commits de nuestras sucursales. 57. Cómo degradar la rama: Entonces, ¿qué es rebasar en git? Rebasing es una técnica que se utiliza para cambiar la commit base de la rama a otra Déjame explicarte con el ejemplo. Aquí está nuestro historial de compromiso y estamos trabajando en la rama llamada features OT. Ahora aquí, mientras estamos trabajando en la rama OT, digamos que alguien tenía compromiso con la rama maestra. Ahora queremos fusionar estos cambios de rama maestra en nuestra rama de características sin crear las fusiones innecesarias Aquí, ¿cuál es la solución? Una solución es fusionar estas dos ramas y luego seguir trabajando en ellas. Pero entonces tenemos que crear también otra característica menos oth rama. Eso lo podemos hacer. Otra solución es que podemos usar rebasing, lo que básicamente significa que podemos cambiar la base de nuestra sucursal Actualmente, esta es la base de nuestra otra rama. Si cambiamos nuestra base a este último commit maestro, entonces llegamos a los cambios en nuestra rama oth sin fusionar las ramas Eso es lo que es rebase. Simplemente estamos cambiando el commit base de nuestra rama. Ahora aquí hay una cosa que hay que tener en cuenta esta técnica de rebasar, reescribir nuestra Cuando cambiamos nuestra base a otro amet, entonces Git no cambia el F original uno Kamete Es simplemente tomar estos dos abrigos y crear un mismo amet que ellos y luego vincularlos con la última capa maestra luego simplemente mover este punto de rama aquí Ahora, como podemos ver, estos comandos no están conectados con la F para cometer, caerán este F uno y F para cometer. Es por eso que rebasar reescribir el historial de comandos, y por eso solo aplicaremos rebasing cuando estemos trabajando localmente De lo contrario, nuestra historia se convierte en masa. Ahora déjame mostrarte cómo podemos realizar rebasing. Primero, tenemos que crear una nueva rama usando Git switch, la función C OT y volver al código VS. Aquí simplemente creamos un nuevo archivo en Jsfolder llamado auth Y aquí simplemente consola dot log trabajando en la autenticación. Guarde este archivo. Ahora menos estos cambios. Y luego cometerlo con mensaje en orth punto Jspile Sé que este no es un mensaje apropiado, pero para demo, está bien. Entonces ahora tenemos sucursal con una Kat. Comprobemos nuestro historial. Aquí, tenemos que hacer una kamita en master para crear kamits divergentes Entonces, antes que nada, volveremos a cambiar a la rama maestra. Abra el código VS, y haré cambios en el archivo script dot js. Entonces aquí simplemente elimino este mensaje de consola, y aquí mismo se requieren algunos cambios para la rama OT y guardo esto. Ahora volvamos a la terminal y probemos los cambios, bueno, y también lo comprometemos. Git commit M, cambios que son necesarios para OT. El ahora vamos a revisar nuestra historia. Ver, ahora nuestra historia es divergente. Si no divergimos nuestras ramas, entonces andar, por defecto aplicar fusión de avance rápido Ahora tenemos nuestras ramas divergentes. Entonces tenemos dos opciones. Podemos aplicar fusión de tres vías o podemos rebasar. Actualmente, nuestra otra rama está apuntando a esto en. Ahora en rebasar, vamos a hacer que nuestra otra rama apunte a esta cumbre, que es la última en medio en el maestro Para rebasar, el primer paso es que tenemos que movernos a la rama que queremos rebasar Aquí, queremos rebasar nuestras características de la rama OT, y después de eso, aplicaremos rebase Primero cambiaremos a la rama OT característica. Ahora bien, ¿cuál es el comando para rebase? Es realmente simple. Escribe git rebase, y master. Básicamente, le estamos diciendo a Git. Queremos rebasar nuestra rama actual al puntero Master, que actualmente se encuentra en el último comando en la rama master Ver, revisamos con éxito nuestra sucursal. En el mundo real, muchas veces durante el rebasing, obtenemos conflictos Te voy a mostrar cómo podemos lidiar con los conflictos en la siguiente lección. Actualmente, solo nos enfocamos en la simple rebase. Veamos qué vamos a conseguir en la historia. Ver, aquí obtenemos historia lineal. Ahora, si queremos fusionar estos, entonces primero cambiamos al maestro, luego simplemente ejecutamos get merge, feature OT y done. Ver, aquí nos ponemos rápidos para nuestra fusión porque tenemos historia lineal. Para explicarte esto con mayor claridad, aquí está el antes y el después de la historia. Podemos ver que no obtenemos el mismo abrigo de rama. Como te dije, sí creó un cometa nuevo, que es lo mismo que esa vieja rama kmete Si tenemos tres medicamentos en la otra rama, entonces podemos aquí tres nuevos abrigos Ahora en la siguiente lección, veremos qué haremos si tenemos conflicto durante la rebase 58. Resuelve conflictos mientras rebasa: Ahora veamos cómo podemos lidiar con los conflictos durante el rebasamiento No hay nada de especial en eso. Haremos el mismo proceso que resolvemos los conflictos antes. Pero hay dos, tres comandos útiles que necesitamos durante esto. Entonces antes que nada, hay que volver a crear una nueva sucursal. Digamos que literalmente me estoy quedando sin nombre aquí. Digamos FixBugot. Ahora hagamos algunos cambios en nuestro archivo STML de punto índice. Aquí, cambio el título de nuestro sitio web. En ese entonces solo escribimos Fix Auth bug. Decir los cambios y volver a nuestra terminal. Aquí hay un consejo rápido. Si no te gusta cambiar entre dos ventanas, entonces también puedes abrir terminal en el código VS. Simplemente presione Control más Batak o Comando más Batak. Me gusta usar itbash así que me cambio a eso. Primero, pongamos en escena nuestros cambios y también nos comprometamos con los cambios, Gate compromete a Fixburg en la autenticación Bueno. Ahora tenemos que comprometer cambios en la rama maestra y en la misma línea para crear conflicto. Entonces volvamos a cambiar a la rama maestra y pasar al código VS. Y en el archivo STL punto índice, también cambiamos el título, adherimos a más signo de exclamación Guarde este archivo. Degustemos el cambio y también comprometamos los cambios con mensaje. Cambiar el título del sitio web. Comprobemos nuestro historial. Ver, aquí obtenemos ramas divergentes. Ahora, simplemente rebasamos esta rama al último puntero maestro ¿Cuál es el primer paso de rebase? Cambiamos a la rama que queremos rebasar. Cambiamos a la sucursal FXBurgoth. Entonces, ¿qué vamos a hacer? Simplemente, escribimos kit rebase master. Ver aquí obtenemos el conflicto en el archivo HTML índice. Vamos a abrir código VS, y aquí podemos ver conflicto. Ahora aquí podemos seleccionar de estas tres opciones. Selecciono aquí la primera opción, excepto los cambios actuales. Guarde este archivo y vuelva a la terminal. Aquí podemos ver que estamos en el proceso de rebase. Ahora aquí sólo tenemos un conflicto. Si tenemos múltiples conflictos, entonces tenemos que resolverlos todos. Después de eso, simplemente escribimos git rebase, dash, continuamos para continuar con el proceso de rebase para el siguiente cometa rama Si el siguiente commit también tiene conflictos, entonces nuevamente los resolvemos y nuevamente ejecutamos este comando git rebase, dash continue Seguimos hasta que todos nuestros conflictos se resuelvan. Entonces si por alguna amida, queremos saltarnos los conflictos, entonces podemos usar aquí otra opción, dash dash kip. Esto se saltará el conflicto actual de nuestro medio. Por ejemplo, obtenemos conflicto y no queremos resolver ese conflicto, entonces usamos aquí Skip. Además, tenemos otra opción, que es dash About para sobre el proceso de rebase sin resolver los conflictos Esto es muy útil mientras tenemos tantos conflictos y no queremos resolverlos aquí. Entonces en esta situación, podemos sobre este proceso de rebase. Verás, estamos fuera de nuestro proceso de rebase. Ahora no estamos haciendo aquí rebase porque es el mismo proceso que vemos en la lección anterior Y otra razón es que tenemos rama divergente que necesitamos en la siguiente lección Entonces por eso abordo este proceso de rebase. Si quieres hacer rebase, entonces puedes hacerlo. Pero en la siguiente lección, hay que crear ramas divergentes Entonces, como puedes ver, rebase es literalmente reescribir la historia Entonces es por eso que usar el rebasing con proyectos locales. 59. Técnica de picador de cereza: Ahora aquí está nuestra historia de Cate. Supongamos que tenemos como en la rama WigberGoth, A one y A. Ahora aquí queremos copiar todo este Evan Camt y agregarlo a todo este Evan Camt y agregarlo nuestra rama maestra o alguna otra rama Se podría decir que podemos fusionar estas dos ramas, pero aquí está el problema. Nuestra sucursal Fixburgoth no está lista para fusionarse. Tenemos algo de trabajo que hacer en la rama Wigberg slash Oth. Ahora en ese momento, utilizaremos una técnica llamada clavija de cereza. Cuando queremos copiar un gameto completo de una rama a otra rama, entonces usaremos la técnica de recolección de cerezas Aquí en nuestro proyecto, podemos ver que tenemos nuestra sucursal maestra y tenemos sucursal FigBurgoth con Para demostrarlo más claramente, crearemos un gameto más en la rama de auth Actualmente estamos en la sucursal Wix per South. En el código VS en el archivo scrip dot js, simplemente agregamos otra línea de consola, escribimos cambios para el segundo commit para FixBugot Estos cambios no son materia porque no estamos trabajando en el proyecto real. Aquí, nuestro objetivo principal es aprender git, guardar los cambios y volver a nuestra terminal. Vamos a escenificar y comprometernos juntos. Gate AM corrige el error de Auth en el archivo JS de punto raspado. Ahora tal vez te preguntes por qué uso este comando juntos y por qué lo uso a veces por separado. El comando único se ejecutará sólo cuando tengamos actualizaciones. Si agregamos nuevo archivo, entonces primero, tenemos que escatimar ese archivo, y luego tenemos que comprometerlo. Bueno. Ahora volvamos a ver la historia. Ver en una rama, tenemos dos gametos y aquí tenemos un gameto en la rama maestra Ahora vamos a recoger a cereza este primer encuentro. Entonces este commit tiene lo que queremos copiar. Para mi, es e67 90d4, donde queremos agregar este commit, necesitamos esta copia de commit en nuestra En primer lugar, cambiamos a la rama maestra. Ahora lo escribimos cherry Pik aquí escribimos nuestro commit, que queremos copiar. Mira, aquí tenemos conflicto, y por eso te dije que no resolvieras el conflicto en la lección anterior, y también podemos ver que estamos en el proceso de recolección de cerezas. Cuando tenemos conflicto, simplemente vamos al código VS y resolvemos el conflicto. Aquí aceptamos cambios entrantes. Guarde este archivo y vuelva a la terminal. Aquí comprobamos nuestro estado actual. Ver aquí obtenemos camino fusionado. Entonces tenemos que escenificar nuestros cambios, Gate agregar periodo. Y ahora volvamos a verificar el estado. Ver camino sin fusionar se ha ido. Así que ahora podemos comprometernos, Gate, commit, y golpear Enter. Abrir vía código, y aquí escribimos mensaje de compromiso. Al final, solo escribo copia para que podamos identificarnos rápidamente. Veamos nuestra historia amet. Ver, aquí obtenemos el nuevo ejemplar kamet y aún así nuestra sucursal es la misma que antes Por lo que copiamos los cambios de este amet sin fusionar la rama Fibergoth en nuestra rama maestra Ahora, déjame decirte por qué le da a esta técnica el nombre de picking de cerezas. Así que el nombre de recolección de cerezas refleja la naturaleza selectiva de este proceso. Entonces, si ves cerezo en ese árbol, tenemos muchas cerezas Pero para comer la cereza dulce, tenemos que seleccionar cereza específica del árbol, y luego podemos disfrutar de la cereza. Mi boca se está llenando de agua. Ahora como estamos recogiendo cereza específica del cerezo en git, tenemos mitra y estamos recogiendo commit específico y aprovechando ese commit Igual que recogemos cereza. Por eso Git llamó esta técnica como técnica de recolección de cerezas. Espero que te guste esto. Nos vemos en la siguiente lección. 60. Agrega un archivo específico a otra rama: Ahora en la técnica de recolección de cerezas, recuerden, copiamos amet entero Pero, ¿y si solo queremos copiar un archivo específico del Kami Entonces aquí cómo podemos hacer eso. Entonces actualmente estamos en la rama master, y si miramos nuestro archivo script dot js, entonces aquí, obtenemos solo dos líneas de consola. Ahora si cambiamos a la rama FxBurgoth, y vemos, en nuestro archivo script dot js, obtenemos dos Ahora queremos copiar este script dot js del archivo FxBurgothBranch, y agregarlo en Volvemos a cambiar a la rama master porque queremos agregar el archivo en la rama master. Aquí escribimos Git, restauramos la fuente es igual a, y aquí escribimos nuestra marca de la que queremos copiar archivo, que es Vicksburg oth Ahora después de eso, escribimos nuestra ruta de archivo que queremos copiar. Escribimos Js script dot js. Asegúrese de escribir la ruta del archivo, no solo script dot js. De lo contrario, obtendrá error. Aquí también podemos separar nuestro nombre de archivo del comando usando doble guión. Eso ya lo vimos. Recuerda, aquí te estamos diciendo get copy script dot js file, última versión de la rama WigberGoth, y pegarlo en nuestra rama y pegarlo en nuestra Ahora bien, si revisamos nuestro archivo script dot js, aquí obtenemos dos líneas de consola que son las mismas de FixBurgoth Ahora podemos escenificar los barquillos y si quieres comprometerte, entonces también podemos comprometer nuestro código Así es como podemos copiar un archivo específico de una rama a otra sucursal. 61. Branch y merge en código VS: Ahora veamos la función de rama y fusión en nuestro código VS. Lo primero que quiero borrar es código VS no tiene todas las características, lo que hacemos usando comandos git. Entonces veamos qué tenemos en VSCode. Abra el control de código fuente. Aquí, obtenemos nuestros archivos de etapa y etapa. Eso ya lo vimos. Ahora aquí en la parte inferior, después viene, tenemos sección de ramas. Aquí, podemos ver todas nuestras sucursales. Contamos con master Fix BouGoT y contamos con carpeta de rama característica Ahora podrías preguntar, no creamos esta carpeta de características. Entonces, ¿quién creó esto? Déjame decirte que creamos esto porque usamos barra diagonal en el nombre de la rama, y para todas las ramas de características, usamos barra diagonal de características el nombre de la rama Por eso llegamos aquí carpeta de características. Si tenemos más de una sucursal con Fix Berg, entonces también obtenemos aquí la carpeta Fix Berg. Ahora aquí podemos ver actualmente estamos en la rama maestra porque tenemos aquí Tick Mark. También, podemos cambiar de sucursal desde aquí. Además, podemos crear una nueva sucursal a partir de aquí. También tenemos ver rama como lista, y pocas opciones más. Ahora, si damos click en alguna sucursal, aquí llegamos a comparar opción. Seleccione el, y aquí escribimos nuestra marca que queremos comparar. Digamos Pisburgot. Ver ahora esta opción convertida en desplegable. Podemos ver aquí los expedientes que se modifican o efectúan. Actualmente, no tenemos ningún archivo aquí, pero si tenemos archivos, entonces haciendo clic sobre ellos, podemos ver los cambios. Ahora déjame mostrarte cómo podemos realizar la fusión. Haga clic derecho en la rama Fix Burg Oth y seleccione fusionar en rama actual. Aquí, obtenemos muchas opciones de fusión. Primero, tenemos merge, que es el comando simple merge como git merge y branch name. Después de eso, tenemos fusión de avance rápido. Aquí podemos ver que solo tenemos avance rápido. Por eso, le estamos diciendo a la marcha, solo use la fusión de avance rápido si es posible De lo contrario, déjelo como está sin fusionarse. A continuación, tenemos squash merge, entonces no tenemos fusión de avance rápido, y por fin tenemos sin avance rápido y sin commit, o también podemos cancelar o sobre demerge Simplemente seleccionemos la combinación predeterminada, y cerramos este archivo de mensajes de confirmación y vemos la fusión realizada. Ahora bien, si vemos nuestras amidas, entonces llegamos aquí merge commit. Ahora bien, si escribimos fuga en Camt anterior entonces llegamos aquí opción de revertir Aquí seleccionamos simple revertir y vemos aquí obtenemos el giro de revertir Ahora también podemos restablecer nuestro Camt Aquí obtenemos un par de opciones, soft, hard o mix Por ahora, cancelemos esto. Como podemos ver este control fuente es muy confuso para las sucursales. Apenas uso este control fuente para sucursales. Para las sucursales, hemos instalado la extensión Git Lens, que es la gran herramienta. Aquí, da clic en el icono de Git Lens. Aquí al principio, obtenemos el ícono de la gráfica Commit. Da click en eso y mira, aquí tenemos Gráfica de Commit. Ahora para ver esto más claramente, cierro esta extensión de lente Git, y además cierro todos estos archivos desde la parte superior y hago clic en esta opción de abrir en el área Editor. Cerremos la ventana de la terminal. Ver esta gráfica se ve más clara. Ver, al inicio de este proyecto, tenemos historia lineal. Luego creamos los comentarios de las características de nuestra sucursal, y luego los fusionamos en la rama maestra. Después de eso, creamos otra rama y nuevamente, las fusionamos en master. Ahora en la parte superior, podemos ver aquí tenemos sucursal. Ahora, si hacemos clic en alguna sucursal, tenemos un par de opciones. Primero, hemos cambiado a otra rama, reiniciamos cambios, renombramos la rama, creamos rama , creamos etiqueta, etcétera Ahora vamos a crear una nueva sucursal aquí. Ingresa el nombre de la sucursal. Digamos que Vicksburg recorta el registro. Pulsa Enter, y aquí tenemos tres opciones. Crea una rama, crea y cambia, y cancela. Entonces seleccionamos Crear y cambiar. Ahora vamos a abrir un archivo, presionar Control más P o Comando más P, y openscrip punto Aquí, hacemos algunos cambios. Guarde este archivo y cometamos estos cambios. Así que ve a Source Control. Y aquí escribimos nuestro mensaje de compromiso. Digamos, trabajar en el registro para Fix Berg y hecho. Ahora, volvamos a la gráfica Commit. Mira aquí podemos ver nuestra sucursal activa actual es FixburgLargistration, y también obtuvimos Ahora bien, si hacemos clic derecho sobre la rama maestra, entonces obtenemos aquí más opciones, cambiamos a la rama, fusionamos con la rama actual, rebasamos, renombramos, y mucho más Ver, aquí obtenemos las mismas opciones que tenemos en el control de fuente. En la siguiente lección, veremos cómo podemos ver sucursales y fusionarnos en Github DesktraFaciation 62. Branch y Merge en Github para escritorio: Como sabemos, para las interfaces gráficas de usuario, tenemos dos aplicaciones. El primero es Github desktop y el segundo es Kraken. Si estás seguro de que quieres usarlo Kraken, entonces puedes saltarte esta lección y pasar directamente a la lección de Git Kraken Aquí está la interfaz de la aplicación de escritorio Github. Ahora para sucursales, tenemos aquí lista de sucursales. Ver, aquí podemos ver nuestra sucursal actual. Ahora para cambiar las sucursales, tenemos que simplemente dar clic en esa sucursal. Verás, nuestras sucursales cambiaron. Aquí en la parte superior, tenemos opción de crear nueva sucursal, lo cual es muy sencillo. Ahora aquí en la parte inferior, tenemos opción para rama selector se fusione en rama maestra Seleccionemos eso y aquí, tenemos que seleccionar la rama que queremos fusionar. Digamos FixBurgrGISTRation, que creamos Haga clic en FixBurgrgistration. Seleccionemos Camt de fusión de tarifas. Si tenemos conflicto, entonces podemos resolverlo desde el código VS y luego continuar la fusión. Aquí obtenemos el mensaje de fusión exitosa, y si verificamos nuestro historial de commits, entonces puedes ver merge commit. Ahora, si queremos acceder a más opciones de sucursal, entonces tenemos este menú de sucursal. Aquí, podemos crear nueva rama, renombrar, eliminar, comparar, fusionar en rama actual, squash merge, rebase, etcétera Ahora déjame mostrarte comparación. Entonces como comparado con rama, y aquí tenemos opciones para comparar. Pero como puedes ver aquí, no podemos ver correctamente el historial de commit con ramas. Por eso a muchos desarrolladores no les gusta Gitub desktop. Si te gusta el escritorio Gitub, entonces puedes usar el historial de Commit del código VS para ver las commits y la rama y luego usar Merge Tool en la aplicación de escritorio Github Esta es mejor opción. En definitiva, la elección es suya. 63. Ramificación y fusión en GitKraken: Ahora, vamos a abrir la aplicación Git Kraken. La historia penal sigue siendo mi corazón. Mira lo hermosa que se ve. Podemos ver claramente las ramas y el historial de confirmaciones mucho mejor que usar el código VS o la aplicación de escritorio Github. Ver, aquí tenemos gráfica clara para sucursales, que podemos entender fácilmente. En la parte superior, podemos ver lista de sucursales. Y si seleccionamos alguna sucursal, entonces podemos cambiar a esa rama. Muy sencillo. Déjame mostrarte cómo podemos crear una nueva sucursal. Haga clic derecho sobre la sucursal y aquí tenemos un montón de opciones. Seleccionemos Crear una nueva sucursal. Aquí, le damos nombre de sucursal. Digamos barra de características Cerrar sesión. Aquí podemos ver que obtenemos Auto switch a esa sucursal. Ahora hagamos algunas amas en esta rama. Volver al código VS openscrip dot sple y simple al fin, nosotros en la consola dot log, implementamos la función de cierre de sesión Los cambios y vamos a comprometer estos cambios. Dar el mensaje de confirmación. Digamos implementar la función Cerrar sesión y comprometerla. Consejo rápido aquí, si queremos ver la rama activa actual, entonces podemos ver desde aquí en el código VS. También desde aquí, podemos cambiar a la otra rama. Volver a la rama Master, y aquí también const dot log y agregamos actualizaciones en el archivo script dot js También vamos a comprometernos con message, update script gs file. Sepa, este no es un buen mensaje de confirmación, pero esto es solo para demo. Ahora volvemos a ello Kraken y ya podemos ver como rama consigue divergir Lovely Ahora antes de hacer merge, veamos cómo podemos comparar dos ramas. Seleccione la sucursal de cierre de sesión y manténgala segura. Y seleccionar la otra rama que es master. Ver en el lado derecho, tenemos diferencia de dos ramas, y debajo de eso, tenemos lista de archivos que se ven afectados. Si seleccionamos el archivo, entonces conseguimos que el archivo se abra con los cambios. Intencionalmente cambio aquí la misma línea, así que tenemos conflicto en la línea tres y vamos a fusionarnos. Seleccione rama maestra y pata derecha en la rama de cierre de sesión que queremos fusionar Aquí tenemos fusión, y también tenemos rebase Seleccionemos Fusionar. Mira, aquí tenemos conflicto, y aquí obtenemos todos los archivos conflictivos Seleccionamos script dot archivo JS, y aquí obtenemos esta hermosa herramienta de fusión. Aquí en el lado izquierdo, tenemos cambios desde el maestro, y lado derecho, tenemos cambios de rama Logout, y en la parte inferior, tenemos salida final Aquí, podemos seleccionar las ramas seleccionando la casilla de verificación, y también podemos seleccionar las dos. También podemos eliminar de aquí, y si tenemos más de un conflicto, entonces podemos verlos desde aquí flecha arriba y abajo. Ahora, cuando satisfacemos con nuestros conflictos, entonces simplemente guardamos los cambios de aquí. Ahora en el lado derecho, tenemos lista de archivos de etapa. También tenemos listo el mensaje de compromiso. Ahora llegamos aquí dos opciones, Comte y merge, y a punto de fusionarse Vamos por Commit y fusionarnos. Ver aquí en la parte superior, obtenemos T merge Comte Muy sencillo y fácil. Ahora imagina que obtenemos error en nuestro código de esta fusión. También podemos revertir o rebasar nuestro Commit. Haga clic derecho en la opción Commit y seleccione Revert Commit Pediremos confirmación para kat inmediato. Seleccionamos sí, C, aquí conseguimos revertir Kumt Ahora bien, si quieres restablecer la amida a esta en medio antes de que hagamos la fusión, entonces podemos escribir click aquí y seleccionar reset. Aquí, obtenemos tres opciones, suave, mixta y dura. Ya vimos ese derecho. Ahora aquí hay una cosa. Imagina que no aprendes los comandos git antes usar Git Kraken o cualquier interfaz gráfica de usuario, entonces definitivamente pasarás al estado confuso Por eso decido enseñarte primero comandos Git y luego interfaces gráficas de usuario como Git up desktop y Git cracon Aquí vamos por el restablecimiento completo y nuestros comandos merge y revert se han ido Así podemos trabajar con ramas y fusionarnos en el Git Kraken Sé que esta sección es poco más larga, pero todas estas son lecciones de fusión muy importantes. Entonces hiciste un gran trabajo. Date un pequeño capricho, escucha algo de música, juega algunos juegos, o da un nuevo paseo. Continuaremos nuestro recorrido de dominio de kits en la siguiente sección Entonces nos vemos en la siguiente sección. 64. Sección 05 Trabaja con un equipo: Bienvenido a la quinta sección del curso Ultimate Kit. En esta sección, veremos cómo podemos trabajar en equipo usando Git. Actualmente nuestro repositorio en nuestro entorno local, pero en el mundo real, tenemos que trabajar en repositorio en Cloud. Entonces podría preguntarse, ¿cómo podemos trabajar con otros miembros del equipo en una empresa? Aprendimos cómo podemos obtener cambios de otros miembros del equipo, publicar nuestros cambios, solicitudes de extracción, problemas y mucho más cosas Sé que estás emocionado por esta sección, y yo también estoy emocionado por eso. Entonces, sin perder el tiempo, entendamos cómo trabajamos en equipo en un solo proyecto usando Git. 65. Descripción general del trabajo en equipo: Entonces como te dije, hasta ahora solo estamos trabajando localmente. Pero en el mundo real, no trabajamos solos. Hay muchos desarrolladores trabajando en un solo proyecto, y es por eso que veremos la vista lateral de pájaro de cómo los desarrolladores trabajan juntos en el mismo proyecto usándolo. Entonces déjame hacerte una pregunta sencilla. Aquí está nuestro repositorio. ¿Cómo crees que otros miembros del equipo pueden trabajar con este repositorio? Una solución es que alojamos este repositorio en algún lugar del servidor y todos los desarrolladores trabajan en el repositorio único. A esto se le llama como sistema centralizado de control de personas. Ahora bien, ¿y si este servidor en el que teníamos nuestro repositorio se desconectaba o va en el mantenimiento? Entonces todos los desarrolladores tienen que sentarse y esperar a que el servidor salga del mantenimiento. Este enfoque no está funcionando correctamente. Ahora, otra solución es para cada desarrollador, les damos repositorio en su propia PC o laptop. No dependen de ningún servidor. Pueden trabajar en cualquier momento en su repositorio. Esto se denomina como Vers distribuidos y sistema de control, y Git es el ejemplo de este sistema distribuido Vs y control. Ahora podrías preguntar si todos los desarrolladores trabajan en su propio sistema, entonces, ¿cómo pueden colaborar con los miembros del equipo? Para trabajar en equipo, adherimos un repositorio centralizado entre todos los desarrolladores. Todos los desarrolladores tienen su propio repositorio, pero también tenemos un repositorio central que utilizan para la colaboración. Déjame explicarte esto con ejemplo del mundo real. Supongamos que este eres tú y este soy yo. Aquí estamos trabajando en un mismo proyecto, que es, digamos, aplicación de comercio electrónico. Ahora primero, clonaremos nuestro proyecto existente para los dos en nuestro sistema personal. Ahora suponga que trabaja en su tarea, hace algunas cámaras, y cuando esté listo, empuja estos cambios en este repositorio. Ahora tenemos actualizaciones en el repositorio, así que me avisan con eso. Abro este repositorio y tire de los cambios en mi sistema. Ahora mi código y el código de este repositorio se vuelven iguales. Pero imagina que llego aquí conflicto. Resuelvo el conflicto aquí en mi máquina y luego empujo mi código a este repositorio. Ahora, otros desarrolladores y tú puedes sacar este código actualizado y seguir trabajando en este proyecto. Esto se llama un flujo de trabajo centralizado y obviamente obtener seguir este flujo de trabajo centralizado. No te confundas. El flujo de trabajo centralizado y el sistema de vers y control centralizado no es lo mismo. Son cosas distintas, solo el nombre son similares. Consigue seguir este trabajo centralizado Ahora, alguna compañía usa su propio servidor privado para alojar este repositorio en su empresa, pero mantener un servidor propio es poco costoso para las nuevas empresas. Entonces, a las nuevas empresas les gusta usar algún servidor basado en la nube que pueda alojar su repositorio de forma privada. Esta es una opción barata y buena para nuevas empresas y startups. Son muchas las empresas que brindan este tipo de servicios en la nube para el repositorio de hosting, y adivina la correcta. Github es una de las plataformas de alojamiento de repositorios. También tenemos Gitlab, Bitbucket, GIT y muchos Pero todos sabemos que Github es una de las plataformas más populares, por lo que usaremos Github. Estás utilizando cualquier otra plataforma de hosting, aún así, puedes continuar este curso porque estamos hablando de trabajar en equipo. Realmente no importa qué plataforma de hosting uses. Hagas lo que hagas en Github, creo que todos los conceptos básicos lo puedes hacer en otra plataforma de hosting de repositorios. Ahora bien, ¿y si estás trabajando solo? En esta situación, también, puedes usar Gitub para almacenar nuestro código como respaldo Incluso del 20 al 40% de los desarrolladores utilizan Gitub para almacenar su línea y administrar su currículum En el futuro, no pierden su código. También estará disponible en su cuenta de Github. Es beneficioso para ti aprender esto. Ahora a partir de la siguiente lección, veremos este flujo de trabajo en proceso. Estoy muy entusiasmado con ello. 66. Cómo subir un proyecto a github: Ahora antes de comenzar a crear un nuevo repositorio, muchos estudiantes me preguntan, ¿cómo puedo subir nuestro Proyecto Git existente en Github? Déjame mostrarte cómo podemos subir proyectos locales en Github. Primero, veremos subiendo proyecto usando Github Dektop y después de eso, te mostraré para Entonces primero, abro Github Dektop aquí, primero, revisamos nuestro repositorio abierto o Si no está disponible en esta lista, entonces vamos al archivo en el repositorio Local y simplemente navega a esa carpeta y abrimos nuestro proyecto aquí. Ahora, si no tenemos ningún cambio, entonces llegamos aquí directamente publicar la opción de repositorio. De lo contrario, tenemos también esa opción aquí después de la opción de sucursal. Aquí podemos ver este repositorio solo disponible en su máquina local. Al publicarlo en GitHub, puedes compartirlo y colaborar con otros. Así que da click en este botón de repositorio público. Obtendremos este pop up que pide nombre del repositorio. Le doy pista de Tas para Git. Si quieres escribir una descripción, entonces puedes escribirla aquí. A partir de aquí, podemos hacer que nuestro repositorio sea privado o público. Si hacemos que nuestro repositorio sea república, entonces cualquiera en Internet puede ver nuestro código. Una cosa es, si quieres colaborar con otros, entonces tenemos que hacer público nuestro repositorio. Si lo hacemos privado, entonces tenemos que pagar el repositorio privado para la colaboración. Si solo quieres almacenar código, entonces podemos usar repositorio privado. Estoy desmarcando esta casilla para repositorio público y simplemente haga clic en publicado Véalo publicar. Si quieres verificar, entonces podemos revisar nuestro repositorio en Github usando este botón. Así de sencillo es. Ahora déjame mostrarte cómo podemos hacer lo mismo usando la aplicación Git Kraken Abra la aplicación Git Kraken y seleccione nuestro repositorio que desea publicar Ahora, antes de publicar el repositorio, necesitamos conectar nuestra cuenta Github con la aplicación Get Kraken Así que haz clic en este botón de configuración desde aquí y ve a la pestaña de integración. Aquí tenemos par de servicios de hosting por defecto es sec Github y mira aquí no nos conectamos. Conectémonos a Github. Te pedirá que inicies sesión con tu cuenta de Github. Yo inicio sesión con mi cuenta. Nos pedirá inicio de sesión o autorización. Autorizo y aquí escribo mi contraseña y simplemente la abro Crack y aplicación. Consulta aquí obtenemos nuestra cuenta. Ahora vamos a cerrar estos ajustes. No lo necesitamos. Ahora para publicar un repositorio, necesitamos primero agregar remoto, clic en este ícono de Cloud que es para remoto y aquí podemos ver que tenemos cero remoto. Para que podamos crear nuevos. Aquí, podemos ver que tenemos Github seleccionado, y pide nombre de repositorio, nombre remoto, que vemos en esta lista remota, descripción del repositorio, y también podemos hacerlo público o privado. No te preocupes, simplemente haz clic en Crear control remoto y presionar el botón Revs locales Y luego recibimos mensaje de éxito. También podemos verlo en github.com. Esto parece un poco complicado porque empujamos a todos nuestros Camts de una sola vez Pero en el mundo real, primero creamos nuestro repositorio y luego trabajamos en él. Así que no te preocupes por eso. Ahora en la siguiente lección, crearemos un nuevo repositorio fresco usando sitio web de Github y aprenderemos los conceptos de sección en su repositorio. Para que no te confundas con este proyecto maestro. 67. Cómo crear un nuevo proyecto en github: Así que abre github.com, y si no tienes cuenta de Gitub, entonces puedes crear fácilmente una nueva cuenta entonces puedes crear fácilmente Es realmente simple y fácil. Además, asegúrate de verificar tu cuenta de correo electrónico antes de crear un nuevo repositorio. Ya inicié sesión con mi cuenta aquí. Ahora para crear un nuevo repositorio, haga clic en este icono más. Aquí tenemos Nuevo repositorio, y también podemos importar repositorio desde otro lugar. Vamos por un nuevo repositorio. Aquí primero ingresamos nuestro nombre de repositorio, que queremos dar. Digamos, CardWishGT porque tengo repositorio Cardwisname Ahora aquí, podemos escribir una descripción de este repositorio. A continuación, tenemos opción pública o privada. Como te dije antes, si seleccionamos privado, entonces tenemos que pagar por trabajar en equipo. Entonces seleccionamos aquí público. Ahora aquí tenemos un par de opciones. Puede agregar el archivo ad me en el que podemos escribir una descripción larga para nuestro proyecto o página web, y también podemos seleccionar el archivo Getting nor. Aquí tenemos lista de idiomas. Por ahora, no lo queremos, y damos click en Crear Repositorio. Y luego creamos un nuevo repositorio. Aquí en la parte superior, podemos ver nuestro nombre de usuario y slash nuestro nombre de repositorio Si alguien te pide que veas tu código, entonces puedes darle esta URL de Github. Pero para eso, necesitas repositorio público. De lo contrario, la gente no lo verá. Ahora aquí tenemos nuestra lista de sucursales. Actualmente, tenemos sólo una sucursal, que es principal. Esta principal es igual que nuestra rama maestra. Github llamó rama maestra como principal. Después de eso, tenemos número de sucursal y también obtenemos número de etiquetas. Aquí podemos buscar un archivo específico. Además, podemos crear un nuevo archivo y también podemos subir archivos. Ahora en esta caja cuadrada, podemos ver nuestro proyecto. Aquí podemos ver nuestro último Commit. Ahora podrías preguntar, no cometimos nada. Esta es la confirmación que Github crea para crear un nuevo repositorio. Aquí, podemos ver Commit tiene tiempo cuando se compromete y todos los commits. Vamos a comprobar esto. Aquí obtenemos la lista de commits. Podemos filtrarlo por usuario desde aquí y también podemos filtrarlo por tiempo. Ahora desde aquí, podemos ver commits por ramas, y si queremos ver más detalles sobre commit, entonces podemos dar click sobre esto. Aquí, obtenemos la sucursal que es principal. Obtenemos el nombre de usuario y también obtenemos tiempo. Después de eso, podemos ver archivo cambiado con dos adiciones y cero eliminación y podemos ver que líneas aquí. Bueno. Volver a nuestra página de códigos. Aquí obtenemos la lista de archivos de proyecto y en el lado derecho, también obtenemos el mensaje de confirmación. En qué comando se agrega o cambia este archivo. También podemos ver el contenido del archivo desde aquí. Hay una pequeña introducción sobre el repositorio Github. Ahora en la siguiente lección, veremos cómo podemos agregar miembros del equipo en este repositorio. 68. Agregar miembros del equipo al proyecto: Ahora actualmente nuestro repositorio es público, pero aún así nadie puede empujar commits en nuestro repositorio. Se podría decir que ya hacemos público nuestro repositorio y aún así nadie puede empujar commits. ¿Por qué? Repositorio público significa que todos pueden ver nuestro repositorio, pero necesitamos agregar a los miembros de nuestro equipo como colaboradores en este repositorio. Aquí vamos a la opción de configuración. En la sección de acceso, obtenemos la pestaña de colaboradores. Aquí podemos ver que tenemos cero contribuyentes. Agreguemos un miembro del equipo a este proyecto. Aquí agregamos un miembro, y podemos buscar miembros del equipo cuenta usando nombre de usuario o nombre completo o cuenta de correo electrónico. Escribo mi segunda cuenta. Esta es mi nueva cuenta que creé para este curso. Si no acepto tu invitación, entonces lo siento por eso porque probablemente no accedo a esta cuenta en el futuro. Si no tienes otra cuenta, entonces puedes crear una segunda cuenta para esta sección, o puedes invitar a tus amigos que también quieran aprender Git. De esta manera, es mejor que entiendas estas lecciones. Ve como ese usuario y haz clic en agregar a este repositorio. Aquí, tenemos un colaborador, pero como podemos ver, tenemos invitación pendiente Cuando agregas a alguien a tu repositorio, Git le envía solicitudes de colaboración en su correo electrónico. Si la persona acepta la invitación, entonces enhorabuena. Tienes colaborador. Pero esa persona también tiene opción de rechazar. Así es como podemos agregar miembros del equipo o colaboradores en nuestro repositorio. 69. Clona el repositorio de Git en nuestra máquina: Entonces, como sabemos, creamos un nuevo repositorio desde nuestra cuenta de Github. Pero, ¿cómo podemos empezar a trabajar en ese repositorio? Porque no tenemos este repositorio en nuestra máquina. Veamos cómo podemos agregar o clonar repositorio desde Github a nuestra máquina. Ir a la opción de código, y aquí obtenemos el enlace de nuestro repositorio en Github. Copia esto y abre la carpeta en la que quieres clonar este repositorio. Entonces estoy en mi carpeta de proyectos, abra Gitwsh o terminal en esta Aquí solo escribimos Gate, clonamos, y pegamos nuestra URL. Si estás usando Windows, entonces Control plus V no funcionará. Entonces haga clic derecho aquí y vea, tenemos opción de página y también tenemos acceso directo para eso. Ahora si ejecutamos este comando, entonces gate clona este repositorio con nombre de repositorio como nombre de carpeta. Además, si quieres cambiarlo, entonces también podemos hacerlo. Digamos que solo quiero cartwish y golpear Enter. C, consigue clonar este repositorio. Entonces ahora tenemos todos los cometas, todas las ramas, literalmente todos los detalles sobre el repositorio tet Vamos dentro de esta carpeta cartws. Así que cambia directorio a cartwis. Ahora veamos los abrigos, así que git log, dash dash p line, dash dash all, dash graph. Ahora aquí obtenemos comando único, que es comando inicial. Aquí, podemos ver que nuestro puntero de cabeza está en este comando, pero tenemos dos punteros más aquí, origen principal y cabeza de origen ¿Quién creó esto y por qué? Entonces como sabemos, headpointer se usa para saber en qué commit estamos, y main es nuestra rama predeterminada Ahora cuando clonamos nuestro proyecto desde GitHub, Git crea una rama remota y la nombra como origen. Esta no es rama original. Esto es solo sucursal remota. Si tratamos de cambiar a la sucursal, entonces esto no va a funcionar. También podemos comprobarlo usando git branch. Mira aquí solo tenemos una sucursal que es principal. Ahora, déjame mostrarte algo útil. Si escribimos puerta remota, entonces aquí obtenemos nuestro repositorio remoto que es origen. Podría preguntarse, ¿qué es el repositorio remoto? Un repositorio remoto es el proyecto o repositorio que está alojado en el servidor como Github o beat Bucket. En palabras simples, repositorio remoto es, que no está en nuestra máquina local. Nuestro repositorio actual no solo está en nuestra máquina local, se almacena en ubicación remota como en Github. Este repositorio remoto, que se llama como origen, se utiliza para proporcionar información sobre nuestro proyecto Github. Al igual que en qué sucursal trabajan actualmente los desarrolladores y más. Ahora, por esa razón, Git crea dos punteros más Origins main o master y origins head Déjame explicarte eso con el ejemplo. Supongamos que tú y yo trabajamos en el mismo proyecto y ambos clonamos nuestro proyecto desde Github. Ahora cuando clonamos nuestro proyecto desde GitHub, entonces Git creamos estos dos punteros orígenes main y origin head Ahora supongamos que trabajo en una característica y empujo la Cam en nuestro repositorio. Obtener mover este puntero principal de origen a esta tarde se reunió en la rama principal. Entonces, esencialmente, origin main nos dirá dónde ocurren los últimos cambios en nuestro repositorio Github. Entonces, si alguien más hace otro cometa, entonces el puntero principal de origen se mueve a ese cometa Se podría decir, entiende acerca de los orígenes principales, que representan los últimos cambios en nuestro repositorio. Pero por qué esta cabeza de corte de origen también se mueve con este origen s principal Honestamente, no se mueve. Está en la misma rama. Origin s head se utiliza para decirnos cuál es la última sucursal es checkout o en palabras simples, que es la última vista de sucursal o trabajo de cualquier miembro del equipo. Supongamos que aquí tenemos esta característica productos página rama. Si eres yo o algún desarrollador cambia a alguna de la otra sucursal, entonces esta cabeza de origen apuntará a esa sucursal. Entonces así es como funciona este puntero. Entonces, para resumir, solo se usa el puntero de cabeza para decirnos en qué commit estamos trabajando actualmente Origin Min o Origins Master nos dicen dónde ocurren los últimos cambios en nuestro repositorio Github. Por esto, podemos conocer los últimos cambios en nuestro repositorio Github. Origins HAD nos dice, cuál es la última vista de sucursal o trabajo de cualquier miembro del equipo. No te preocupes por esto. Todos ustedes las dudas se sienten claras cuando ven todo esto en acción. 70. Obtén los cambios: Entonces como sabemos, este es nuestro repositorio Gitub, y este es nuestro repositorio local, que clonamos desde el github Ahora bien, estos dos repositorios no están conectados entre sí. Entonces, cuando alguien pone los cambios en este repositorio de gitub, entonces no obtenemos esos commits automáticamente Necesitamos ejecutar el comando Git fadge para obtener los nuevos commits en nuestro repositorio local Aquí tenemos que prestar atención. Actualmente, en nuestro repositorio local, estamos trabajando en el cometa C one Nuestro principal, o podemos decir maestro puntero sigue en este cometa. Pero como les dije en la lección anterior, nuestro puntero principal de origen avanzará porque representa los últimos cambios en el repositorio remoto. Al usar el comando Git patch, obtenemos decommit, pero nuestro puntero maestro o principal todavía está en nuestro C one commit Entonces nos descomprometemos en nuestra historia, pero nuestro directorio de trabajo aún no se ve afectado, y por eso, no obtenemos ningún conflicto Ahora bien, si te sientes cómodo para aplicar esos cambios en tu directorio de trabajo, entonces podemos ejecutar git merge, y este nombre de puntero, que es origin Min. Entonces aquí no tenemos ninguna rama diversa. Qué tipo de fusión realiza Git. Absolutamente correcto. Git realizar pase para o fusionar. Y si conseguimos algún conflicto, entonces los resolvemos como estamos resolviendo previamente y luego hecho. Digamos que este parche de Git prácticamente. Entonces en este navegador, me conecto con mi otra cuenta de Github. Y en esta máquina, tengo mi cuenta original, que es que Dios los bendiga. Aquí sólo tenemos mi archivo. Entonces vamos a cambiar en este archivo y simplemente comprometerlo. Da click en este archivo, y desde aquí, podemos editar este archivo y cambiar este texto. Esto es para el segundo commit y simplemente comprometa los cambios. Aquí, podemos escribir el mensaje de compromiso. Lo dejo como está. Aquí, asegúrate de seleccionar Commit to main branch. También podemos crear una nueva rama a partir de aquí con este commit. Pero veremos esta opción en la próxima lección. Simplemente haga clic en Commit. Ahora volvamos a nuestra ventana de código, mira, aquí tenemos dos cometas. Ahora si vemos en nuestro repositorio local, entonces aquí solo conseguimos uno conocido. Ahora veamos cómo podemos recuperar repositorio de nuestro repositorio remoto Escribimos git fetch, y luego escribimos nuestro nombre remoto que es origen No escribimos nada, entonces por defecto, Git toma origen. Verás, es parchear. Ahora vamos a revisar nuestro historial. ver, llegamos a los cometas, y también podemos ver origen principal y cabeza de origen se mueve a este cometa, pero nuestra cabeza sigue aquí Ahora, veamos cómo podemos agregar estos cambios en nuestro directorio de trabajo. Sugiero que escribamos git merge, y escribimos nuestro nombre de puntero, orígenes principales. Y lo hicimos. Mira aquí nos ponemos rápidos para nuestra fusión y también podemos ver en nuestro historial headpointer se mueve a nuestro segundo comando y también abrimos archivo IDM en código VS, luego obtenemos el archivo RDM actualizado 71. Haz los cambios: En la lección anterior, vemos para obtener los últimos cambios del repositorio remoto, necesitamos usarlo comando patch y luego para agregar cambios en nuestro directorio de trabajo, necesitamos fusionarlo. Como podemos ver, este es un enfoque de dos pasos. Podemos hacer esto en un solo paso también, y ¿sabes por qué comando es tirar? Supongamos que tenemos estos amds en repositorio local y repositorio remoto Aquí nos comprometemos en nuestro repositorio local y aquí otro miembro del equipo también agregamos amid al repositorio remoto. Ahora bien, si hacemos comando git pool, entonces Git agrega este commit sit en nuestro repositorio local y origen Min Pointer muévase a esto en medio. Ahora git fusiona estos dos cambios y haz un nuevo abrigo. Ahora a muchos desarrolladores no les gusta este enfoque porque podemos ver que está creando nuevos kamit merge y además obtenemos comandos diverge La otra solución, en lugar de hacer merge, también podemos realizar rebasing Así podemos ejecutar git, pull, rebase command, y eso rebasará nuestro comité a este origin slash main commit, y así es como obtenemos un historial lineal y claro Ahora bien, ¿cuál es la mejor opción para pull Merge o rebase? Honestamente, esto realmente depende de nuestra situación. Lo más probable es que tu manager te diga que uses merge o rebase, no te preocupes por eso Personalmente me gusta usar rebase en lugar de usar merge porque nuestro historial de commits se mantendrá limpio. Entonces veamos esto en nuestro repositorio. Entonces, para la solicitud de extracción, primero necesitamos confirmar algunos cambios en nuestro repositorio local, así como en el repositorio remoto. Entonces abro nuestro repositorio local en el código VS y creo un nuevo archivo, digamos, scrap dot js, justo aquí, consola dot log. Este es archivo raspado. Guarde los cambios, y vamos a comprometerlos. Volver a Git Bash it Ed period, c staging y Gitatm createscript c staging y Gitatm createscript dot Jsfile para JavaScript. Ahora vamos a revisar nuestro historial. Ver, aquí obtenemos tres Camits y nuestra cabeza se mueve a nuestro último amit y origen principal y la cabeza de origen sigue en este Ahora hagamos Cait en nuestro repositorio remoto. Dirígete a la segunda cuenta. Y aquí creo un nuevo archivo a partir de aquí, y aquí escribimos nuestro nombre de archivo. Digamos que los planes puntean TxD. Físicamente, escribiré planos en este expediente. Entonces paso número uno, crear un diseño de sitio web básico para este proyecto. Ahora, vamos a comprometernos esto, así que comprometa los cambios. Dejo este mensaje de compromiso tal como está, y voy por Commit. Hecho. Ver, aquí tenemos tres commits. Ahora volvamos a nuestro Git Bash. Aquí ejecutamos el comando git pull, así esto agregará nuestro repositorio remoto commit en nuestro proyecto y luego lo fusionará. Se pedirá mensaje de compromiso. No quiero cambiarlo, así que cierra esto. Ver, la fusión está completa. Comprobemos nuestro historial. Mira, aquí conseguimos el commit de fusión, y también conseguimos los abrigos de buzos Ahora déjame mostrarte cómo podemos rebasar con pull. Antes de eso, deshagamos esta commit de fusión. Entonces git reset, d dash duro, y queremos ir un paso antes de cabeza. Así que dirígete a la una. Consulta nuestro historial. Verás, reiniciamos nuestra fusión, y obtenemos esta sucursal separada. Así que vamos a ejecutar git pull, rebase. Básicamente, le estamos diciendo a Git que rebase nuestro commit actual con el puntero principal de origen y vea que obtenemos el mensaje de éxito Comprobemos nuestra historia una vez más. Ver, obtenemos historia lineal, y este origen principal es mover aquí. Ahora en la siguiente lección, veremos otro comando muy útil, que es el comando push. 72. Lleva cambios al repositorio remoto: Ahora, actualmente, en nuestro repositorio local, tenemos cuatro cometas, pero en nuestro repositorio remoto, solo tenemos tres kamets No tenemos este en. Si queremos agregar esta kamide al repositorio remoto, entonces tenemos que usar el comando push de Git Ahora, como sabemos, este principal pasará a nuestro último kamid también en nuestro repositorio, origen principal también se moverá a este cometa Nosotros lo escribimos push. Aquí, tenemos que escribir nuestro nombre de repositorio remoto que es origen. Después de eso, abrigo que queremos empujar, que es principal. Actualmente, también estamos en main, así que podemos eliminar este main también podemos eliminar origin porque ese es repositorio remoto predeterminado. Ahora a veces puede pedirte tu nombre de usuario y contraseña de Github antes de empujar el código. Hay que escribirlo cuando se lo pida y ya terminamos. Comprobemos nuestro historial. Consulta aquí nuestro origen Min se traslada a nuestro mando principal. Si queremos verificar, entonces podemos consultar nuestra página de GitHub. Mira aquí sacamos cuatro amets y si lo comprobamos aquí, entonces conseguimos a los Camets Empujamos con éxito nuestro código a nuestro repositorio remoto. Ahora déjame mostrarte otra situación. Supongamos que aquí tenemos tres gametos y en repositorio remoto, tenemos sólo dos ametos Ahora antes de empujar este camete al control remoto, nuestro miembro del equipo empuja otro kamit aquí, si empujamos nuestro código, entonces nuestro comando push fallará Me puedes decir por qué? Derecha. En esta situación, nuestro historial de repositorios locales y el historial de repositorios remotos son diferentes. Si Git todavía nos permite empujar, entonces podemos perder este compromiso de miembro del equipo. Y por eso Git falla nuestro comando push. Ahora a veces muchos desarrolladores usan Git push F para empujar con fuerza nuestro código Entonces cuando ejecutamos este comando, luego eliminamos este amit y agregamos nuestro amid en remoto Pero esa no es una buena práctica porque esencialmente, estamos quitando el trabajo de los miembros de nuestro equipo. Entonces si no tienes ninguna razón principal, entonces en mi sugerencia, no uses la fuerza de empuje. Ahora bien, ¿cuál es la solución para esto? Entonces, si nuestra solicitud push falla, entonces primero, hacemos pull request. Esto agregará este gummit en nuestro repositorio local, y luego usando merge o rebase, podemos agregar cambios en nuestro amid y luego empujar nuestros cambios a remoto Así que ahora nuestro repositorio local y nuestro historial de repositorios remotos son los mismos. Entonces los comandos más útiles para Git son git pull y Git push porque estos dos comandos se usan mucho para trabajar con team. 73. Llevar las etiquetas a distancia: Ahora, supongamos aquí en esta etapa, nuestra aplicación está lista para la versión 1.0. ¿Recuerdas el comando para agregar etiquetas? No te preocupes, puedes ver mi hoja de Git Git. Así que aquí escribimos git tag versión 1.0. Este comando agregamos etiqueta a nuestro commit actual. Si queremos darle esta etiqueta a commit específico, entonces podemos escribir aquí ese puntero o commit tiene. Por ahora, agreguemos etiqueta a nuestro último commit. Verifiquemos esto. Registro de git. Ver, nuestro último commit está marcado como etiqueta versión 1.0. Ahora aquí, quiero decirte algo. Esta etiqueta solo es visible en nuestro repositorio local. Esto no es visible en el repositorio remoto de Github. Entonces, ¿cómo podemos empujar nuestras etiquetas al repositorio remoto? Para eso, tenemos que escribir git push. Aquí escribimos nuestro nombre remoto que es origen. Aquí escribimos nuestro nombre de etiqueta que queremos empujar, que es person 1.0. Hecho. Ahora verifiquemos en el sitio web de Github, obtenemos nuestra etiqueta o no. Mira, aquí tenemos una etiqueta. Veamos esto con más detalle. Aquí, podemos ver el nombre del autor, hora, y también podemos descargar el código fuente completo desde aquí. Lo uso mucho cuando estoy trabajando en grandes proyectos. Entonces así es como podemos empujar la etiqueta. Ahora supongamos que queremos eliminar esta etiqueta, así podemos escribir el mismo comando aquí, agregamos dash delete. Ver, se ha eliminado correctamente. Ahora bien, si revisamos nuestro historial, entonces podemos ver que la etiqueta sigue aquí porque ese comando acaba de eliminar la etiqueta de nuestro repositorio remoto. Si también queremos eliminar esta etiqueta del repositorio local, entonces escribimos Get tag, D, escribimos nuestro nombre de etiqueta. Ver, también se elimina de nuestro repositorio local. 74. Crea lanzamientos para Github: Entonces en la lección anterior, vemos cómo podemos dar etiquetas. Pero aquí hay una cosa sobre las etiquetas. En etiquetas, no podemos describir lo que hay dentro de la versión 1.0. Entonces, si un nuevo desarrollador se une a nuestro equipo, entonces tenemos que explicarle qué hay dentro de esta versión. De lo contrario, tenemos que decirles para ver todos los cambios. Pero no te preocupes, Github brinda una solución muy útil para esta situación. En Github, podemos agregar lanzamientos para describir lo que hay dentro de esta versión. Entonces vamos sección, y aquí tenemos lanzamientos. Actualmente, no tenemos ningún lanzamiento, así que creamos un nuevo lanzamiento. Ahora en la parte superior, tenemos opción para seleccionar la etiqueta. Actualmente, no tenemos etiqueta porque la borramos en la lección anterior. Aquí mismo, nuestro nombre de etiqueta verson 1.0, y creamos una nueva etiqueta Después de eso, seleccionamos una sucursal, que es principal. Aquí podemos escribir el título de nuestro lanzamiento. En su mayoría, escribimos el mismo nombre que nuestro nombre de etiqueta, pero también puedes dar tu nombre. Depende totalmente de ti. Ahora en esta área de texto, podemos describir nuestros cambios y características. Entonces primero, seleccionamos rumbo de aquí y aquí mismo, nuestro encabezado, digamos, detalles de lanzamiento. Quieres ver vista previa, entonces también podemos ver eso. Además, tenemos muchas opciones. Agreguemos viñetas para más detalles. Creemos el diseño básico del sitio web, arreglemos el error de diseño y diseñemos la página de inicio. Veamos la vista previa. Ver, obtenemos nuestros datos. Ahora en la parte inferior, también podemos adjuntar archivos binarios a esta versión. Si has compilado la versión de tu aplicación o cualquier archivo binario que quieras agregar, entonces puedes editar aquí. Si tu lanzamiento no está listo para publicar, entonces podemos verificar este lanzamiento como pre-lanzamiento. Los miembros del equipo saben que esto no está listo para producción. Ahora, supongamos que estamos listos para liberar. Desmarco esta casilla y hago clic en publicar. Mira aquí obtenemos nuestro nuevo lanzamiento y podemos ver detalles, alguna información básica, y como nuestro texto, también obtenemos aquí nuestro código fuente. El lanzamiento es una característica muy hermosa para trabajar en equipo, y también podemos usarlo como documentación de nuestro recorrido de aplicación. Si vamos a la página principal, entonces en el lado derecho, obtenemos todos los lanzamientos de este repositorio. Entonces una cosa que quiero decirte es release es la característica de Github, no de Git. Solo podemos ver lanzamientos usando Github, no por línea de comandos. Ahora en la siguiente lección, veremos cómo se puede estar trabajando con rama en equipo? 75. Trabajar con ramas: Ahora veamos cómo se puede trabajar con sucursales en equipo. Aquí, creo una nueva rama con kit switch C feature slash ad to cart Ahora vamos a revisar nuestra lista de sucursales. C. Aquí obtenemos dos sucursales, principal y Agregar al carrito. Pero esta nueva sucursal sólo está disponible en el entorno local. Ahora bien, si los miembros de nuestro equipo quieren trabajar en la misma rama, entonces ¿cómo pueden hacerlo? Para eso, tenemos que empujar esta rama a nuestro repositorio remoto. O empujando lo que usamos, bien. Usamos git push origin mean para empujar cambios al origen. Pero aquí lo ponemos todo al día porque este comando sólo empujará códigos al control remoto, no a las sucursales. Escribimos aquí, puerta, empuje, aquí obtenemos este error de pétalo, que es decir que la característica de rama actual slash head to card no tiene rama aguas arriba También nos está dando sugerencias para resolver este error. Este comando establecerá esta rama ascendente en nuestro origen de repositorio remoto. Pero espera, ¿qué es esta rama upstream? ¿Qué pasará si establecemos rama upstream? Establecer una rama ascendente significa construir una conexión entre nuestra sucursal local y una sucursal en el repositorio remoto. Déjame explicarte con el ejemplo. Actualmente, esta es nuestra sucursal en nuestro repositorio local. Si subimos nuestra rama, lo que significa que construimos una conexión a, digamos, una rama llamada Origin slash feature slash Ed to card No te preocupes, esto es solo por ejemplo. Si empujas tu sucursal, entonces tiene el mismo nombre que le das. Ahora bien estas dos ramas están conectadas entre sí y también podemos decir rama aguas arriba también conocida como rama de seguimiento remoto. Se podría decir, entendemos que establecer una rama ascendente es construir una conexión entre local y una rama en el repositorio remoto. Pero, ¿por qué necesitamos esta conexión? ¿Cuál es el beneficio de hacer esto? El primer beneficio al establecer la rama ascendente es Git saber dónde publicar los cambios desde la sucursal local. Entonces, si empujamos los cambios desde la sucursal local, entonces por esta conexión, conoceremos dónde se agregarán estos cambios en el repositorio remoto, y también lo mismo se aplicará para tirar los cambios. Si nuestro miembro del equipo empuja algo a esta rama, entonces si sacamos esos cambios, conozca de dónde necesita buscar cambios Por lo tanto, buscará cambios de esta función de barra diagonal de origen de sucursal remota, diagonal agregar a la tarjeta a nuestra En general, al establecer una rama ascendente, nuestro flujo de trabajo es fácil de insertar y extraer cambios entre el repositorio local y remoto. Veamos cómo podemos establecer sucursal upstream para nuestra sucursal local. Y aquí, Git también nos da solución. Antes de eso, veamos nuestras sucursales actuales de rastreo local y remoto. Básicamente, vemos el nombre de la sucursal aguas arriba. Rama Git, V C, aquí obtenemos Min y su rama upstream es origen principal. Pero para las funciones cabeza a tarjeta, no tenemos ninguna sucursal ascendente o podemos decir que no tenemos sucursal de rastreo remoto. Si queremos ver la lista de rama de rastreo remoto, entonces también podemos tener comando para eso. Sucursal Git R para seguimiento remoto. Ver, actualmente, sólo tenemos estos dos punteros orígenes principal y origen slash head Vamos a establecer rama upstream o rama seguimiento remoto usando git push, dat, upstream, o aquí, podemos escribir atajo que es dU o upstream, aquí escribimos nuestro nombre remoto que es origen. Y después de eso, escribimos nuestro nombre de sucursal local, que es característica slash head to cart Recuerda, tenemos que escribir este comando solo la primera vez que empujamos nuestra sucursal. C, se empuja la rama. Ahora bien, si revisamos nuestras sucursales upstream, obtener la sucursal V C. Ahora aquí podemos ver la rama upstream para nuestra sucursal local, que es la característica de origen, slash head to card Además, si ejecutamos git branch R, C, se agrega la rama de seguimiento remoto. Vamos a verificarlo también en GitHub. Básicamente, tenemos una sucursal, refrescar la página y ver, aquí tenemos dos sucursales. Ahora podemos empezar a trabajar en esta sucursal de cabeza a tarjeta, igual que estamos trabajando en nuestra sucursal principal. Cuando queremos empujar nuestras gammas, entonces podemos empujarla en esta rama y otros miembros del equipo pueden ver que empujan cambios Si queremos eliminar este enlace entre la sucursal local y la rama de seguimiento remoto, entonces podemos escribir comando como este push D para su eliminación. Aquí escribimos nuestro nombre remoto, que es origen. Y luego escribimos el nombre de nuestra sucursal que es característica slash head to card Por lo que ahora retiramos la rama de seguimiento remoto. Si ejecutamos git branch, R, luego C, nuevamente, obtenemos estos dos punteros Y si ejecutamos git branch, VV, entonces aquí podemos ver que obtenemos origin feature slash head to card is gone También eliminemos esta sucursal de nuestro repositorio local. Para hacer eso, primero tenemos que volver a cambiar a la rama principal. Aquí escribimos Git branch D, y aquí escribimos nuestra rama name feature slash t to card and done so so so is how we can publish branch on our remote repository by setting upstream branch Ahora en la siguiente lección, entendemos en mundo real cómo los miembros del equipo trabajan con la rama. 76. Escenario del mundo real para trabajar con Branch: Vamos a entender trabajar con sucursales usando escenario del mundo real, se puede entender más claramente sin perder el tiempo. Este no es el ejemplo, esta es una historia real. Cuando me uní a mi primera compañía, tuve la oportunidad de trabajar en una característica, que es trabajar en el diseño de páginas de inicio. Esta característica, tengo que trabajar con Unati y ella es la empleada existente de esa empresa Tenemos que diseñar homepage para el sitio web de la compañía. Esa compañía estaba construyendo un sitio web como stackoverflow para problemas y soluciones Ella me dijo que trabaja en el diseño de tarjetas de preguntas, y tengo que trabajar en la sección de encabezado, pie de página y barra lateral. En primer lugar, creó una nueva sucursal llamada feature Ss Home Page, y comenzó a trabajar en el diseño de la tarjeta Qi. Pero aquí no tengo ni idea. ¿Qué está pasando aquí? ¿Cómo puedo trabajar con branch? Conozco los fundamentos de git, pero no tengo experiencia real. Primero clono el proyecto desde el Github y primero, ejecuto la solicitud de extracción para obtener los últimos cambios del repositorio remoto. También empiezo a trabajar en la misma característica de la rama de página principal de Sless Ambos estamos trabajando independientemente en la misma rama. Ahora terminó con su diseño, por lo que se comprometió con el código y luego empuja los cambios al repositorio remoto. Ahora ella me dice que empujó el código. Aquí de nuevo, pull request y obtener los últimos cambios y fusionarlo con mi código. Ahora después de algún tiempo, estoy listo con mis diseños, así que empujo los cambios y le informo. Ella ejecuta git pull request y la fusiona con su código. Después de 5 horas de hacer este pull and push, terminamos con el diseño de la página principal. Por último, empujo todos los cambios y le digo. Ella tira todos los cambios en la sucursal, y si consigue conflictos, entonces nos contactamos entre nosotros y resolvemos el problema. Ahora bien, este código va a probar y nuestro gerente revisa el código final. Si todo bien, entonces este código se fusiona en la rama principal o rebase o squash kms, cualquiera que sea la mejor opción Entonces esta característica barra inicio rama caída desde el mando A medida que eliminamos la sucursal del repositorio local. Ese es el escenario de trabajar juntos, o puedes ver cómo podemos trabajar en la misma rama que equipo. 77. Muestra práctica de trabajo con sucursales: Veamos el escaparate práctico de trabajar con sucursales. Podría preguntarse ¿por qué me estoy enfocando tanto en trabajar con sucursales? Porque este es el concepto más usado y poco confuso para los desarrolladores, y por eso te estoy mostrando paso a paso. Después de completar este curso, dominas trabajar con sucursales. Para simular esto, les mostraré ambos trabajos de BC. Trabajo en mi PC y además compartiré pantalla de nati PC. Esto es nats PC. Ahora aquí en este proyecto, C crea una nueva rama. Anteriormente, hemos visto cómo crear rama usando comandos, pero también podemos crear ramas usando Github. O abrir esta sucursal, desplegable, y desde aquí, podemos crear una nueva sucursal. Digamos diseñar Página principal y seleccionar, crear una rama de principal y listo. Creamos nuestra nueva sucursal y vemos aquí obtenemos esta sucursal está al día con principal La sucursal está en el repositorio remoto. Tenemos que buscarlo en nuestro repositorio local. Entonces aquí en esta terminal, escribimos git fetch para buscar esta rama Ver, aquí conseguimos nueva página de inicio de slash de diseño de sucursal. Ahora déjame mostrarte algo. Si escribimos rama Git, mira, aquí no obtenemos la nueva rama, pero podemos ver a Git encontrar esta rama en nuestro repositorio remoto. Aquí, escribimos Git branch R. Entonces tenemos esta rama de rastreo remoto. Cuando ejecutamos Git fetch, entonces siempre obtenemos la rama de seguimiento remoto Ahora creamos una nueva sucursal privada en nuestro repositorio local y luego la vinculamos con la rama de seguimiento remoto. Para eso, lo escribimos switch, C o creamos aquí escribimos nuestro nombre de sucursal local, queramos llamar. Podemos llamarlo de cualquier manera, pero la mayoría de las veces, lo llamamos igual que el nombre de la sucursal de rastreo remoto. Así que no necesitamos recordarlo. Página de inicio de diseño. Después de eso, tenemos que escribir nuestro nombre de sucursal de seguimiento remoto, que queremos vincular, que es la página de inicio de diseño de origen. Obtenemos el nombre de la sucursal de rastreo remoto aquí. Ahora bien si escribimos git branch VV, C, aquí obtenemos la rama, y también está vinculada con la página de inicio de la barra de diseño de origen Cuando alguien más crea una rama y empuja la rama en el repositorio, entonces primero, tenemos que ejecutarla comando fetch Por eso, obtenemos la sucursal de rastreo remoto, y luego tenemos que crear una sucursal local y vincularla con nuestra sucursal de rastreo remoto usando Kit Switch, C, nombre de sucursal local y nombre de sucursal de rastreo remoto. Ahora aquí podemos comprometer nuestros cambios y empujarlos a nuestro origen. Entonces abro este repositorio en el código VS, y aquí creo un nuevo archivo llamado index dot DML, y solo agrego aquí código boilerplate Guarde esto y simplemente escenifique los cambios y comprometa estos cambios. Gated M, crear e indexar DML punto para la página de inicio. También empujemos los cambios al mando a distancia. Git push, hecho. Ahora veamos cómo trabajo en mi pantalla. Aquí tenemos nuestro repositorio en mi PC. Si no tenemos, entonces tenemos que clonar nuestro proyecto. Primero obtengamos todos los cambios usando git fetch. Si revisamos nuestro registro, vea, aquí obtenemos nueva sucursal. Ahora cambio a esta sucursal usando Kit switch Design slash página de inicio Ahora antes de empezar a trabajar en nuestro código, siempre es mejor extraer los cambios desde el control remoto. Pero aquí solo traemos los cambios para que no los necesitemos, así podemos empezar directamente a trabajar en esto Aquí hago algunos cambios en script dot js archivo, guardar los cambios. Ahora imaginemos que terminé mi trabajo en esta rama. Vamos a escenificar los cambios y también a confirmar el código con el mensaje de confirmación, completar el trabajo en el archivo js script, empujo los cambios, puerta push. Ahora, como ya le dije anteriormente, cerrar esta sucursal es responsabilidad de nati. Volvamos a las especificaciones nati. Aquí, ver primero, importar mis cambios usando Git pull. Bueno. Aquí nos ponemos rápidos para nuestra fusión. Vamos a revisar nuestro historial. Aquí llegamos a commits. Ahora tenemos nuestro código de sucursal listo y también nuestro puntero de página de inicio de diseño está por delante de la sucursal principal. Aquí, tenemos que fusionar nuestro código en rama principal. Esto lo hemos hecho tantas veces, aquí, primero volvemos a la rama principal. Después de eso, escribimos puerta, fusionamos, diseñamos la página de inicio. Ver, aquí nos ponemos rápidos para nuestra fusión porque tenemos ramas lineales. Pero aquí no tenemos conflictos. Porque esto es solo una demo. Lo más probable es que cada vez tengas conflictos, y ya sabemos cómo resolverlos. Entonces tienes que resolverlo con los miembros de tu equipo. Ahora, veamos aquí nuestro registro. Podemos ver ahora nuestro puntero principal y el puntero de página de inicio de diseño está en el mismo mit. Pero origen Min está en el medio anterior. Entonces tenemos que empujar los cambios en repositorio remoto y cómo podemos hacerlo, bien, usando Git push. Ahora volvamos a revisar nuestro historial. Ahora origen Min está en la misma marcha. Ahora vamos a comprobar esto también en Github. Ir a los gametos. Mira aquí tenemos nuestro último Camite que es Merge Gamit Ahora como nuestra rama de página de inicio de diseño se fusiona en la rama principal, podemos eliminar esta rama de página de inicio de diseño. De lo contrario, creará confusión. Así que consigue ph D origen y diseño homepage. C, rama eliminada del repositorio remoto. Pero si vemos las sucursales, C, aquí todavía tenemos sucursal homepage, así que también tenemos que bajarla. Obtener sucursal D Diseño Página principal. Ahora nuestra sucursal local también está bajando. Ahora de vuelta a mi PC, primero, voy a tirar los cambios para obtener la confirmación de fusión. Ahora ambos tenemos el mismo historial de compromiso. Primero, revisemos la rama de seguimiento remoto usando Git BanChR. Ver aquí Estoy consiguiendo la rama de origen diseño slash home. Hasta ahora quitando la rama de seguimiento remoto, que no están disponibles en remoto, escribimos Git remote Prune origin Este comando eliminará todas las ramas de seguimiento remoto que no estén disponibles en el repositorio remoto. Ahora déjame revisar sucursales locales. Ver todavía tengo aquí, tengo que dejar también la sucursal local. De nuevo, git branch D Design home page, y aquí obtenemos error, no se puede eliminar branch design slash home page porque actualmente estamos en la página de inicio de Design slash, cambiamos a la rama master Puerta como para usar el comando git pull para actualizar la rama local. Mira aquí nos ponemos rápidos para nuestra fusión, y si revisamos nuestro historial, mira aquí todavía tenemos esta rama de página principal de diseño. Ejecutamos git branch D Design slash home page, y es eliminar la rama Así es como trabajamos con sucursales en equipo. Te confundes un poco, entonces no te preocupes, déjame recapitular esta porción Primero, creamos una nueva rama y luego para empujar esa rama, tenemos que establecer la rama aguas arriba. Entonces sabe qué sucursal local se conectó a la sucursal remota. Después de eso, podemos empezar a trabajar en la sucursal. Si queremos empujar algo, entonces primero lo comprometemos y luego podemos empujarlo al origen. Pero antes de hacer push, es una buena práctica usar pull. Obtenemos los últimos cambios y después de completar el trabajo de sucursal de commits, lo fusionamos con la sucursal principal y luego eliminamos la sucursal de rastreo remoto y también la sucursal local. Si la rama de seguimiento remoto ya es abandonada por otro miembro del equipo, entonces tenemos que ejecutar git remote, Prune origin y ya terminamos 78. Crea solicitudes de pull en Github: Ahora, supongamos que está trabajando en una rama y entre el código, quiere obtener algunas sugerencias de los miembros del equipo. Después en Github, puedes tomar sugerencias o abrir discusión para el tema específico. En esta situación, podemos crear una solicitud de extracción para la discusión de apertura sobre nuestro código. Pide sugerencias o comentarios a otros miembros del equipo. Déjame mostrarte eso prácticamente. Aquí está el NathiPC. Vamos a crear una nueva rama e impulsar cambios en esa rama. Primero, escribimos Git switch Design slash Q&A Page. Abramos este código en el código vias. Aquí en el índice punto sdmlfle en el cuerpo, agrego etiqueta principal Dentro de esto, agrego Du en ella, otra DU y aquí H una etiqueta. Esta es la pregunta uno. Esto es solo una demo. Guarde esto y comulguemos y publiquemos estos cambios. En nuestro terminal, escribimos apretado AM, agregando tarjeta Q. Uno. Bueno. Ahora tenemos que empujar estos cambios a nuestro repositorio remoto. ¿Y cómo podemos hacer eso? Podemos escribir puerta, empujar. Pero mira aquí nos sale un error fatal. Me puedes decir por qué? Sí, porque no establecimos rama upstream. O en palabras simples, no vinculamos nuestra sucursal local con la sucursal remota. Aquí simplemente escribimos Git push u origin, aquí escribimos nuestro nombre de sucursal local, que es la página Design Slash Q&A y listo Aquí, impulsamos nuestros cambios con la configuración de la rama Upstream. Déjame abrir esta cuenta en el sitio web de GitHub. Ver en la página principal, aquí obtenemos Diseño SQ y página, H DSN push, y también obtenemos D compare y pull request Aquí podemos abrir discusión para esta rama de página de preguntas y respuestas y colaborador puede dar algunas sugerencias o discutir el código Además, podemos crear pull request desde esta pestaña Pull Request. Haga clic en Nuevo Pull Request. Ahora aquí, podemos seleccionar dos ramas para comparar los cambios. La mayoría de las veces, seleccionamos rama principal como rama base, y aquí seleccionamos nuestra sucursal de página de preguntas y respuestas Ver, aquí obtenemos los commits en esta rama. Tenemos un commit, un cambio de archivo, y también tenemos un colaborador. Aquí obtenemos una lista de confirmaciones y a continuación de eso, podemos ver los cambios en nuestros archivos. Aquí también podemos seleccionar para vista dividida, así podemos ver antes y después con mucha claridad. Ahora abramos discusión para esta rama. Haga clic en Crear solicitud de extracción. Aquí podemos escribir nuestro título de discusión. Cambiemos estos por sugerencias para el phon de la tarjeta de preguntas. A continuación, podemos describir lo que queremos discutir, lo que queremos arreglar, etcétera Digamos, primero agregamos sugerencias de título necesarias, y después de eso, viñetas, sugieren algunas etiquetas semánticas para tarjeta y resumen este código corporal Ahora podemos simplemente crear pull request o también podemos redactarlo. Vamos por Crear solicitud de extracción. Mira aquí estamos en la conversación y este estado de solicitud de extracción está abierto. Ahora bien, ¿cómo pueden saber otros miembros del equipo que abrimos esta discusión? Para eso, tenemos que agregarlos en los revisores. Da click en este ícono de engranaje, y aquí tenemos la lista de colaboradores, que agregamos en nuestro repositorio al inicio de esta sección. Se como esta cuenta. Ahora, en el momento en que seleccionamos al usuario, Github envía un correo electrónico a este usuario y le decimos que tiene nueva discusión. Ahora déjame cambiar la ventana y mostrarte cómo este miembro del equipo puede revisar nuestro código. Entonces esta es mi cuenta original. Vamos a la solicitud de extracción y vemos aquí tenemos esta discusión. Abre eso. Ver en la parte superior, aquí nos llega este mensaje. Este usuario solicitó su opinión sobre esta solicitud de extracción. Así que haz clic en agregar tu opinión. Aquí, obtenemos una vista dividida de este archivo cambiado. Si quieres ver todo el archivo, entonces podemos hacer click aquí, Ampliar Todo. Ahora aquí, tengo un par de cambios que me gusta sugerir. Primero, en esta etiqueta principal, podemos ir como artículo de sección, y luego H una etiqueta, y luego H una etiqueta, no la simple de También quiero contar en clase para el artículo de la tarjeta de preguntas para que los desarrolladores sepan que esta es una tarjeta de preguntas. Aquí podemos ver antes de cada línea, obtenemos estos íconos plus. Por eso, podemos escribir reseña para cada línea. Pero actualmente, solo quiero decir jerarquía de texto y nombre de clase. Entonces hago clic en este ícono más, y escribimos nuestra reseña aquí. Entonces agrego viñeta primero, agrego etiqueta semántica, sección principal, artículo y H uno, y después de eso, agrego la clase igual a tarjeta de subrayado de pregunta a la etiqueta del artículo Y simplemente inicia la revisión. Ver aquí podemos ver la revisión y detalles y actualmente se encuentra en estado pendiente, y simplemente terminamos esta revisión. Aquí, tenemos que escribir una descripción básica para nuestra revisión. Entonces podemos escribir estas son la sugerencia para este código, hacer los cambios, y empujarlos. Ahora en la parte inferior, obtenemos tres opciones. Primero, podemos presentar esto como comando. Podemos establecer aprobar y podemos solicitar los cambios. Actualmente, estamos solicitando dos cambios, por lo que podemos seleccionarlos y simplemente enviar la revisión. Verás, estamos en la pestaña de conversación de esta pull request, y desde aquí, podemos ver lo que está pasando aquí en la parte inferior, obtenemos nuestra revisión, cual se acaba de presentar de manera muy sistemática. Y debajo de eso, puedes ver que tenemos solicitud de cambios. A en el lado derecho, tenemos este icono, que informa a este usuario a solicitud de cambios. Entonces ahora volvamos a cambiar a la cuenta nadis a partir de la cual inicié esta discusión Primero, hicimos la vista previa desde la pestaña de conversación. Y luego hacemos cambios en nuestro código. Entonces abro índice punto sdmlfle. Primero, cambio esto primero debido a la sección y segundo DU a artículo. Si te preguntas cómo estoy cambiando las etiquetas de apertura y cierre juntas, entonces tienes que instalar la extensión de etiqueta Autor nam en tu código VS, muy recomendable. Además, necesitamos agregar aquí clase a la tarjeta de subrayado de pregunta Guarde los cambios, y vamos a comprometerlos. Así que las etiquetas semánticas de GTMTAM, y la actualización del nombre de la clase Sé que este es un mal mensaje de coommit, pero es solo para demo Entonces empujemos también esto. Ahora como hemos hecho con nuestros cambios, tenemos que decirle a ese miembro que vea nuestros cambios y los verifique. En el lado derecho, tenemos esta opción de re solicitud de revisión. Haga clic en eso. Esto nuevamente enviará correo electrónico a ese usuario y le dirá que vea las actualizaciones. Vuelvo a cambiar a mi cuenta, y aquí puedo ver este usuario solicitó su opinión sobre esta solicitud de extracción. Haga clic en agregar su opinión. Consulta nuestros cambios y si no estamos satisfechos, entonces podemos volver a escribir reseña y enviarla. Aquí, estamos satisfechos con los cambios, luego podemos hacer clic en visto y simplemente hacer clic en estos cambios de revisión. Aquí, escribo, perfecto, eso se fusiona en nuestra rama principal. Desde abajo, podemos seleccionar, aprobar y enviar revisión. Mira aquí obtenemos los cambios aprobados, y esta discusión cumple con su propósito y podemos ver en la parte superior, tenemos el estado de cambios aprobados. Ahora en la parte inferior, tenemos opciones para fusionar esta solicitud de pool Ahora aquí hay un debate qué desarrollador hace a la hora de cerrar la solicitud de pool. Pregunta ¿quién debe fusionar esta solicitud de extracción? El que inició esa solicitud de extracción o algunos revisores debe fusionar la solicitud de extracción Algunos desarrolladores optan por esta primera opción porque piensan que la persona que inicia pull request sabe más de eso. Entonces el o ella que creó esta solicitud de extracción, tienen que fusionarla. Entonces algunos desarrolladores dicen que la persona que contribuye a MR es el revisor, el revisor debe fusionarse Honestamente, no necesitas preocuparte por eso. Simplemente pregúntale al respecto a los miembros de tu equipo o gerente porque algunas empresas siguen primera opción y otras siguen la segunda. Así que haz lo que sugieran los miembros de tu equipo. Podemos fusionar esta solicitud de extracción desde aquí y obtenemos tres opciones para merge, simple merge, squash y merge, y rebase y merge Ya conocemos esta opción, así que vayamos por la fusión simple, confirme la fusión. Ver, obtenemos pull request fusionar y cerrar con éxito. Ahora podemos eliminar esta sucursal de aquí. Podemos restaurar la sucursal. Ahora déjame ir al switch NathipCF de nuevo a la puerta do principal, pull para obtener la Mira, nos ponemos rápidos para nuestra fusión y si revisamos nuestro historial, mira, aquí tenemos página de preguntas y respuestas y también la rama de seguimiento remoto Tiene que eliminar esta sucursal del local y también eliminar la sucursal de rastreo remoto. Entonces esta rama ya está eliminada del repositorio remoto, y queremos eliminarla de nuestro repositorio local, y cómo podemos hacerlo. Podemos escribir git remote, prune origin. Ahora vamos a eliminar también esta sucursal local. Git rama D, Diseños Q&A página y hecho. Puedes ver si usamos algún comando Git dos o tres veces, entonces no nos confundimos con eso. Como te dije, esto es todo acerca de la práctica. Sé que esta lección es poco larga, así que puedes tomarte un descanso de cinco a 10 minutos, tomar un poco de aire fresco, y después de eso, continuar este curso. 79. Resolver conflictos durante las solicitudes de pull: Anteriormente, hemos visto cuando estamos haciendo merge in pull request, no obtenemos ningún conflicto. Pero, ¿y si tenemos conflicto? Una forma es que podemos usar el código VS, pero eso es poco largo. Si estamos haciendo fusión en nuestra sucursal local, entonces tenemos que usar código VS. Pero también, podemos resolver conflictos usando Github. Solo es útil mientras estamos fusionando pull request. Digamos esto. Primero, creo una nueva sucursal desde Una esta PC y hago una marcha y empujo a esa Kat Obtener características de swish C Página principal. Aquí en index dot sdmlfle, cambio el título de demo a título de página de inicio Y también cambiar la primera línea en script punto archivo Gs. Esto es script para la página de inicio. Guarde los cambios y cometamos esta función Gtms AM, Actualizar el título y el guión para el hogar Ahora, vamos a empujar esta rama en Github. ¿Te acuerdas de eso? Derecha, usa Git push para configurar la característica Origen de la rama Upstream Slash página de inicio Hecho ahora para crear conflicto, abro cuenta Github desde mi PC y simplemente abro index dot stmlfle seleccionamos Editar y cambiamos este título a título en Comprometamos los cambios y continuemos con este compromiso. Ahora vamos a crear un archivo js de inscripto de conflicto más. Entonces nuevamente cambiamos la primera línea al guión por rama principal y venimos los intercambios Ahora déjame crear una solicitud de extracción. Así que dirígete a Github y vamos a la sección pull request. Aquí, creamos una nueva solicitud de extracción. La base es la rama principal, y la comparamos con la característica página de inicio de SLS Ver, aquí no podemos fusionar automáticamente. No te preocupes, aún puedes crear una solicitud de extracción. Vamos a crear una solicitud de extracción. Aquí automáticamente elige Commit message, y podemos escribir una descripción para la solicitud de extracción, solicitud extracción para la página de inicio de barra de características y crear una solicitud de extracción Ver, aquí obtenemos esta rama tiene conflictos que deben resolverse. Entonces aquí podemos usar la línea de comandos para resolver los conflictos. Además, podemos hacer eso usando Github. Simplemente damos clic en Resolver conflictos. Aquí en el lado izquierdo, obtenemos la lista de archivos que tienen conflictos. Aquí podemos ver el conflicto. Ya hemos visto estos punteros. Quiero mantener este título de página de inicio. Se conflicto se ha ido de este archivo y haga clic en Marcar como resolución para este archivo. Ahora para el siguiente archivo, aquí guardo este código de sucursal principal. Ver aquí están todos los conflictos se han ido. También podemos marcar este archivo como resolver y simplemente cometer fusión. Y mira, ahora esta rama no tiene conflicto con la rama base. Además, si quieres agregar revisores, entonces también podemos hacer eso, igual que hicimos en la lección anterior Ahora podemos fusionar pull request, y confirmar merge. Así es como podemos resolver conflictos mientras creamos una solicitud de fusión. 80. Crea problemas en Github: Ahora en Github, como tenemos la función pull request, también obtenemos la opción issues. Nuevamente, esta es la característica de Github, no de Git. ¿Cuáles son estos temas? Issues es como un Nodos pegajosos que usamos en nuestro libro. Los nodos pegajosos se utilizan para escribir nodos, corregir algo o escribir preguntas, etcétera Igual que podemos usar temas para rastrear tareas, errores, o también podemos discutir sobre nuestro proyecto. Déjame mostrarte eso. Así que haz clic en Nuevo número. Aquí, podemos escribir el título de nuestro número. Digamos, discusión sobre las características de las tarjetas. Y aquí escribimos nuestra descripción para este número. Vamos a discutir sobre las características de la tarjeta de preguntas para este proyecto. Aquí también podemos dar fe la imagen demo de nuestra tarjeta de diseño básico Los archivos adjuntos son muy útiles. Si estamos creando problemas para resolver los errores, entonces podemos dar fe de la captura de pantalla o grabación de pantalla para mostrar los errores En el lado derecho, podemos asignar el problema a los miembros de nuestro equipo. Por ahora, acabo de agregar mi otra cuenta. Después de eso, tenemos etiquetas. Github tiene tantas etiquetas relevantes para casi todo tipo de temas. Vea aquí obtenemos documentación de errores, duplicado, mejora, buen primer problema, inválido, pregunta y corrección de Vance Además, podemos crear nuestras propias etiquetas. Editemos estas etiquetas. Y crear una nueva etiqueta. Podemos dar nombre discusión. A partir de aquí, podemos cambiar de color. Entonces déjame probar algo. Sí. A mí me gusta este y creo etiqueta. Ahora volvamos a nuestra página. Y selecciono esta nueva etiqueta. Aquí también podemos vincular nuestros proyectos. Además, actualmente, no tenemos hitos. Veremos hitos en la siguiente lección. Por ahora, no te preocupes por eso. Además, actualmente, no tenemos pull request, lo contrario, también podemos conectar problema con pull request. Y cuando fusionamos esa solicitud de extracción, entonces todos los problemas conectados se cerrarán automáticamente y enviemos un nuevo problema. Mira aquí conseguimos que este número esté abierto. Ahora los cedentes comentarán sobre este tema y discutirán sobre lo que piensan y establecerán sus sugerencias Ahora, después de completar toda la discusión, también podemos cerrar este tema. Así es como podemos usar temas usando Github. Por eso a los desarrolladores les encanta Github. 81. Agregar hitos en GitHub: Ahora, a veces en nuestro proyecto, queremos crear un hito. Hito, podemos ver como la meta a corto plazo o la meta a largo plazo, que queremos completar en tiempo particular. Por ejemplo, en nuestro proyecto, queremos agregar la función de autenticación de usuario. Para que podamos crear un hito y fijar la fecha para completar este hito. En este hito, podemos agregar varios tipos de problemas como página de inicio de sesión de diseño, página de registro de diseño, plan de opciones de restablecimiento de contraseña, etcétera Supongamos que complete este número de página de inicio de sesión de diseño, así puedo marcar ese número como cercano, y en nuestro hito, obtenemos un avance de 33.3% Cuando se resuelven todos los problemas, que están conectados a este hito, entonces nuestro hito fluye automáticamente. Esto es muy útil para planificar, organizar y hacer un seguimiento del progreso de nuestros proyectos. Veamos cómo podemos crear hito en Github. Aquí estamos en la sección temática. En la parte superior, obtenemos la opción de hito. Actualmente, no tenemos hitos, creamos un nuevo hito Aquí, escribo título para este hito. Digamos autenticación de usuario. Aquí, podemos seleccionar el approxtate cuando completemos este hito, y por fin, podemos escribir una descripción para describir este Por lo tanto, implemente la funcionalidad de autenticación de usuario, incluidas las funciones de inicio de sesión de registro y restablecimiento de contraseña, y creamos un hito. Esta es nuestra lista de hitos. Aquí tenemos detalles básicos sobre hito y aquí podemos ver nuestro progreso. Ahora para mostrarte el progreso, agreguemos un número en este hito. Ir a los números y crear un nuevo número. Agregar aquí título, diseño, página de inicio de sesión, agregar asignadorAsí también podemos asignar nuestro propio yo Selecciono etiqueta a realce y desde aquí, podemos seleccionar hito. Ver, aquí tenemos hito de autenticación de usuarios. Esta es otra forma de agregar temas en hito. Entonces por ahora, acabo de presentar un nuevo número. Ahora volvamos a la página de números. Aquí, seleccionamos nuestros números de todos los números que están abiertos. Y aquí tenemos opción de hito. Aquí seleccionamos hito de autenticación de usuario y vemos, aquí obtenemos nuestro nombre de hito. Veamos nuestro hito. Podemos ver que tenemos un tema abierto en este hito. Entonces haz clic en el hito y después de completar el número, podemos seleccionarlo y marcarlo como número cercano. Y mira aquí nuestro hito está 100% completo. Así es como podemos usar hitos en Github. 82. Flujo de trabajo en proyectos de código abierto: Hasta ahora vemos cómo podemos trabajar en nuestro proyecto con los miembros de nuestro equipo. En Gitub, también podemos trabajar en proyecto de código abierto. Veamos el flujo de trabajo del proyecto de código abierto. Por ejemplo, aquí hay un proyecto de código abierto en el que te gusta contribuir. Este es el proyecto en mi cuenta de Gitub, pero no puedes empezar a trabajar directamente en este proyecto porque no te agregan como colaborador, y por eso tampoco puedes empujar tu código en este Entonces, ¿cuál es la solución aquí? ¿Cómo podemos empezar a trabajar en este proyecto? Primero, tienes que agregar ese proyecto en tu propia cuenta de Github. Esto se llama como creación de Fork. Ahora aquí tenemos acceso completo para este repositorio. Ahora cuando hayas terminado con tu contribución, entonces puedes empujar tus cambios a tu repositorio. Después de eso, puedes crear una solicitud de extracción para fusionar tu código. Y en el momento en que creas una solicitud de extracción, Github, envíeme eso por correo electrónico. Alguien crea una solicitud de extracción para este proyecto de código abierto. Reviso tu código. Si quiero darte algunas sugerencias, entonces te daré y luego cuando esté satisfecho con el código, puedo fusionar ese código en mi proyecto directamente desde tu solicitud de pool. Aquí, no puedes fusionar los cambios en mi repositorio porque solo yo puedo empujar los cambios a mi proyecto. Para resumir, primero, encontramos proyecto de código abierto en el que te gusta trabajar Entonces bifurcamos ese repositorio. Esto agregará ese proyecto de código abierto en tu cuenta de Github. Cuando haya terminado con sus cambios, entonces puede empujar los cambios en su proyecto para su revisión final, puede crear pull request. Ahora, el autor de esa solicitud verifica tu código, da algunas reseñas sobre tu código, o te sugiere que hagas algunos cambios y luego simplemente fusionar ese código en su proyecto de código abierto. Así es como podemos trabajar en el proyecto de código abierto. Ahora en la siguiente lección, vamos a ver esto prácticamente. 83. Cómo trabajar en un proyecto de código abierto: Entonces, cuando queremos contribuir en algún proyecto, puedes buscar aquí el repositorio. Supongamos que quiero trabajar en la funcionalidad de búsqueda en react. Así que busco aquí reaccionar buscar. Aquí, obtenemos la lista de repositorios, y así es como podemos encontrar repositorio Y en ese repositorio, los desarrolladores agregaron algunos temas que abren para discusión o contribución. Se puede trabajar en ese tema específico. Aquí, selecciono mi propio proyecto, que creé hace tres años. Y aquí podemos ver también abro un número para este repositorio. Ahora bien, este repositorio es comprometido por mi cuenta antigua, no por Cod bless you account. Y en este navegador, me conecté con Cod blessu para poder contribuir a ese proyecto Ahora, el primer paso para trabajar en proyecto de código abierto es que tenemos que bifurcar el repositorio en nuestra cuenta. Entonces, en el lado derecho, simplemente haz clic en este ícono de niebla. Aquí podemos cambiar estos detalles si queremos y simplemente dar clic en crear Niebla. Ver, aquí obtenemos la copia de ese repositorio y podemos verlo niebla desde el repositorio original. Aquí podemos ver que esta sucursal está actualizada con nuestra sucursal de repositorio original. Ahora podemos cerrar este repositorio en nuestra máquina y empezar a trabajar en eso. Déjame mostrarte eso para que no te confundas. Copia este enlace de repositorio y abre la terminal donde quieras agregar este proyecto. Aquí escribimos Git clone y pegamos el enlace del repositorio. Bueno. Vamos a entrar en esta carpeta y crear una nueva sucursal aquí. Consigue switch como C design Home y ábrelo en código VS. Aquí, hago un pequeño cambio en app dot archivo JS. Guarde los cambios, y vamos a comprometerlos. Entonces Git, ven 8:00 A.M. Actualiza el archivo F. Y por empujar esta rama, primera vez escribimos Git push U para upstream origin design home. Bueno. Ahora cuando hayamos terminado con nuestras actualizaciones, volvemos a nuestro repositorio, actualizamos la página. Ver, aquí tenemos esta casa de diseño Harris y push. Así podemos comparar y tirar de solicitud, igual que antes. Pero aquí hay una pequeña diferencia. Estamos comparando nuestra rama de diseño doméstico de nuestro repositorio de niebla, y comparamos con esta rama maestra de repositorio original. Aquí, podemos escribir un título para la solicitud de extracción, y también podemos escribir una descripción. Por ahora, selecciono directamente crear solicitud de extracción. Ver, aquí creamos solicitud de pool, y en esto, no tenemos conflictos. Pero aquí hay una cosa. No podemos fusionar esta solicitud de pool, solo el encargado o propietario puede fusionarla. Entonces desde mi antigua cuenta, puedo aceptar los cambios e implementarlo en ese repositorio principal. Aquí está mi cuenta antigua, que es la dueña de ese repositorio, y aquí podemos ver pull request. Abre eso y aquí podemos ver esa cuna desde abajo, mira aquí esta cuenta, consigue merge, pull request, así merge pull request, y confirme merge. Ese cambio se agrega en el repositorio principal. Así es como contribuimos al proyecto de código abierto. 84. Sincroniza Local y Fork con el repositorio base: Cuando bifurcamos un repositorio, este repositorio de niebla no está realmente conectado al repositorio base. Entonces, cuando estamos trabajando en ese repositorio de niebla en este repositorio base, alguien puede cometer cambios. Entonces en ese momento, tenemos que sincronizar la niebla con este repositorio base. Pero, ¿cómo podemos hacer eso? Es muy sencillo. Entonces vamos al repositorio de niebla. Ver, aquí estamos consiguiendo esta rama es dos rama detrás de la rama repositorio base, lo que significa que hay dos viene suceder después de nuestro código actual. Entonces en el lado derecho, obtenemos la opción sync fog. Aquí, podemos comparar estos cambios o simplemente podemos actualizar rama. Entonces tenemos sucursal actualizada aquí. Así que simplemente podemos obtenerlo en nuestro repositorio local. Así que ejecuta git, busca. Ver, aquí conseguimos nuevo commit. Ahora podemos simplemente fusionarlo con nuestro master commit. En primer lugar, nos cambiaremos a la rama maestra. Bueno. Actualmente, estamos en la rama Master, y escribimos git merge origin master. Y hecho. Tenemos todos los cambios en nuestro repositorio local así como en el repositorio de niebla. Eso es muy fácil y eso se trata de trabajar en un proyecto de código abierto. No hay ciencia cohete para esto, tenemos que practicarla dos o tres veces. 85. Herramientas de colaboración en VS Code: Ahora veamos algunas herramientas de colaboración en código VS. Entonces en nuestro proyecto, aquí podemos ver que actualmente estamos en la rama maestra. Déjame cambiar a la otra rama. Ahora déjame mostrarte cómo podemos impulsar el cambio a nuestro control remoto. Entonces en el archivo Read Me, cambio este título, digamos, iniciando con VSCode Guarde esto, y ahora vamos al control de fuentes. Escribir mensaje de commit, actualizando léeme para VSCode, y Ahora aquí podemos ver que obtenemos la opción de cambios de sincronización. Y si pasamos el cursor sobre eso, entonces dice, empujar uno commit to origins Design slash home branch Entonces a partir de aquí, también podemos empujar. Además, si hacemos clic en estos tres puntos, también obtenemos la opción push. Con eso, también obtenemos opciones pull, clone checkout, fetch y mucho más interesantes Ejemplo, si vamos a CDs, aquí, podemos hacer Commit normal, commit only stage files, commit, deshacer el último commit y también sobre rebase Tenemos cambios, pull, push, branch, remote, escaleras, etiquetas, y casi todas las opciones que se utilizan a menudo en git. No quiero aburrirte mostrando todas y cada una de las opciones. Ya vimos estas opciones usando la línea de comandos. Entonces aquí, hago simple empujón. Y hecho. Nosotros publicamos los cambios. Utilizo estas opciones cuando no quiero abrir terminal. De lo contrario, me gusta usar línea de comandos porque eso es más claro para mí y además no me gusta usar mouse cuando estoy codificando. No sé por qué. Si quieres usar estas opciones, entonces también está bien. Realmente depende de tu elección personal. Yo no soy nadie que te diga que uses esto o no uses eso. La elección es suya. También en el panel de control de origen en la parte inferior, podemos ver nuestros cometas, ramas, controles remotos, estasis, etiquetas, árbol de trabajo, y en la parte inferior, obtenemos la lista de contribuyentes de este repositorio También, desde aquí, podemos agregar colaborador. Si no quieres usar el sitio web de Github. 86. Colaboración con Github Desktop: Ahora veamos las opciones de colaboración en la aplicación de escritorio Github. Entonces aquí también cambio el título del archivo Read Me para comenzar con la aplicación de escritorio Github. Guarda esto y déjame comprometerme esto con mensaje, actualización, léeme archivo para Github Dextop Bueno. Ahora, pasemos a la aplicación de escritorio Github. Actualmente, no tengo nuestro proyecto de repositorio de niebla abierto en la aplicación de escritorio Github, así que tengo que abrir eso. Entonces voy al archivo, agrego repositorio local, elijo mi ruta de carpeta y agrego repositorio. Ver aquí obtenemos directamente la opción de origen push. También puedes abrir este proyecto en Github usando este botón. Herramienta muy útil. Ahora en la parte superior, tenemos repositorio actual. Después de eso, tenemos rama actual, y luego podemos ver que tenemos botón push to origin, y debajo de eso, obtenemos detalles sobre fetch En el mundo real, cuando estamos listos para impulsar nuestros cambios, es una buena práctica extraer primero los cambios desde el origen. Entonces en el lado derecho, tenemos botón. Consulta aquí obtenemos el origen del parche. Haga clic en eso. Y si tenemos cambios, entonces obtenemos esos cambios en nuestro repositorio. Y si tenemos conflicto, entonces antes de empujar, podemos resolver nuestros conflictos. Y por eso, no necesitamos volver a presionar Merge kat. Usando esta práctica, podemos limpiar nuestra historia de Cat. Ahora en la parte superior, tenemos el menú del repositorio, y dentro de él, obtenemos muchas opciones básicas para git, como push, pull, fetch, remove, y en la parte inferior, obtenemos la configuración del repositorio Solo me gusta esta opción porque aquí podemos cambiar fácilmente nuestro repositorio remoto. Entonces estas opciones son muy similares en el código VS. Lo curioso es que el código VS tiene muchas más opciones que la aplicación de escritorio Github. Y por eso te digo escritorio Github es una aplicación sencilla, básica y amigable para principiantes. Simplemente empujemos al origen y hecho. Ahora aquí podemos ver que podemos previsualizar pull request, y también podemos crear pull request. Y cuando creamos una nueva solicitud de extracción, entonces podemos verlo en nuestra página de repositorio. Ahora veremos otras opciones en la siguiente lección usando Git crack y aplicación. 87. Colaboración con GitKraken: Ahora veamos las herramientas de colaboración usando Git kraken. En primer lugar, en Git Kraken, tenemos que abrir ese repositorio de niebla porque actualmente no está abierto Así que ve al archivo, OpenRPO aquí, seleccionamos repositorio abridor y seleccionamos nuestra carpeta de repositorio Ahora aquí podemos ver actualmente estamos en la rama Design Slesome En el lado izquierdo, podemos ver el nombre de la sucursal local, controles remotos, solicitud de extracción actualmente activa, que es cero También podemos crear pull request desde aquí. Después de eso, tenemos problemas, seleccionamos aquí Github, y obtenemos los problemas. Aquí, también podemos crear un nuevo número y después de eso, tenemos muchas más opciones. Ahora déjame mostrarte algo realmente genial. Aquí tenemos repositorios. Después de eso, tenemos lista de sucursal que ya vemos en el apartado anterior. Ahora después de eso, tenemos un par de botones que son muy útiles. Primero, nos deshacemos, que es por deshacer el último abrigo Si pasamos el cursor sobre ese botón, entonces podremos ver qué hace ese botón Entonces deshacemos el último en medio. Mira, aquí se ha ido. Déjame rehacer eso Después de eso, tenemos pull button, y aquí en el pull, tenemos muchas opciones. Trae todo, jala si es posible avanzar rápido, solo avance rápido y rebase Ahora, después de eso, tenemos pulsador y este botón de rama para crear rama a partir de esta confirmación seleccionada actual. Ahora aquí, damos click sobre el nombre de esta sucursal. Podemos ver, también obtenemos pull request, push set upstream, que configuramos para empujar rama por primera vez. También en la parte inferior, podemos iniciar pull request para esta sucursal y muchas más opciones. Aquí, no tenemos mucha opción porque estamos trabajando en el repositorio de niebla y no podemos empujar directamente al repositorio base. Comencemos la solicitud de extracción. Aquí, podemos seleccionar nuestra sucursal de nuestros dos orígenes. Desde nuestro repositorio de niebla, sucursal Design Home y compárela con nuestro repositorio base Sucursal Master. Ahora escribimos aquí, pull request title, así que actualizando léeme en casa de diseño. Aquí, también podemos escribir descripción, y desde aquí, simplemente podemos crear Pull request. También tenemos opción continuar editando en Github y vea aquí obtenemos el sitio web de Github. Simplemente haga clic en Crear solicitud de Pool. Y hecho. Si tenemos conflicto, entonces aquí, podemos resolver este conflicto. Y después de eso, desde el repositorio base, podemos fusionar estos cambios al repositorio base. Ya vimos ese derecho. Ahora desde mi segunda cuenta, que es autora de este repositorio, vamos a la pull request. Aquí, no tenemos ningún conflicto, así que podemos fusionarlo con rama. Y hecho. Así es como podemos trabajar con herramientas de corabación en él Kraken. Pero aquí está mi opinión personal. Si sabemos lo que es push, pull, setting upstream, merge, rebase y todos los términos, entonces usar la línea de comandos git es mucho más fácil que usar la interfaz gráfica de usuario En las GUI, podemos ver claramente la historia. Pero para estas opciones, personalmente creo que la línea de comandos es una opción mucho mejor. Puede abrir nuestra ficha en cualquier momento y escribir ese comando. Tan simple como eso. No necesitamos encontrar opciones o no necesitamos abrir aplicación de escritorio Git Kraken o Github en segundo plano En lugar de eso, simplemente podemos usar Git Bash o el terminal de código VS Entonces eso es todo acerca de la colaboración en git. Espero que aprendas mucho de esta sección. Después de esta lección, agregué Resumen PDF y puedes agregarlo en tu ficha 88. Sección 06 Limpia y organiza el historial: Bienvenido a la última sección del curso ultimate it. En esta sección, veremos cómo podemos limpiar y organizar las ayudas en la marcha. Entonces veremos hacer commits, recompensar a los niños, recuperar commits perdidos, soltar commits, cambiar el mensaje de comando, dividir, aplaudir y mucho, mucho más En palabras simples, reescribiremos o git commit history. Entonces comencemos esta sección. 89. Reescribe el historial de los compromisos: Ahora la pregunta que podrías hacer por qué necesitamos reescribir nuestra historia La razón por la que escribimos la historia o almacenamos la historia de nuestro proyecto es que queremos ver cómo evoluciona nuestra aplicación con el tiempo. Por historia, podemos ver en ese año, cuáles son las características que lanzamos, cuáles son los errores que solucionamos, y quiénes contribuyeron a qué característica, y muchas cosas más. Ahora imagínese en el momento en que vemos nuestra historia, vemos mal mensaje de compromiso. A veces cometemos pequeños cambios, que se pueden hacer en commits individuales o hicimos amidas realmente grandes en las que implementamos dos características juntas, lo cual no es bueno. A veces es posible que queramos eliminar las commits no deseadas, luego en ese momento, tenemos que reescribir nuestro historial de commits Por eso esta sección es útil para hacer nuestra historia limpia y organizada, que es el signo de desarrollador profesional. Ahora podrías preguntar, ¿ deberíamos reescribir historial de commits de proyectos que son remotos La respuesta es no. No debemos reescribir los commits que empujamos a remoto porque eso va a estropear nuestro proyecto para los demás y terminamos con un gran problema En muchas empresas, sólo la autoridad superior reescribirá la historia Pero primero, él o ella trae reunión o informa a todos los miembros del equipo sobre la reescritura de la historia Pero como desarrollador, podemos reescribir el historial de commits, que son locales y no push al remoto Reescribiendo la historia, podemos hacer que nuestra historia sea más limpia y organizada En la siguiente lección, comenzaremos con hacer el historial de compromiso. 90. Deshace el compromiso en los detalles (RESET): Entonces antes que nada, para esta sección, diseñé uno de él proyecto llamado Curso cartwis Obtendrás el proyecto en la carpeta de recursos que descargaste al inicio de este curso. Para que puedas abrir esa carpeta en el Git Bash o en la terminal Veamos la historia de este proyecto. Ver, aquí tenemos lista de Commits. Aquí, queremos deshacer el medio. Ya lo vimos en las secciones anteriores, pero solo quiero asegurarme de que no nos perdamos ningún tema. Entonces como sabemos para deshacer el amid, usamos el comando git reset, y este reset tiene tres opciones, LSD soft, LSDs mix, que es el default y hard Déjame explicarte cada opción una por una. Así que imagina que este es nuestro código de directorio de trabajo y queremos almacenar ese código en nuestro historial de Git. Primero, escenificamos nuestros cambios, y luego hacemos Commit. Ahora, después de algún tiempo, trabajamos en un error fijo en el diseño de maquetación. Nuevamente escenificamos los cambios y los comprometemos. Ahora aquí queremos deshacer la Commit B y queremos volver a commit A. Si escribimos git reset the soft head till one, entonces Git deshará la commit en git history. Aquí, obtenemos commit A, pero no tocará nuestro código de directorio de trabajo y código de área de puesta en escena. Se quedarán igual que antes. ¿Sabes que esta situación actual es cuál condición? Cuando hacemos cambios en el directorio de trabajo y escenificamos nuestros cambios, pero no lo comprometemos. Ahora supongamos en el lugar de ahí está el soft, escribimos mixto, entonces deshará nuestro último commit actual a la cabeza hasta que uno, que es un commit en el historial de commit. También reemplazará nuestro código de área de puesta en escena con código Com A. Pero aún así, no tocará el código del directorio de trabajo. ¿Sabemos que esta condición es cuál condición? Derecha. Cuando hacemos cambios en el directorio de trabajo, pero no escenificemos esos cambios, realmente lo estás haciendo genial. Ahora bien, si escribimos guión duro, entonces deshará todo el área en cabeza hasta uno, que es uno venir antes de que la cabeza se comprometa, que es A. ¿Conoces esta condición? Derecha. Cuando acabamos de hacer Commit A, todo nuestro código está en el estado anterior. Veamos estas opciones en acción. Digamos que queremos deshacer nuestro último compromiso con el commit anterior. Primero, veamos qué hicimos en este commit. Obtener mostrar referencia de Commit, que es head. Ver aquí en este commit, cambiamos estilo punto archivo CSS. Y aquí agregamos estas líneas de código. Entonces primero, escribimos git reset, da di soft. Aquí, escribimos nuestro Comite tiene o puntero sobre el que queremos movernos Entonces él, que es el Camttll actual, que es uno commit antes de este Sepa que esto solo deshará commit en el historial de commit y no toque nuestro directorio de trabajo y tampoco toque el área de puesta en escena. Entonces nuestro área de puesta en escena tiene esas líneas, pero nuestro amit se restablece a la versión anterior Entonces podemos ver eso al ver la diferencia entre área de puesta en escena y commit. Para eso, tenemos comando, Git df das cast. Mira, aquí tenemos esas líneas. Ahora, vamos a escribir git reset, dd mixed, add till one. Comando deshará el comando actual a la cabeza hasta un comando y también desdeclarará los cambios Aquí, a partir de este comando, si eliminamos esta prueba como mixta, entonces por defecto, obtener la prueba usada como mixta. Podemos verificar esto viendo la diferencia entre el área de trabajo y el área de preparación. Podemos usar el estado de Git, o también podemos usar GTF Mira, aquí obtenemos esta diferencia. Ahora veamos la última opción, que es obtener reset, ahí está esta cabeza dura hasta una. Ahora nuestro todo un código se restablecerá a esta cabeza hasta uno. Ahora si vemos el DF vemos, aquí no obtenemos ninguna diferencia porque toda el área se restablece para que se dirija hasta un cometa. Así que aquí nuestras últimas tres commits se han ido porque ejecutamos el comando reset tres veces. Así es como podemos deshacer el commit a un commit específico. 91. Revertir los compromisos: En la lección anterior, vemos cómo podemos deshacer el abrigo. Ahora veamos revertir amidas. Imagina que tenemos dos amidas en nuestra historia, que empujamos al github. Ahora no podemos deshacer esas amidas y volver a empujarlas. Coincidirá con el código para todos los miembros de nuestro equipo. Entonces, en esta situación, usamos revert, lo que significa que podemos deshacer esos cambios que hizo nuestro omit B y crear un nuevo Revertir significa volver a la versión anterior, pero sin envolver amidas anteriores Ver esto prácticamente. Entonces aquí tenemos nuestro historial de compromiso, y quiero deshacer los cambios que hizo este tercer cometa. Imaginario, pensamos que todo esto viene es empujado al control remoto, así que no podemos usar git reset. Entonces usamos aquí, Git reword y aquí escribimos Commit reference, que comprometemos los cambios que queremos deshacer, que es esta cabeza de Camt hasta dos Si escribimos cabeza hasta una, entonces deshará los cambios realizados por el segundo Cate. Aquí, también podemos revertir múltiples commits con un cometa. Si quieres revertir todos los cambios que realiza esta gama específica de cometas, así podemos escribir algo como Primero, escribimos la referencia de commit, una commit a continuación, que es él hasta cuatro. Punto doble, aquí escribimos último commit, que es head. Recuerda, sea cual sea el commit que escribamos primero, tomará commits después de ese abrigo hasta el último commit. Este comando revertirá los cambios realizados por estos cuatro commits y creará nuevos cuatro mets Ahora, Git pide mensaje Commit por cada nueva amida de recompensa. No quiero cambiar el mensaje de commit, así que simplemente estoy cerrando este cada archivo y listo. Ahora vamos a revisar nuestro historial. Mira, aquí conseguimos cuatro Camts de recompensa. Ahora, como podemos ver revertir múltiples amidas está haciendo que nuestra historia sea desordenada ¿Hay alguna otra solución que pueda limpiar este lío? Sí, hay un descanso. En lugar de crear estos cuatro cometas de recompensa individualmente, podemos revertir esos cambios y ponerlos en single met Entonces primero, retiremos estos cuatro medicamentos. Nosotros no los queremos. Aquí, podemos usar reset porque estas cuatro amidas no se plantean al repositorio remoto. Por lo que vamos a utilizar los resets de puerta con fuerza y donde queremos mover la cabeza Cierto, queremos mudarnos aquí. Entonces él, esto es cabeza hasta uno, cabeza hasta dos, hasta tres hasta cuatro. Así que dirígete hasta las cuatro. Ahora vamos a revisar nuestro historial. Mira, aquí deshacemos esos cuatro ametes. Ahora volvamos a revertir estos cuatro cometas, pero vamos a crear sólo un Escribimos Git, revert, dn, das amet y aquí escribimos nuestra referencia de Kameit igual que antes Cabeza hasta cuatro cabezas de punto doble. Mira aquí no obtenemos nada, pero podemos ver que estamos en el proceso de reversión Actualmente, git revierte todos los cambios que ocurrieron en esos cuatro comandos y puso esos cambios en el área de puesta en escena Podemos comprobar que usando git status S. S, aquí obtenemos tres archivos con D, que se elimina y uno con modificado y también tamp el cual está desrastreado Revertimos los cambios en el área de puesta en escena. Si quieres ver los cambios o hacer algunos cambios más, entonces nosotros podemos hacer aquí. Actualmente, no queremos hacer nada, así que podemos escribir Get revert Aquí tenemos dos opciones. Acerca de por abortar la revertida, o podemos continuar la revertida, lo que nos llevará a cometer esa revertida en un solo ait Nosotros sí seguimos Obtener pedir mensaje de compromiso. Aquí solo tenemos el último mensaje de reversión de compromiso. Podemos escribir aquí, revertir último para Coit para degustación. Guarde este archivo y ciérrelo. De vuelta a la terminal, ver revertir está hecho. Y en la historia, también obtenemos solo una reformulación en. Ahora, como puede ver, nuestros tres expedientes se han ido. Entonces por ahora, volvemos a restablecer esto en porque solo quiero mostrarte la demo de revert, pero podríamos necesitar estos Camtes en el futuro Así que consigue reiniciar, hay esta cabeza dura hasta uno y listo. Ahora en la siguiente lección, veremos p log. 92. Reflog para recuperar los compromisos perdidos: Ahora imagina en nuestro código, nosotros bi místicamente restablecemos nuestro código para que se dirija hasta las tres Aquí podemos consultar nuestro historial de cometas. Verás, perdimos nuestros tres primeros mets. Ahora bien, ¿y si queremos recuperar a esos ametos? Ahora bien, aquí se podría decir que perdimos eso en. ¿Cómo podemos recuperarlo? En git, realmente no perdemos nada. Consigue almacenarlos en el repositorio y cuando esos cometas perdidos se mantengan alejados por mucho tiempo, solo Git elimina esos cometas Si restablecemos bimstaalmente nuestro código, entonces Git no eliminará inmediatamente esos cometas Aquí ejecutamos Git Rf log, que es la forma completa de registro de referencia. Este comando mostrará la referencia de nuestro puntero de cabeza predeterminado. Básicamente, nos mostrará cómo se mueve nuestro puntero de cabeza en nuestra historia. Oh, ¿qué es lo que acabamos de ver? ¿Sientes tanta confusión? Sólo estoy bromeando. Esto es realmente sencillo. Déjame explicarte eso. Esto es solo mostrar cómo se mueve nuestro puntero de cabeza. Al principio, obtenemos commit a, luego obtenemos identificador de unidad para ese punto, y luego obtenemos la descripción de esa acción. Al principio, hice diez gametos en línea recta Con cada gameto, nuestra cabeza se mueve. Después de eso, en la primera lección, ejecutamos este comando git reset tres veces. Después hicimos cuatro veces revertir y luego reiniciar, Camt y Ahora bien, lo bueno de esto es que aquí tenemos a todos los cometas. Y en esta lección, también hicimos reset por error Lee. Por lo que solo necesitamos mover nuestro puntero de cabeza a esta referencia anterior y recuperamos el cometa perdido Entonces git reset, D duro. Aquí escribimos nuestra referencia aproximada de registro o podemos decir este ID de commit, o también podemos usar este ID de commit. Cabeza en calibrakets. Ahora, si revisamos nuestro historial de compromiso, mira, obtenemos nuestros Cumms perdidos Lo que aprendemos de esto Cuando ejecutamos el comando git reset, Git en realidad no elimina esos cometas. Consigue solo muévete Headpointer y pon esos commits en algún lugar de la historia Si durante mucho tiempo no tocamos esos comandos, entonces solo Git eliminará esos comandos. Así recuperamos nuestros comads perdidos usando f log. Ahora bien, la única pregunta que me hacen muchos alumnos es, podemos ver solamente el referencia headpointer o podemos ver cualquier registro de referencia de punteros tienes razón con el comando Git flog, podemos ver cualquier registro tienes razón con el comando Git flog, de referencia de punteros Actualmente, no tenemos ninguna sucursal. Te mostraré el f log de este puntero maestro. Git flog show, y aquí escribimos nuestro nombre de puntero, que es master Tenemos sucursal llamada carrito de características, luego escribimos aquí carrito de características. Consulta aquí obtenemos registro de referencia para Puntero maestro. Es lo mismo que el puntero de cabeza porque se mueven juntos en esta historia. Ahora actualmente, vemos todas las referencias o podemos ver la historia completa. ¿Y si queremos ver solo los últimos cinco momentos de nuestro puntero maestro? Podemos simplemente escribir aquí N espacio. Aquí escribimos cinco. Mira, aquí solo obtenemos los últimos cinco momentos de nuestro puntero maestro. Esto es muy útil, eso es todo acerca de ref log. Ahora en la siguiente lección, veremos cómo podemos hacer cambios en la comi existente 93. Modifica el Commit reciente: Ahora veamos enmendar comando. Por lo que enmendar significa corrección. Podemos hacer la corrección en nuestro comando reciente sin crear un nuevo comando. Déjame mostrarte. Entonces aquí en el archivo ML de punto índice, simplemente cambiamos el título a Cartwigs Modern Ecommerce Guardar los cambios menos son estos cambios y confirme este cambio con el mensaje de compromiso, actualizando el título de la aplicación. Ahora aquí hicimos nuestro Commit, y en nuestro título, encuentro que necesitamos capitalizar esta W en ortografía Cardi y también queremos agregar guión entre E y comercio Aquí no queremos crear un nuevo Camt para este pequeño cambio Aquí podemos usar comando de enmienda. Hacemos cambios en nuestro título, guardamos este archivo y enseñemos estos cambios. Para Gamat escribimos Puerta KamITF enmendar solo agregamos enmendar Aquí escribimos nuestro nuevo mensaje de compromiso. Además, si quieres usar el mismo mensaje de commit que el mensaje de commit anterior, entonces no escribimos nada aquí. Ver, aquí nos llega el mensaje de commit anterior. Cierra esto y listo. Actualizamos nuestro último kommt. Si queremos comprobar qué hemos cambiado en nuestro último Commit, entonces podemos escribir Git show. Ver, aquí obtenemos título actualizado. Ahora, una cosa que quiero aclarar es conseguir que no actualicen realmente el último Commit. Oficialmente crea un nuevo comando porque los commits de Git son inmutables, lo que significa que si creamos un commit, entonces Git no puede modificarlo Pero aquí se nota como si estuviera modificando el último commit. Ahora bien, ¿y si queremos agregar archivo en el commit anterior? Para eso, tenemos que hacer el mismo proceso que acabamos de hacer. Aquí en nuestro proyecto, creamos un nuevo archivo, scrape dot js y dentro de él simplemente consola dot log Este es un archivo de script. Guarda este archivo y vuelve a Git pas aquí montamos nuestros cambios y simplemente podemos usar Git commit, dd amend. No cambiemos el mensaje de compromiso. Ahora, vamos a revisar nuestro último compromiso. Ahora como agregamos un nuevo archivo en nuestro último commit, ¿cómo podemos eliminar el archivo? Es un poco complicado. Entonces para eso, primero lo usamos reset, y aquí usamos la opción mixta de DDs porque solo queremos restablecer nuestro historial de commit, y además restablecemos de etapa nuestro directorio de trabajo permanecerá igual que antes, área de enseñanza y commit se restablecerán Así que consigue restablecer como lo hace mixto, Dirígete hasta uno. C, desmontamos los cambios, y en el archivo STML de punto índice, obtenemos nuestro título Así podemos eliminar este archivo temp y ahora podemos escenificar nuestros cambios. Y luego en lugar de usar Git commit, amend, usamos simple commit porque restablecemos nuestro último commit y también le damos un mensaje, actualizando el título de la aplicación y creamos archivo script y listo. Entonces así es como funciona el comando de enmienda. Ahora bien, ¿y si queremos modificar alguno de estos commits, y lo veremos en la siguiente lección? 94. Modifica cualquier compromiso en la historia: Entonces, en la lección anterior, vemos cómo enmendar nuestro último cometa. Pero, ¿y si queremos modificar alguna anterior en? Digamos estos en estilos para índice STML cuerpo. En este medio, queremos cambiar el color de fondo de nuestro cuerpo. Entonces, ¿cómo podemos hacer eso? Es muy sencillo. Primero, vamos a comprobar qué cambiamos en ese abrigo. Así que Git show d35, CB 01. Ver, aquí podemos ver agregamos estilo para cuerpo, pero quiero cambiar este color de fondo. Aquí vamos a usar el comando rebase. Déjame explicarte lo que hace el comando base. Imagina aquí tenemos seis commits A a F, y queremos cambiar commit, digamos C. Tenemos que rebasar para commit B porque commit C base es commit B. Así que aquí hacemos cambios en nuestra commit C, y como sabemos, los commits de Git son inmutables Git no puede cambiar la confirmación. Git crea una nueva confirmación que tiene nuestros cambios y luego la rebase con commit B. Podrías preguntar, ¿cómo puede Git reemplazar C commit con commit C ¿Y qué pasa con los commit D, E y F? La respuesta es Git no reemplace el commit C con C. En lugar de reemplazar commit C, aquí, Git create commit, igual que este commit D, pero ese commit tiene también el cambio que hacemos en CDs. Si Git elimina ese cambio en la siguiente confirmación, entonces ¿cuál es el punto de esto? Entonces es por eso que Git Pi exactamente mismo commit que commit D, pero con cambios. Lo mismo ocurre con commit E y commit F. Git elimina esta rama anterior, y así es como al usar git rebase, podemos modificar cualquier commit en nuestro historial Pero asegúrate de que solo cambiemos aquellas confirmaciones que no son empujadas porque rebase claramente reescribe la historia Ahora veamos rebasar en acción. Entonces aquí, que comprometemos queremos cambiar. Escribe éste. Entonces copiamos el ID de confirmación de su base, que es su confirmación anterior. Recuerda siempre para rebase, tenemos que tomar referencia de confirmación previa Ahora para rebase, escribimos git rebase I para interactivo. Básicamente, queremos decirle a Git. Queremos interactuar o hacer cambios en nuestros commits. Y aquí escribimos nuestro commit base, que es 4239 CEC Consulta aquí en nuestro editor de código, obtenemos este tipo de interfaz. Por ahora, no usamos esta interfaz porque te va a confundir Veremos cómo usar esta interfaz en las próximas lecciones. Aquí, desde abajo, hemos cambiado a opción de texto. Aquí obtenemos este tipo de líneas. No te preocupes. Estos son solo un script que git va a ejecutar, y estos son todos medicamentos desde nuestro antiguo hasta el último orden de confirmación Aquí al inicio de cada amet, tenemos opción de PC, tenemos opción de PC, lo que significa que Git simplemente escoge esos cometas de la historia y lo rebase Ahora bien, ¿y si queremos cambiar este amet? Entonces en la parte inferior del archivo, obtenemos muchas opciones y es explicación. Entonces para editar en el lugar de pico escribimos editar. Ahora no queremos editar otras amidas, pero si queremos hacer, entonces también podemos escribir aquí, editar, guardar este archivo, encerrar ambos archivos Mira, aquí nos detenemos en este Camt para editar, y actualmente estamos en rebasar uno de cinco, y podemos ver que ya podemos modificar este compromiso Entonces ahora podemos cambiar lo que queremos cambiar en este abrigo. Así que en estilo punto archivo CSS, quiero cambiar el color de fondo a blanco. Y color a tiene 101010. Guarde los cambios, y probemos estos cambios. Y también Gt ka mate, guión, guión, enmienda. Lo siento, es un errata. Entonces, abrigo de puerta, guión, guión, enmienda. Seguimos con el mensaje de omitir. Así que cierra esto. Ahora en esta etapa, veamos la historia. Ves, como te dije, Git inicia una nueva sucursal, y esta es nuestra base en. Y aquí en la parte superior, obtenemos nuestro actualizado Modifique Camt Ahora cuando continuemos con esta rebase, entonces Git escoge estas amidas y se la pone en esta Camt y luego quita estos viejos Ahora para continuar con esta rebase, escribimos git rebase O si queremos sobre, entonces podemos escribir sobre. Por ahora, continuemos esta rebase y no tenemos ningún otro dits, Git rápidamente completa este proceso Ahora vamos a revisar nuestro historial. Aquí podemos ver que nuestra historia vuelve a ser lineal. Si observas, te das cuenta todos los cometas ID son diferentes a los cometas anteriores Entonces se confirma que Git crea nuevos cometas. Pero como sabemos, esto es para organizar la historia. Ahora si vemos en nuestro código, entonces también obtenemos esos cambios en nuestro archivo CSS de puntos de estilo. Los cambios que modificamos en que Camt también está disponible en todas estas amidas Así es como modificamos cualquier Camd usando git rebase I. 95. Cómo abandonar todo el commit: Dejar caer un todo en es útil cuando bi comprometemos erróneamente nuestro trabajo Pero cuando dejamos caer cualquier camet, tenemos que tener en cuenta que estamos rechazando todos los cambios que hicimos en ese En nuestra historia, tenemos este trabajo en progreso en, lo que bimstakally hice Veamos qué me comprometo en esto al andar, mostrar AC a 49c Aquí podemos ver en el archivo ML de punto índice. En lugar de este texto, agregamos esta etiqueta he, y en estilo archivo CSS, agregamos este estilo para sección. Ahora bien, si dejamos caer este comando, entonces estos cambios irán. Entonces para caer también, usaremos rebase. En nuestro ejemplo anterior, tenemos seis commits, y si queremos soltar esta commit C, entonces usamos gate rebase I, y aquí comenzamos con base que es Commit B. Y luego soltamos esta commit C. Aquí, nuevamente, creamos una nueva commit para commit D, E y F y luego las reemplazamos con Commit B, eso es simple drop Aquí, nuevamente, creamos una nueva commit para commit D, E y F y luego las reemplazamos con Commit B, eso es simple drop Ahora bien, y si en este commit C, creamos un archivo llamado página DML En cualquiera de estos tres commits, cambiamos algo en ese archivo. Entonces llegamos aquí conflicto porque cuando dejamos caer Commit C, entonces nuestro archivo pg ML también caerá. Y en nuestros otros commits, estamos haciendo cambios en esta página punto S archivo DML Entonces aquí tenemos conflicto. No te preocupes, lo resolveremos ya que está usando la herramienta Merge. También es muy sencillo. Sólo te digo que el conflicto puede suceder si dejamos caer nuestro compromiso. En nuestro ejemplo, aquí tenemos estos cambios. Dejemos caer este compromiso y veamos que tenemos conflicto o no. ¿Qué opinas? A ver. Entonces primero, escribimos git rebase I y aquí escribimos nuestro ID de commit anterior, que es nuestra base Nuevamente, aquí vamos al cambio a texto y aquí obtenemos estos guiones. Ahora queremos dejar caer este abrigo en el lugar de este pico, escribimos drop o podemos quitar este todo en del script, guardar los cambios, cerrar estos archivos y ver aquí conseguimos rebasar con éxito si revisamos nuestro historial, luego ver que el progreso de trabajo kate se ha ido porque no obtenemos conflicto Déjame mostrarte qué debemos hacer si tenemos conflicto porque eso podría confundirte y no quiero que te confundas Aquí en nuestro proyecto en carpeta de componentes, creamos un nuevo archivo llamado myders dot HTML En este archivo, simplemente agregue aquí H una etiqueta, y esta es mi página de Pedido. Los cambios y vamos estos cambios. Además, consigue crear mi pedido punto DML página. Bueno. Ahora, de nuevo, cambiamos algo en este archivo. Entonces en etiqueta ST, digamos que esta es la lista de pedidos. Guarde los genes, y también vamos a escenificar esto y comprometerlo también con las actualizaciones de mensajes de Commit para la página Pedidos. Ahora veamos nuestra historia. Digamos que queremos abandonar este segundo commit. Así que hacemos git rebase I y commit ID de nuestra base, que es 9981 Asegúrate de escribir tu identificación de compromiso. Aquí nuevamente obtenemos scripts en nuestro editor de código. Queremos dejar este commit, para que podamos eliminar este commit de aquí. Guarde este archivo, y también cerremos este archivo. En el Git Bash, mira, aquí tenemos conflicto porque dejamos caer nuestro commit y en ese comando, estamos descartando todos los cambios, que es que es que creamos Moder dot Eliminamos mi pedido punto sdmlfle y en el siguiente commit, estamos haciendo cambios en ese mismo estamos haciendo cambios en ese Entonces por eso tenemos conflicto. La mayoría de las veces, no enfrentamos esta situación. Pero si a veces ocurre, entonces podemos hacer así. Podemos verificar nuestro estado usando el estado de Git como a, C, aquí obtenemos D y U, lo que significa eliminación y actualización. Entonces para resolverlos, simplemente escribimos aquí git merge tool. Ver, aquí obtenemos borrado conflicto de fusión para componentes slash Moder punto STml Local se elimina y remoto, lo que está indicando En esos tenemos modificación. Entonces para modificado, podemos escribir A, para eliminar, escribimos D, y para Abortar, podemos escribir A. Aquí no queremos eliminar nuestro archivo Vamos por Modificar porque queremos mantener esta página de Moder en nuestro Cmd Ahora si revisamos de nuevo nuestro estado, entonces aquí nos agregan y obtenemos este Moder punto STml punto ORIG, que es el archivo temporal que Gate crea durante el Podemos ignorarlo o también podemos eliminarlo de nuestro proyecto. Ahora continuemos con nuestro proceso de rebase usando Continuar rebasado Vamos con el mismo mensaje y listo. Ahora, si volvemos a revisar nuestro historial, vea nuestras caídas en medio con éxito. Entonces así es como dejamos caer nuestro medio. Ahora en la siguiente lección, veremos cómo solo podemos cambiar el mensaje Commit. 96. Cambiar el mensaje de confirmación: Ahora en nuestra historia actual, supongamos que quiero cambiar el mensaje de commit de este segundo commit porque el mensaje no es claro. qué se refiere con cambios en la estrategia de índice ML, que cambian. Y este tipo de mensaje de compromiso puede crear mucha confusión. Así que siempre es mejor cambiar estos mensajes, así nuestra historia parece significativa. Primero, déjame ver qué hice realmente en ese commit. De veras se me olvidó eso. Obtener espectáculo D seis, un 7d59 Bien, aquí agrego esta sección de lista de productos. Entonces para cambiar el mensaje de commit, también usamos aquí rebase Obtener rebase I, y aquí escribimos nuestro ID de commit base, que es 61a8 Solo ten en cuenta, el commit base siempre es uno que viene por delante de Commit que queremos rebasar De nuevo, llegamos aquí guión. Ahora por cambiar el mensaje de commit en el lugar de pico, escribimos recompensa. Aquí también podemos reformular múltiples comandos. Supongamos que este último comando queremos reformular. Aquí escribimos reword. Ahora cuando cerremos este archivo, nos pedirá el mensaje de commit actualizado para qué comandos agregamos reword Déjame mostrarte guardar estos cerrar estos archivos. Ver, pido mensaje de compromiso para nuestro primer comando. Aquí escribimos agregando sección de lista de productos en el archivo DML de punto índice Guarde esto y cierre este archivo. Y nuevamente, podemos escribir un mensaje de compromiso para nuestro último compromiso por el que nos recompensamos. Estoy contento con este mensaje. Así que vamos a por ello y listo. Ahora si revisamos nuestro historial, vea, aquí obtenemos un mensaje de compromiso actualizado. Ahora aquí, de nuevo quiero decirles, como hacemos pagos, como hacemos pagos, nuevamente crean este Camt y como se recrea este commit, los todos los abrigos van a recrear los todos los abrigos Entonces es muy claro que estamos reescribiendo la historia. Está bien si tenemos gametos en nuestro repositorio local, pero no debemos cambiar los gametos que ya están empujados en el repositorio remoto 97. Cambia las posiciones de los commits: Ahora, en nuestra historia, si queremos mover commits arriba y abajo, digamos, aquí tenemos esto actualizando el título de la aplicación y crear script file Commit. Queremos mover este commit debajo de este nombre de clase de anuncio en index dot sdmlKit Entonces aquí volvemos a empezar a rebasar obtener rebasi aquí escribimos nombre base del cometa donde queremos Supongamos aquí tenemos diez cometas, queremos mover el seis cometa tras el tercer encuentro Ante esta situación, comenzamos el proceso de rebasar a partir del cometa dos porque eso va a ser Ahora supongamos que si queremos colocar el seis cometa después de ocho cametas, entonces empezamos a rebasar a partir del Para cambiar la posición del repositorio, siempre comenzamos a rebasar desde el punto más bajo Por eso aquí empezamos a rebasar desde esta posición. Nueve E cuatro, CD tres D. Así que nuestro guión de rebase tiene estos todos los kats Ahora aquí, podemos simplemente mover líneas en qué orden, queremos reordenar repositorio Entonces vamos al título de actualización y archivo de script Cat y simplemente manteniendo presionado Alt u Opción, flecha arriba y abajo, podemos cambiar la posición de los abrigos en la historia, moverlo a la parte superior de la historia y guardar este archivo y cruzar estos archivos. Mira, aquí conseguimos una rebase exitosa. Vamos a revisar nuestro historial. Mira esto en moverte al fondo, así es como podemos cambiar la posición de nuestros amets. Ahora en la siguiente lección, veremos ¿cómo podemos fusionar dos o más ametes en un solo amet 98. Rompe dos o más compromisos: Ahora veamos cómo podemos combinar dos o tres cometas. Entonces aquí en nuestra historia, podemos ver agregar el nombre de clase en archivo SML de punto índice y agregar estilos para el cuerpo del índice dotlFle Estos dos códigos pueden combinarse en un solo cometa porque ese es el mismo proceso Entonces los combinaremos juntos. Aquí, nuevamente iniciamos el proceso de rebase desde aquí. Así que consigue rebase I seis F EA tres F ocho. Nuevamente, cambiamos al texto. Ahora queremos combinar este segundo commit en nuestro primer commit. Entonces para el segundo commit en el lugar de pico, escribimos squash. Si también queremos combinar este tercer commit en este ambos, entonces también podemos escribir aquí squash. Por ahora, no queremos eso, así que volvemos a echar un vistazo Guarde este archivo y cierre estos archivos. Ahora Git nos preguntará por el nuevo mensaje de commit. Aquí obtenemos todos los mensajes de commit, que commits aplastamos. Entonces aquí, estoy eligiendo este primer mensaje de commit y elimino el segundo mensaje. Y también, podemos cambiar este mensaje de commit para agregar estilos para index dot StML Guarde este archivo y cierre. Vea aquí nuestra rebase completada con éxito. Veamos nuestra historia. Mira, solo obtenemos un coamte en nuestra historia de Comte. Ahora supongamos que combinamos torpemente estos abrigos . ¿Y si queremos deshacer la última rebase? Entonces aquí usamos el registro de Gid Raf. Aquí podemos ver en la parte superior, tenemos acabado de rebase. Después de eso, tenemos pico, pico, pico, squash y inicio de rebase Entonces tenemos que movernos a este Camt donde terminamos nuestra anterior rebase Copia esta identificación de Cait, y pasemos al fondo Y aquí escribimos Git, restablece duro a esta Cam Vamos a revisar nuestro historial. Mira aquí volvemos a llegar, esos dos kamts separados Ahora la razón por la que deshacemos esta calabaza es porque hay otra manera de combinar nuestras amidas. Nuevamente escribimos, obtenemos base I, nuestra base amet aquí obtenemos rebase script Ahora en el lugar de escribir squash, podemos escribir Fix up. Ahora podrías preguntarte, ¿cuál es la diferencia entre squash y fix up? Entonces son casi iguales. Pero como sabemos, cuando usamos squash, después de eso, tenemos la oportunidad de escribir un mensaje de commit para ese commit combinado. Pero cuando usamos Fix up, entonces no tenemos la oportunidad de escribir un mensaje de compromiso. Obtener pick el primer mensaje de commit como el mensaje de commit combinado. Aquí, nuestro primer commit de repositorio combinado es este. Por lo que elegirá este mensaje de compromiso. Guarde esto y cierre el archivo. Ver, kit automáticamente completar el proceso de rebase sin pedir mensaje de compromiso, y obtenemos ese mensaje en nuestro historial Ahora en la siguiente lección, veremos cómo podemos dividir un solo commit en dos o más commits. 99. Dividir los compromisos: Ahora veamos el último tema de reescribir el historial de commit, que es dividiendo grandes ametes en pequeños Aquí en este Camt creamos página CAT y también página de perfil de usuario Esto puede ser grande Kummet. Podemos dividir este solo Camt en dos cometas, uno para la página CAT y otro para la página de perfil de usuario Aquí, nuestra base Camt también está un cometa por delante de esto en. Déjame mostrarte otra forma de escribir previo en medio. Aquí, seleccionamos nuestro commit actual y copiamos su ID. Ahora, escribimos, git rebase paso ese ID de commit actual, y olvidando commit anterior, usamos aquí signo de quilates Esto significa este compromiso. Aquí cambiamos al texto. Ahora bien, este amit lo queremos dividir. Entonces aquí escribimos, editamos en el lugar de pico. Entonces cuando cerramos este archivo, se quedará en este commit, y luego mediante el uso del comando reset, podremos separar nuestros ammts Déjame mostrarte prácticamente. Guarde este archivo y ciérrelo. Ver estamos en proceso de rebasar. Veamos dónde estamos exactamente en nuestra historia. Git log, mira, actualmente estamos en este Camt porque nuestra cabeza está aquí Ahora lo que queremos hacer es que usaremos el comando reset para eliminar nuestro código comite actual del área de puesta en escena y también de nuestro amet Aquí, escribimos git reset, soft, pero eso solo eliminará nuestro código de at. También quieres eliminar el código de nuestra zona de espera. Para eso, escribimos aquí, es mixto. Ahora estamos reiniciando el código de commit actual al cual código commit Reiniciaremos al cometa anterior. Cabeza, buharrón. Ahora en nuestro directorio de trabajo, tenemos todos los cambios que hemos hecho en ese gran medio, pero no son escenario o no en gato. Déjame aclarar eso con el estado de Git. Mira, aquí tenemos dos archivos sin seguimiento. Entonces aquí podemos hacer tantos commits como queramos. Primero, vamos a comprometernos para la página del carrito. Así que escenificamos primer archivo de página de carrito, Git add components slash cart dot sgML Nos comprometemos a cambiar. Git commit, implementa la función de carrito. Ahora vamos a revisar nuestro historial. Ver, aquí obtenemos historia diversa porque nuestra base es esta y aquí nuestros coamts anteriores Ahora vamos a crear otro commit para el perfil de usuario. Escenamos aquí componentes barra perfil de usuario punto SGML, y también CommitateGT Ahora la razón por la que no usamos aquí modificar commit porque no queremos cambiar en nuestro commit actual. Aquí queremos crear un nuevo Cat. Así git dM, Implementar función de perfil de usuario. Ahora vamos a revisar nuestro historial. Ver en la parte superior, obtenemos dos cometas separados No te preocupes, todavía estamos en el proceso de rebase. Esta no es la salida final. Ahora cuando continuemos nuestro proceso de repase, entonces Git recreará a estos otros cometas y lo pondrá encima de estos dos comemetas por eso, entonces Git recreará a estos otros cometas y lo pondrá encima de estos dos comemetas por eso, nosotros gat historia lineal. Git rebase continuar. Bien, rebasamos con éxito. Verifiquemos eso por historia. Mira aquí obtenemos dos commits separados y nuestro gran commit se ha ido de nuestra historia. Para recapitular rápido, primero iniciamos el proceso de rebase, luego lo usamos comando en el script de rebase Después de eso, cuando estamos en ese gran commit, eliminamos nuestro código actual del área de ensayo y cometemos área usando git reset, quilates de cabeza mixta. Carat de cabeza significa que reiniciamos nuestro área de espera y comprometemos el código al código de compromiso anterior. Aquí, podemos escenificar los cambios y comprometerlos, Commit uno, y también nuevamente escenificar los cambios, y luego commit, que puede ser Commit two. Y entonces podremos continuar el proceso Bs y completarlo para que S divida Commit y reescriba nuestra historia 100. Reescribe la historia con GitKraken: Ahora veamos cómo podemos reescribir nuestra historia usando Git Kraken Aquí duplico el proyecto que te doy para practicar al inicio de esta sección y simplemente abro eso en puerta Kraken Aquí tenemos todas las malas medicinas y queremos realizar reescribir la Ahora reescribir el historial es súper fácil en el cracker de puerta y es el mismo proceso en el código VS también Ahora reescribir la historia significa que tenemos que rebasar. Aquí queremos iniciar proceso de rebase como base de esto en Así que escribimos click en ese commit y simplemente seleccionamos aquí rebase interactiva a partir de este commit En palabras simples, que comprometemos seleccionamos, se establecerá como base kommt Ahora aquí simplemente obtenemos este tipo de script de rebase. Ya vimos esta interfaz en el código Vas. Aquí, a partir de este desplegable, podemos cambiar el comando. Ver para primer commit selecciono reword. Aquí podemos cambiar nuestro mensaje de compromiso. En el lugar de los cambios en el punto índice SDML, escribimos agregar lista de productos en archivo SGML de punto índice y actualizamos el mensaje Ahora también queremos fusionar este tercer comando en este segundo comando, podemos seleccionar aquí squash y ver usando flecha, obtenemos claro squash. Ahora aquí queremos dejar caer también esta capa de trabajo en progreso. Si obtenemos conflts, entonces Git kraken, pide modificación, eliminación, y Igual que Gitask en nuestro Git Bash. Empecemos la rebase ver, aquí tenemos conflicto y podemos ver archivos conflictivos en el lado derecho Da click en eso y aquí tomamos cambios de B y simplemente hacemos C. C, el conflicto se ha ido, y ahora podemos continuar esta rebase o también podemos abortar Vamos por Continuar y ver que todos los cambios están hechos. Esa es una base simple en Git Kraken y viscode. Pero aquí hay una cosa. Yo Git Kraken o en código Vs, podemos hacer enmendar cometer o dividir cometas Para eso, tenemos que usar terminal. Por eso primero te muestro Git usando la línea de comandos y luego para las herramientas GI. Ahora, oficialmente cubrimos todos los temas de la marcha. ¿Qué opinas? ¿Qué es lo que más te gusta de Git? Utilizarlo en terminal o usarlo con herramientas de interfaz de usuario. Me gusta usar la línea de comandos para todos los comandos y herramientas GI para ver el historial y rebase Tu elección puede verse diferente, pero es tu elección personal. Al final del día, tienes que trabajar en tu sistema. Sea lo que sea que usemos, nuestro trabajo debe hacerse. 101. Sección 07 Los comandos de Git más utilizados: Bienvenido a la sección de recapitulaciones del curso definitivo de Git. En esta sección, veremos todos los comandos que son más comunes en la vida de los desarrolladores. Es como una revisión de conceptos de git. Así que sostén un poco de agua y disfruta de esta sección. 102. Fundamentos y comandos de historia de Git: Empecemos con los comandos básicos de Git. En primer lugar, para inicializar nuestro proyecto, utilizamos el comando Gain init. O si ya tenemos proyecto en Cloud, entonces usamos clon de Git, y URL. Después de obtener nuestro proyecto, podemos hacer cambios en nuestro código, y luego podemos escenificar esos cambios usando Git add. Y aquí escribimos nuestro nombre de archivo. La puesta en escena de los cambios significa que estos cambios están listos para el pelaje. Es como zona de espera. Ahora bien, si quieres escenificar todos los cambios, entonces escribimos aquí Git add period. Entonces, si quieres ver nuestro estado actual, entonces escribimos Git status o git status para short status. Ahora, después de satisfacer nuestros cambios, nos comprometemos a los cambios para almacenar ese código en nuestro historial de puertas, para almacenar ese código en nuestro historial de puertas usando Git commit, y agregamos aquí mensaje. Aquí, asegúrate de escribir un mensaje significativo. Si no agregamos ningún archivo nuevo, entonces podemos usar este comando de atajo, Git commit AM message. Mediante este comando, podemos escenificar y comprometer nuestro código en un solo comando. Ahora bien, si quieres ver la diferencia entre código de área de trabajo y el código de área de puesta en escena, entonces podemos usar Git DF si queremos ver diferencia entre el código de área de prueba y el código comprometido, entonces podemos usar Git dif, stage, o podemos usar Git Di dash dash cast. Después de eso, si queremos ver nuestro historial de commits, entonces podemos usar el comando Git log. Y si queremos ver el historial en una línea, entonces podemos usar Git log, dash one line. También podemos agregar otras opciones como y graficar para el historial de grafos. Después de eso, si queremos ver qué cambiamos en Commit, entonces podemos usar Git, show, y commit ID. Además, podemos usar su puntero de cabeza y si queremos ver un archivo específico, entonces podemos usar Git, show, commit reference y con columna, escribimos nuestra ruta de archivo. Así que a veces queremos cambiar el código de una commit a otra. Entonces podemos usar Git checkout, commit ID, o también podemos usar Git, switch, commit ID. Ahora bien, si en nuestro proyecto, alguien escribe muy mal código, y para verificar al autor de cada línea, podemos usar Git, culpar y aquí escribimos nuestra ruta de archivo a la que queremos culpar. Si queremos ver líneas particulares, entonces podemos agregar aquí la opción L, y aquí escribimos la línea inicial coma final número de línea Después de eso, otro comando más utilizado para marcar Git commits es git tag, tag name. Luego escribimos nuestro ID de commit para el que queremos crear esta etiqueta. Si queremos eliminar la etiqueta, entonces usamos la etiqueta Git, D, y aquí escribimos nuestro nombre de etiqueta y para C, la lista de etiquetas, simplemente usamos el comando Git tag. Estos son los comandos importantes relacionados con los conceptos básicos de Git y para ver el historial de commit. 103. Comandos de ramificación y fusión: Ahora, recapitulemos sobre las sucursales. Cuando quieras trabajar en una función separada o simplemente quieres trabajar en tu equipo, entonces debes crear una nueva sucursal y trabajar en esa sucursal. Si queremos ver la lista de todas las ramas, entonces tenemos comando git branch. Y para crear una nueva rama, usamos rama Git y nombre de rama. Después de crear una nueva rama, necesitamos cambiar a esa rama, y podemos hacerlo usando Git switch branch name. Ahora bien, si queremos crear una nueva rama y también queremos cambiar en un solo comando, entonces escribimos Git switch, C, y nombre de rama. Ahora para ver cuáles son las diferencias entre una rama en particular y nuestra rama actual, entonces podemos escribir el nombre de la rama Git Div. Además, podemos ver la diferencia entre dos ramas usando Git, D rama uno, punto punto rama dos. Ahora bien, si estamos trabajando en la rama uno y de pronto tenemos que trabajar en la rama dos, la en lugar de cometer medio código, podemos stass ese código Escaleras es como, mantener ese código en una esquina, entonces podemos cambiar a otra sucursal y completar nuestra o después de eso, podemos aplicar las escaleras en nuestra sucursal anterior. Para crear las escaleras, usamos Git stairs, push, y aquí agregamos mensaje Ss para ver todas las escaleras, usamos Git stats list. Ahora, si queremos aplicar cambios de escaleras en nuestro directorio de trabajo, entonces podemos usar Git, apply y stats ID. Después de aplicar los cambios de esa escalera, podemos dejar esas escaleras usando git stash, drop y stats ID Y si queremos eliminar todas las estancias del proyecto, entonces podemos usar Git clear. Ahora, después de eso, si terminamos con nuestra sucursal, entonces podemos fusionarla con nuestra sucursal principal. Y para eso, podemos cambiar a rama principal, y luego podemos fusionarla usando git merge branch name. Si tenemos historia divergente, entonces Git hará fusión de tres vías, y si tenemos historia lineal, entonces Git hará pasar por nuestra Después de fusionar nuestra sucursal en rama principal, podemos soltar esa rama usando Git branch, D, branch name. Si queremos soltar con fuerza esa rama, entonces podemos usar Git branch, D, branch name Además, podemos restablecer el Kamed a la versión anterior usando git reset En reset, tenemos tres variaciones. Git reset, dash dash soft, Kate, que restablece el código de coat, git reset, dads mixed, que restablece el código de a y de Camt Si usamos Git reset ds hard, entonces nuestro código de área completo se restablece con ese código comite Ahora también podemos revertir el amid y la diferencia entre reset y amid es con revert, Git crea un nuevo met, pero en reset, Git no crea un nuevo Hará cambios en el Camt actual. Para revertir, usamos Git revert y si queremos volver a padre uno, que es el cometa anterior de nuestra rama actual, entonces escribimos aquí uno y después de eso, escribimos Comte, que queremos revertir, que es cabeza Por fin, si quieres copiar un código Comite en nuestro Camt actual sin fusionarlo, entonces podemos usar Git cherry peak Esta es la visión general de ramificación y fusión. 104. Trabaja en comandos de equipo: Ahora recapitulemos sobre trabajar en equipo. En primer lugar, cuando estamos trabajando en equipo, mayoría de los comandos que usamos es git fetch, que se usa para recuperar cambios de todas las ramas de nuestro repositorio en la nube Después de eso, si queremos específicamente obtener cambios de una sola rama, entonces podemos escribir git fetch entonces podemos escribir git fetch Aquí escribimos nuestro nombre remoto origen, que es el nombre remoto y de sucursal más utilizado. Si queremos fetch de master, entonces podemos escribir git fetch origin master o podemos escribir git fetch solamente. Esto va a funcionar igual. Ahora, como sabemos, al usar el comando fetch, solo obtendremos cambios en nuestra historia Nuestro directorio de trabajo permanece igual que antes. Si queremos aplicar directamente esos cambios desde remoto, entonces en el lugar de git fetch, usamos git pull Pero ten en cuenta, va a crear un nuevo commit. Ahora si hemos terminado con nuestros cambios y queremos empujar los cambios a la nube. Tenemos que escribir git push origin, master o main, cualquiera que sea nuestro proyecto. Además, podemos usar aquí el comando de atajo, que es Git push. Ahora también podemos empujar nuestra etiqueta al control remoto usando git push, origin y tag name para eliminar la etiqueta del origen, usamos git push origin, dash delete, tag name. Ahora bien, si creamos una nueva rama y queremos empujar esa rama al origen, entonces tenemos que crear primero la rama upstream. Escribimos git push origin branch name. Después de eso, si de nuevo queremos empujar cambios en esta rama, entonces podemos usar simple push de puerta. Git impulsará los cambios a esa rama, eso se trata de trabajar en equipo. 105. Muchas gracias: Entonces enhorabuena. Acabas completar el curso definitivo de Git y Github. Y solo quiero preguntarte, ¿aprendiste el git? ¿Pude explicar conceptos que te ayudarán a entender a Git? Eso espero de verdad. Y en este video, solo quiero decir, muchas gracias por ver este completarlo y curso de Github. Estoy muy, muy agradecida por eso. Y por favor, si quieres compartir tu opinión sobre este curso, entonces en la parte superior, puedes ver el botón de bating, y por eso, puedes compartir tu reseña Lo que quieras decir, positivo o negativo es realmente importante para mí. Dar esta retroalimentación no tomará más de 10 segundos, pero eso me dará inspiración y motivación para crear más cursos mejores, y también me ayudará a llegar a más estudiantes que quieran aprender Git y Github como tú. Muchas gracias por ver este curso y todo lo mejor en el viaje de tu desarrollador, y espero que todos tus sueños se hagan realidad.