Clase magistral de Git y GitHub: ¡acelera tu viaje a Git!

1. Video de introducción: Bienvenido a este curso sobre Git y GitHub. Estas son algunas de las razones por las que debes aprender Git y GitHub. Más de 83 millones de dólares por ciento en todo el mundo usan Get up. El 90% de las empresas financiadas por Fortune usan GitHub. Más de 200 más millones de repositorios son proyectos que actualmente residen en GitHub. Github es un componente clave de tu viaje de DevOps. De hecho, si quieres perseguir DevOps Catia, GitHub es un punto de partida. No vas a llegar a ninguna parte a menos que aprendas GitHub. Github es también la plataforma de alojamiento de código más popular en comparación con sus competidores, como Bitbucket o GitLab, get es el sistema de control de versiones más popular que haya existido. Es casi una habilidad imprescindible para cualquier profesional de TI. Y supongo que ya lo sabes. Aquí están los objetivos de este curso. Te enseñaré todo lo que necesitas saber sobre Git y GitHub. Lo uso desde 2014 e incluso he tenido experiencia en la gestión de equipos y en el cumplimiento de los plazos del proyecto. Tengo afinar el plan de estudios en consecuencia. Y no tienes que referirte a ningún otro libro ni a otros cursos. Aprenderás todo lo que necesitas en este curso solo y no necesitas ir. Cualquier cosa más allá de esto. Haz que te sientas seguro para manejar cualquier tarea de proyecto relacionada con Git y GitHub. Enséñate a contribuir a proyectos de código abierto y hacerte sentir seguro con entrevistas. Pero, ¿por qué deberías aprender de este curso? Aldi, temas importantes y esenciales se tratan en los primeros capítulos. Y todos los temas que no son esenciales o discuten más adelante en el curso. Tan sólo estamos atentos de seis a diez capítulos. Empezarás a sentirte confiado para empezar a asumir la tarea más tarde para levantarte. Dicho esto, le recomiendo encarecidamente que vigile todo el curso. Para aprender toda la asignatura. Combino múltiples temas relacionados en la misma conferencia para ahorrar su precioso tiempo. Si tiene sentido para mí combinar múltiples temas relacionados y enseñarlos juntos, siempre hago eso. No sólo para ahorrar tiempo, sino también para enseñar de manera más efectiva. Te enseñaré este objeto con escenarios del mundo real, casos de uso y flujos de trabajo. Yo mismo he manejado algunos de los retos más difíciles del proyecto. Y sin duda puedo usar esa experiencia para hablar de algunos de los escenarios del mundo real donde se pueden aplicar todos estos conceptos. Tengo una habilidad única para enseñar conceptos muy complejos de manera fácil de entender. Entenderás esto por ti mismo una vez que avances en este curso. También tengo expectativas sobre quién está viendo este curso. Olvídate de lo que ya sabes y empieza de nuevo. Si ya sabes algo sobre Git y GitHub o cualquier tema relacionado, quiero que simplemente borres todo de tu mente y empieces con una mente limpia. De lo contrario, podrías escuchar algunas terminologías conflictivas, que podrían empezar a confundirte. Dedicación y compromiso para aprender el intersujeto estaban viviendo en el mundo de las distracciones. A menos que pongas esfuerzos para mantenerte comprometido y dedicado a aprender todo el tema, realmente no estás aprendiendo nada. Practicar lo que enseño. Practicar por una vez equivale a diez veces de lectura fijada por alguien en alguna parte. Pero tiene perfecto sentido. Deberías tratar de practicar lo que enseño. De lo contrario, podrías perder la pista del tema y confundirte. Manténgase enfocado en un curso, ya sea que tome este curso o algún otro curso, complete completamente, y luego cambie a otra fuente de información si lo desea. Pero no mezcles las cosas, lo que volverá a crear mucha confusión. Dedica solo una hora todos los días sin distracciones. Es mejor aprender durante una hora con enfoque completo que aprender durante ocho horas con enfoque no tan bueno. Tengan eso en cuenta. A continuación empezaremos a entender qué es conseguir Github, ¿qué es el sistema de control de versiones, etcétera, con ejemplos del mundo real? Y esa es una gran manera de comenzar nuestro curso. Nos vemos a continuación. 2. 0101 Need For Version Control System y Git Parte 1: ¿ Por qué necesitamos sistema de control de versiones? Conoce al señor Bob, quien es asesor de inversiones. Y debido a todo el increíble trabajo que está haciendo, su base de clientes ha aumentado significativamente con el tiempo. Y así ve la necesidad de tener su propio sitio web personal. Entonces Bob había imaginado un sitio web propio. Y Bob siendo un tipo no técnico, pensó en tomar ayuda de un freelancer para hacer el trabajo. Por lo que conoció a remitente que es freelance o le inexplicaba todo lo que está esperando en su página web y darle la fecha límite como el 24 de febrero, que pasa a ser su cumpleaños a que está bajo una y comenzó a trabajar en el proyecto. Insights sobre esos computadores. Ahí se había creado esta carpeta llamada app de inversión, dentro de la cual creó todos estos archivos que harán ese sitio web. Después de unos días de descanso en el trabajo, cilindro finalmente había terminado trabajar en la creación del sitio web. Lo probó. También lo alojó en un proveedor de hosting o en un proveedor de servicios Cloud. Dios, la aplicación en marcha y se la mostró a Bob. Bob quedó bastante impresionado con el trabajo realizado por Sunder. Y así ahora decidió agregar un par de funcionalidades más a su sitio web. Y se obtiene la fecha límite el 20 de febrero. Dos mercancías más pronto una vez más, habían aceptado el trato y comenzaron a caminar sobre esas características adicionales. Y una vez más, cinder había agregado todas esas características, lo alojó en proveedor de hosting, puso el sitio web en funcionamiento y se lo mostró a Bob. Pero esta vez, sin embargo, bob no estaba completamente satisfecho con el trabajo. A pesar de que las últimas características introducidas después del 24 de febrero, estamos trabajando bien. Las características que funcionaban antes parecen haberse roto o no funcionan como se esperaba. Por lo que Bob había explicado las mismas dos cenizas y le había pedido deshacer todos los nuevos cambios y traer de vuelta la aplicación a lo que era el 24 de febrero. A ello pronto son aceptados vacilantemente. Pero desafortunadamente para Cinder, No va a ser una tarea fácil deshacer todos esos cambios porque hay mucho código nuevo introducido después del 24 de febrero, y el código se ha dispersado através de múltiples archivos. Es realmente difícil para el remitente recobrar todas y cada una de las líneas de código que se introdujeron y deshacer todos esos cambios. No obstante, ya que el que aceptó el trato, para mantener feliz al cliente, después de muchas noches de insomnio y después de mucha frustración y mucho centro de pruebas finalmente hizo el trabajo. No obstante, esta vez, en medio de la fecha límite de Bob, y Bob se preguntaba por qué tardó tan menos de un par de semanas sólo para deshacer los cambios. Bueno, sólo le tomó unos días crear todo el sitio web. Esto ha resultado en que Bob no esté satisfecho y pronto, pronto comenzó a ver tipos similares de problemas con algunos de sus otros clientes también. quejaban de que algunas de las características no funcionaban como se esperaba, lo cual había funcionado antes. Y así quisieron arreglarlos o quieren volver a versiones anteriores de sus aplicaciones web las cuales están funcionando bien. Así que Sunder le dio un pensamiento y finalmente se le ocurrió una idea genial, que son algo resolver este problema. Hablaremos de ello en un rato. 3. 0102 Need For Version Control System y Git Parte 2: Entonces lo que hay ahí había empezado a notar es que no tenía sitios web de clientes de Office de respaldo. Si tuvieras una copia de seguridad de sus sitios web, él tendrá oportunidad bien volver a la versión de trabajo anterior de su sitio web o al menos n miente el problema al comparar una versión con la otra. Cylinder se le ocurrió una idea brillante para resolver este problema. Lo que empezaste a hacer ahora es, por ejemplo, consideremos la app de inversión que estábamos hablando. Cinder crea una carpeta llamada app de inversión V1 y 14 de marzo, que es la fecha en la que este proyecto fue entregado al cliente. Y luego asumir que Bob le había pedido que introdujera un par de nuevas características. Esta vez cilindro no va a hacer ningún cambio en esta porción del proyecto. En cambio se va a hacer una copia de ese proyecto, nombrarlo como V2 e introducir todas las nuevas características. Y de igual manera, si Bob le pidiera a algunos de ahí que agreguen aún más características, va a hacer una copia de la última versión de su proyecto, nombrelo como V3 por ejemplo. Y luego hacer todos los cambios necesarios, así sucesivamente y así sucesivamente. Por lo que cada vez que introduce una nueva característica o introduce un enorme pedazo de código, simplemente va a copiar la carpeta o el proyecto y hacer los cambios necesarios. Esta vez. De nuevo, asumamos el mismo caso donde Bob se quejaba de que Washington antes no está funcionando como se esperaba, y que deseaba volver a Washington V3, que estaba funcionando bien tan pronto que no tienen que quitarse el pie revirtiendo todos los cambios. Podría simplemente eliminar la carpeta V4 del servidor y reemplazarla con la versión de trabajo V3 del sitio web be-bops. O si Bob le había insistido para arreglar el error, que en realidad puede comparar los archivos entre v3 y v4 usando un software de comparación como más allá de comparación, por ejemplo, identificar exactamente los cambios que fueron recién introducido, analizar el problema, y solucionar el problema. Si bien esto ha resuelto un poco el problema, repente comenzó a darse cuenta de que esto está ocupando más memoria de la necesaria. Porque remitente no sólo está haciendo una copia de todos los archivos que había modificado, sino también de los archivos que nunca tocó. Entonces esto va a ocupar mucho espacio y se está volviendo realmente difícil para similar manejarlo. Así que de repente se le ocurrió una idea mucho mejor, que en realidad es crear versiones de los archivos dentro del proyecto. ¿A qué me refiero con eso? Entonces supongamos que una vez más tienes un proyecto como este con todos estos archivos. Ahora por supuesto en este caso los nombré como HTML, pero esto podría ser cualquier archivo, este podría ser un archivo de imagen, archivo CSS, archivo JavaScript, archivo java, lo que sea. Por el bien de este ejemplo, supongamos que tenemos todos estos archivos. Ahora, supongamos que el centro está introduciendo una nueva característica que tiene algo que ver con el archivo B y C. Así que en lugar de crear una copia de toda la carpeta que va a hacer una copia de la última versión deestos dos expedientes. Esto va a hacer una copia del archivo B y ver archivo, introducir todo el código requerido para la característica uno. Y si quieres introducir otra característica, y esta vez asumir que los cambios necesita ir y archivar el archivo, ver algo de eso se va a simplemente hacer una copia de las últimas versiones del archivo a y archivo. Ver, por ejemplo, en este caso va a hacer una copia de archivo aquí así como una copia del archivo C, versión uno, que tiene la última versión del archivo C. Y luego va a introducir la nueva característica en él. Una vez puedo suponer que Bob le había pedido a Sunder que eliminara la característica a por completo y que deseamos volver a la versión anterior de su sitio web ambulante. Adivina Watson, solo pueden sacarlo los archivos V2 y solo mantener los archivos V1 tan simples como eso. Y si quieres arreglar el error en su lugar, él solo puede comparar la versión un archivo con Washington a File y señalar exactamente lo que está saliendo mal usando un software de comparación como Beyond Compare. No obstante, Watson empezaron a notar es que ni siquiera esto es factible porque se está volviendo increíblemente complejo gestionar múltiples proyectos de clientes. Por ejemplo, el remitente necesita cambiar el nombre de todos estos archivos a sus nombres originales antes implementarlos en el servidor remoto. Y también ha empezado a notar que sus archivos van en constante aumento, lo que está creando un problema no sólo en cuanto a la organización de los archivos, sino que también está tomando mucho espacio. En este momento desde que comencé a darme cuenta de que es hora de dejar que el software haga el trabajo por él. Un software que administrará versiones como software que rastreará los cambios históricos, creará copias de seguridad, y permitirá la reversión de los cambios, etc. Esta es la razón principal por la que alguien en algún lugar tuvo que venir con el software que hará este trabajo. Y ese es el nacimiento de get. Ahora, get hace mucho más que solo esto. Pero no estoy hablando de ellos en este momento porque en este momento, no sabes qué es la rama de colaboración en equipo de GitHub en la fusión y cosas por el estilo. Voy a conservarlos para próximas conferencias. Y estoy bastante seguro que también debes estar teniendo preguntas como, qué es GitHub o GitLab, qué es ramificación, etc. Bueno, solo tienes que esperar eso. No puedo caber todo bajo solo video, cómo pacientes y ver el resto del curso. Y encontrarás respuestas a todas las preguntas que podrías estar teniendo. Pero la verdad sea dicha. Me gusta lo pronto que el mantenimiento es expresión smiley todo en todo. No importa cómo su vida esté girando a su alrededor. Algo de lo que aprender , ¿no? ¿ Qué acabas de decir? No. No. Sólo digo que tienes un gran sentido de la moda. De acuerdo. 4. 0103 VCS Cómo funciona: Veamos cómo funciona el sistema de control de versiones, o simplemente el software visio a un nivel muy alto. Una vez más, supongamos que tenemos a Sunder, que es desarrolladora freelance, y cylinder tiene una nueva cliente, Linda, que es dueña de un restaurante, y ella quería tener un sitio web para su restaurante. Por lo que para aceptar pedidos en línea de nuestros clientes. Se puede decir con base en su sonrisa que está listo para asumir el proyecto. Pero basado en sus malas experiencias pasadas con algunos de sus otros clientes que ahora han decidido utilizar un software VCS para administrar el versionado. Cylinder en su computadora local, crea una carpeta con el nombre de la app restaurante, pasa unos días e introduce todos los archivos necesarios para crear un sitio web de funcionamiento mínimo. El software de video tendrá su propio data store para almacenar todos los datos históricos y copias de seguridad. Cuando digo Datastore no necesariamente tiene que ser una base de datos relacional o alguna forma de software de base de datos. Puede ser tan simple como el sistema de archivos. Vendemos software es típicamente tienden a utilizar su propio sistema de archivos para almacenar las copias de seguridad y datos históricos. medida que avanzamos por el curso, entenderás mucho mejor este concepto. Pero por ahora, solo asuma que se trata de una especie de almacén de respaldo para almacenar el estado del proyecto. Ahora supongamos que cilindro está bastante contento con los avances que ha logrado en su proyecto. Tiene un sitio web de funcionamiento mínimo y ha probado todo. Todo está funcionando muy bien. Por lo que ha decidido salvar el estado de este proyecto actual. Así que recuperarlo cuando sea necesario. Por lo que va a instruir al software visio que almacene el estado actual del proyecto, típicamente ejecutando un comando. Una vez que ejecuta el comando que vemos software esencialmente haría una copia de todos los archivos y los almacenaría dentro del data store. Ahora asuma que el remitente tiene un nuevo requisito para introducir la característica uno. Y supongamos que todos esos cambios de código necesitarían ir dentro de archivo, archivo bn, ver algunos que ha hecho todos esos cambios. Una vez más, se va a ejecutar el comando para salvar el estado de su trabajo actual. Pero esta vez el visir suave, almacenaremos la información ligeramente diferente en comparación con cómo se almacena antes. Así es como se va a almacenar. Dado que no se introdujeron cambios en el archivo a, el software VCU solo almacenaría la referencia de contaminar una. lo que eso significa es que solo tendrá información sobre la ubicación donde archivan una copia es residiendo. Y la razón de esto es obvia. No queremos hacer innecesariamente una copia de todos los archivos que quedaron intactas o sin modificar y ocupar este espacio. Cuando se trata del archivo B y C, sin embargo, hemos introducido nuevos cambios. Pero el software más fácil no va a hacer una copia de estos archivos. Adr. Lo que se va a almacenar es en realidad la diferencia entre el archivo modificado y la última versión del mismo archivo. Y va a almacenar lo mismo en el Datastore. Llamamos a cada uno de estos tiene un mal set. Esencialmente, un mal conjunto es la diferencia entre el archivo original y la última versión del mismo archivo. Y la razón de eso es una vez más obvia. Queremos ahorrar este espacio tanto como sea posible. Del mismo modo, supongamos que tenemos nueva característica llamada característica a la que se introduce. Y se modificaron el archivo a y el archivo B. Y así es como el software VCS almacenaría los datos. Entonces tenemos conjuntos de PAD para el archivo a y el archivo B. Y luego para el archivo C, sólo vamos a almacenar la referencia de su versión anterior. Y de igual manera asumir que tenemos otra característica. Vamos a hacer modificaciones al archivo B. Y así es como el software VCO, que almacena la información, ahora asumió que cilindro no está contento con la versión para archivo crudo B y que quería volver a la versión tres del archivo B. Así que va a insertar lo mismo al software visir. La visa más suave luego recogería la copia original del archivo B y luego aplicaría todos los parches que vinieron después de ella hasta la versión tres para componer la versión tres archivo B y va a devolver a Domingo. Él puede hacer lo que quiera con él. Un oyente similar también puede escribir el comando instruyendo al software para obtener la torsión completa del proyecto tres, por ejemplo, y el software va a hacer precisamente eso. Ahora, obviamente hay muchos softwares visires disponibles en el mercado. Tenemos buena Mercurial, SVN, etcétera. Y todos difieren ligeramente en cuanto cómo manejaron los datos históricos. Pero en general, así es como manejan los datos históricos. Ahora vamos a sumergirnos en profundidad y entender qué pasa exactamente , qué pasó, ¿por qué? No me importa cómo funcione internamente. De todos modos no me ayuda con mi trabajo. Sólo quiero saber cómo usar el software. Eso tiene sentido. Eso tiene sentido. Tan solo un último video y luego empezaremos a instalar el portón y ensuciarnos las manos con mucha práctica. ¿ Qué tal eso? Gracias. De nada. 5. 0104 DistributedVCS: Hablemos del sistema de control de versiones distribuidas. Linda está bastante contenta con el trabajo realizado domingo y empezó a notar un aumento en los ingresos de nuestro negocio desde que lanzó un sitio web. Y debido al aumento en las demandas de los clientes, ahora ha decidido tener aún más funciones en su sitio web. Ella quiere segundo acercamiento es hacer el trabajo por ella. Pero esta vez, debido a las crecientes demandas de nuestros clientes, ella tiene un plazo muy corto para vigilar. Remitente ha aceptado el trato, pero alguien es bastante consciente del hecho que no puede hacer esto solo y que necesitaba contratar a un par de personas en su equipo, ayudarlo a entregar el proyecto a tiempo. Por lo que Sunder contrató a un par de personas conocen a Asia y Luke, que son los nuevos miembros del equipo. Sender también les ha proporcionado un nuevo MacBook Pro, les ha compartido los archivos del proyecto o el código. O tal vez ha hospedado devolver un servidor FTP, compartido el enlace y pedirles que descarguen. Y también les ha instruido instalar el software en la computadora local, dados todos sus beneficios. Por supuesto, under tiene su propia matrícula local y su propio conjunto de problemas a medida que van avanzando en el proyecto. Desde que empecé a notar pocos problemas con el uso de un sistema de control de versiones local. Algunos de los problemas que están enfrentando son estos no cambios históricos de otros miembros. Por ejemplo, si quiere echar un vistazo a los cambios históricos hechos en el expediente a, ella sólo puede echar un vistazo a los cambios históricos que haya hecho, pero no tiene acceso a datos históricos de otra persona, por ejemplo, cilindro, porque sólo tiene acceso a su propio data store, pero no así en este data store. Ahora bien, esto es claramente un problema. A menos que tenga acceso a toda la historia de cambios, no puede trabajar efectivamente en una tarea. Otro problema es que es difícil mantener la última base de código. Siempre que alguien hace un cambio, necesita dejar que otros desarrolladores sepan que han hecho ese cambio y la necesidad copiar ese código en su máquina local también. Entonces tener la última versión del código en todas las computadoras, esto es por supuesto prácticamente imposible, sobre todo cuando tienes varios miembros del equipo trabajando en una sola base de código. Y las cosas se complicarían aún más si dos personas pasaran a trabajar en el mismo archivo exacto. Otro problema es la falta de administración centralizada de roles o control de acceso. Por ejemplo, supongamos que alguien quiere poner restricción a Luke de que solo puede acceder a conjunto particular de carpetas en el proyecto, pero no a las otras carpetas. Bueno, con el sistema de control local de Washington, no tiene control sobre eso. Sender ha pensado en todos estos problemas a los que enfrentan y ha hecho una investigación en Google. Y finalmente se le ocurrió el llamado sistema centralizado de control de versiones. Simplemente significa que esta vez, en lugar de tener el data store, así como el código en las inscripciones locales están en las máquinas locales. Va a ser en un servidor centralizado. Y todos escogerían el código del servidor centralizado, trabajaban en él, y luego lo enviaban de vuelta al servidor para que otros pudieran usar su código. Y con esto, podemos deshacernos de todos los problemas que tuvimos con sistema de control de versiones local. Una vez más, si esa quiere echar un vistazo a todos los datos históricos de determinado archivo, obtendrá fácilmente acceso a él. Porque esta vez, todos los conjuntos de paths se mantienen en un servidor centralizado y todos los desarrolladores tendrían acceso a él. Y con sólo un simple comando, todo el mundo sería capaz de obtener el nuevo código más reciente y pueden empezar a trabajar encima de él. Entonces para evitar conflictos. Y Cinder también puede tener un mejor control en cuanto a quién puede acceder a qué. Dado que todo está alojado en un servidor centralizado, ahora puede comenzar a usar el control de acceso basado en roles. Y tendrá control en cuanto a quién puede acceder a qué carpetas del proyecto, etcétera. Sin embargo, los sistemas de control de versiones centralizados vienen con su propio conjunto de problemas. Por ejemplo, ¿y si varios van por un lanzamiento? ¿ O qué pasa si alguien hackea el servidor? ¿ Y si muestra tener problemas de conexión? A lo mejor su Wi-Fi no está funcionando. En todos estos casos, los desarrolladores no pueden trabajar en el proyecto. También podrían arriesgarse a perder todo el código si no pueden grabar el servidor. Teniendo en cuenta todos estos inconvenientes ofrece sistema centralizado de control de versiones, tuvo que averiguar una alternativa. Y así se encontró con un sistema de control de versiones distribuido. Es básicamente lo mejor tanto de los mundos de VCS local como de VCS centralizado, eliminando todos sus inconvenientes. Esta vez con sistema centralizado de control de versiones. En lugar de tener un solo depositario como servidor centralizado. Aquí, cada durable tendrá su propio servidor y cada uno de los desarrolladores tendrá una copia de todo el historial o versiones del código en su propia máquina local. Lo que eso significa es incluso si el servidor qué ir para una tarea, cada uno tiene su propia copia local de todo el código así como los datos históricos. Y si alguien como Asia, qué perder conectividad, tal vez por una conexión Wi-Fi, todavía puede progresar porque está teniendo todo en su computadora local. Ella puede hacer cambios. Y siempre que la conexión vuelva a la normalidad, ella puede entregar el código al servidor centralizado para que otros desarrolladores puedan obtenerlos y hacer algo con él. O en caso de una pérdida de datos, cada dólar más tener una copia de seguridad de toda la base de código. Por lo que pueden recordar de algunos de los ejemplos de sistemas de control centralizado de versiones o subversión CVS o simplemente SVN Perlice, o algunos de los ejemplos de sistemas de control de versiones centralizados. Algunos de los ejemplos de sistemas de control de versiones distribuidas son Mercurial, Bazaar y Git. Git es un sistema de control de versiones distribuido. Todos los desarrolladores tendrían que instalar Git en la máquina local. Además de eso, también tenemos GitHub, que actúa como un servidor centralizado. Creo que hemos ganado suficiente conocimiento para empezar a trabajar con Git. 6. 0105 InstallingGit: De acuerdo, veamos cómo podemos descargar, instalar y configurar, subirnos a nuestra inscripción local. Ahora asuma que soy freelancer y tengo un proyecto muy pequeño el cual siento que puedo caminar solo. Olvídate de la colaboración en equipo, olvídate de múltiples personas involucradas en el proyecto. Olvídate de GitHub por el momento. Vamos a mantenernos enfocados en conseguir. Así que ve a Google y busca descarga, consigue en el primer enlace, pero se asegura de que pertenece a la página web. Obtener guión SCM. Ese es el sitio oficial de get. Una vez que estés allí, dependiendo del sistema operativo que estés usando, haz clic en el enlace correspondiente. Ahora para cuando estés viendo esta página, posible que veas un diseño diferente. Pero ya entendiste el punto. Sólo tienes que dar clic en el enlace que es específico de tu sistema operativo. Estoyusando Windows. En mi caso, si estás usando macOS, hay un conjunto separado de instrucciones para el mismo. Sólo síguelos. Y mientras se instala, se puede dejar todo a los valores predeterminados y proceder con la instalación. Y no es necesario que entiendas todos y cada uno de los pasos mientras se instala. Eso es perfectamente normal. En caso de que tengas algún problema instalando en sets macOS, ponte en contacto con nosotros y te podremos ayudar. Pero como estoy usando Windows, voy a dar clic en esto aquí. Básicamente me dieron un par de opciones. El primero de los cuales es la versión instalador de Git, y el otro es la versión portátil de Git. Si descargo versión portable, puedo empezar a usar Git sin tener que instalarla. Y esto podría ser útil, sobre todo si quiero trabajar en múltiples computadoras y no quiero instalar Git en todas y cada una de las computadoras. Simplemente puedo volcar todos estos archivos en un pen drive o en un pendrive y luego comenzar a usar bien en todas esas computadoras. Pero me voy a ir con instalador. Estoy usando OS de 64 bits, así que voy a dar clic en esto. Bueno, para los usuarios de Linux y Mac, es posible que ya estés teniendo Git instalado. Simplemente puedes verificarlo ejecutando un comando. Te voy a mostrar ese mando dentro de un rato. O tal vez ya estés teniendo esas bibliotecas, así que solo tienes que instalarlas. Puede diferir a las instrucciones de instalación para el mismo. Por lo que tengo esto descargado. Comencemos ahora el proceso de instalación. Si tienes pacientes pasan por toda esta licencia, no tengo tanto de pacientes, acabo de hacer clic en Siguiente. Ahora, mientras instalas Git, podrías encontrarte con ciertos pasos, son ciertos prompts, son ciertas terminologías que no te suena familiar. Está perfectamente bien. Comoregla general, solo recuerda, mantén todo a sus valores predeterminados y procede con la instalación. No es necesario que entiendas todos y cada uno de los pasos de este proceso de instalación. Ya que he trabajado en ello desde hace mucho tiempo. Entiendo lo que aquí se está pidiendo. Pero para ti, no tienes que entenderlo todo. Yo sólo te guiaría por los pasos que siento que serías capaz de entender en base al nivel de conocimiento que has adquirido hasta ahora en este curso. Para que pudiera simplemente dejar todo a los valores por defecto. Pero lo que básicamente nos está pidiendo este prompt es que nos está pidiendo que elijamos los componentes que queremos instalar. Vamos a hablar de Git Bash y vamos. En la próxima conferencia. Simplemente puedes ignorar y mantener el resto de estas cosas a los valores predeterminados. No queremos entrar en demasiados detalles. No es lo que aquí básicamente te está pidiendo que elijas un software para editar archivos dot get. Tengo instalado Notepad Plus Plus en mi computadora, y puedo elegir eso. Y también te recomendaría usar el mismo software. Esde código abierto. No tienes que pagar nada por eso. Descarga Notepad Plus, Plus, es una herramienta increíble. Elija eso y haga clic en Siguiente. Deja esto por defecto porque no sabes qué es una sucursal en este punto en el tiempo. Entonces no tiene sentido para mí explicarte sobre este paso. Entonces vamos a dejar esto por defecto. De acuerdo, en esta pestaña básicamente nos está preguntando si vamos a usar solo Git Bash o también vamos a usar la línea de comandos de windows? Este paso es específico para Windows. Es posible que no estés viendo pasos de instalación similares. esfuerzo de instalar Git en otro sistema operativo como Linux o macOS, es posible que estés viendo un conjunto diferente de instrucciones por completo. Pero como dije, dejen todo a sus predeterminados y terminen la instalación. Pero aquí si elijo esta opción, get en realidad va a agregar una variable de ruta en las variables de inscripción del sistema para que podamos empezar a usar comandos de Git en el procesador de comandos de Windows. Si eliges esta opción. No obstante, no va a hacer eso con una suposición que sólo estaría usando Git Bash. De nuevo, vamos a hablar de Git Bash, ponte gris en la próxima conferencia. A continuación, voy a dejar esto por defecto. Básicamente. Es preguntar si quieren usar el OpenSSH existente o si ya lo tienes instalado alguno. Simplemente puedes señalarlo. Pero vamos a usar el OpenSSH que viene junto liado con bueno. Por cierto, apertura que esencialmente le permitiría conectarse a la máquina remota de una manera segura. Más sobre ello en próximas conferencias seguro. Deja esto por defecto también. Obviamente, no entiendes lo que es combate o este checkout, así que no puedo explicarte nada de esto ahora mismo. Déjalo por defecto. Deja el default. De acuerdo, esto hablando de git pull. Nuevamente, esto es demasiado avanzado para que lo entiendas. Simplemente deja todo a los valores por defecto. Soy británico o puede que no estés entendiendo todos los pasos aquí. Ni siquiera intentes entender que no es necesario. Vamos a explorar todo en las próximas conferencias. Es perfectamente normal. Si no lo entiendes, eso está perfectamente bien. Confía en mí. Hit Siguiente. Habilite el almacenamiento en caché del sistema de archivos. Sí, queremos, eso mejoraría el rendimiento. Podemos desseleccionar esto también y presionar Instalar. Espera un poco. De acuerdo, no quiero leer las notas de la versión. Acabado de la cabeza. De acuerdo, ya lo tenemos instalado en nuestra máquina local. Vamos a verificar. Si efectivamente se instaló. Soy ventana abierta, procesador de comandos de Windows. Y luego teclea en get. Si eres capaz de ver una salida como esta. Eso significa que get se instaló con éxito. Y la razón por la que somos capaces de ejecutar el comando git desde procesador de comandos de Windows es elprocesador de comandos de Windows es porque en algún lugar en medio del proceso de instalación, habíamos pedido llegar a incluir la variable path de obtener en variables de inscripción de Windows. Déjame mostrarte lo que quiero decir. Búsqueda de variables de inscripción. Haga clic en Editar variables de inscripción del sistema. Si vas a camino. Aquí verías camino para conseguir biblioteca. Así que cada vez que ejecutes el comando, algo así simplemente se ejecutará. El sistema operativo Windows en realidad va a echar un vistazo a todas estas partes enumeradas aquí. Y luego se encuentra con esta parte donde tiene el código para hacer algo con el comando GET. Y de ahí que seamos capaces de ver esta salida. Si eliminas esto, no podríamos ejecutar ningún comando de Git desde el procesador de comandos de Windows a menos que vayamos explícitamente a este directorio y hagamos eso. En fin, si todo esto suena confuso, simplemente ignora, confía en mí, lo vas a entender todo en próximas conferencias. 7. 0106 Git CLI vs Git Bash vs Git GUI: Básicamente hay tres formas en las que podemos interactuar con Git. Podemos usar gets CMD o Git Bash o obtener GUI o interfaz gráfica de usuario. Obtiene CMV no es más que el procesador de comandos de Windows que usamos para ejecutar comandos git. De hecho, ya habíamos echado un vistazo a un ejemplo de lo mismo en nuestra conferencia anterior, donde estábamos probando la instalación de conseguir. La otra opción que tenemos es usar Git Bash, que es una herramienta que habíamos instalado junto con Git. Git Bash es similar al procesador de comandos de Windows, excepto que podemos usar comandos estándar de Linux para interactuar con buenos. Esto te será útil, especialmente si vienes del fondo de Linux donde estás acostumbrado a ejecutar comandos de Linux. Y ahora digamos que estás trabajando desde el sistema operativo Windows. No tienes que tomar esa curva de aprendizaje adicional para entender el comando de Windows con el fin de interactuar con Git. Por ejemplo, para enumerar todos los archivos en una carpeta particular dentro de la línea de comandos de Windows, utilice el comando allí. Mientras que en Linux, se usa el comando ls para listar todos los archivos. Si estás usando un Mac o Linux, ambos vienen con shell Unix. No tienes que instalar Git Bash. Git Bash sólo está destinado para el sistema operativo Windows. Si no estás acostumbrado a ninguna de estas herramientas, entonces obviamente siempre es mejor elegir Git Bash sobre buen cmd. Y la razón es que, si estás acostumbrado a Git Bash, también puedes trabajar en el sistema operativo Linux en un punto posterior en el tiempo, si fueras a hacerlo. La tercera opción que tenemos es obtener GUI o interfaz gráfica de usuario. Y como su nombre indica, esta herramienta proporcionará una interfaz gráfica de usuario para interactuar con Git. Ahora, sí tengo que mencionar que get gooey no tiene soporte para todas las características que get tiene para ofrecer. Podemos hacer más con Git Bash o conseguir combate CMD para conseguir gloria. Dicho esto, la buena GUI también tiene su propio papel. Por ejemplo, si desea echar un vistazo al panorama general, o si desea obtener una vista de pájaro de todos los cambios históricos, etcétera. Entonces tal vez te resulte útil usar la consulta get en comparación para obtener ese efectivo. No obstante, en el resto del curso, estaremos usando Git Bash ya que esta es la mejor opción. También podríamos explorar camino get-go en algún momento del curso. Pero nos vamos a centrar principalmente en Git Bash, que también es la opción popular. 8. 0107 comandos básicos de bash: Echemos un vistazo a algunos de los comandos básicos que podemos ejecutar en Git Bash para interactuar con el sistema de archivos de Windows. Ahora bien, si vienes de un fondo Unix o Linux, probablemente conozcas todos estos comandos. Siéntase libre de saltarse el video. No tienes que ver el resto de la conferencia. Y para otros quizás te estés preguntando ¿por qué tenemos estos comandos? Bueno, en Windows, creamos carpetas. Echa un vistazo a lo que hay dentro de él, o elimina carpetas. Hacemos eso gráficamente que Windows nos proporciona. No obstante, si quieres hacer lo mismo desde Git Bash, necesitamos usar estos comandos porque Git Bash no viene con una interfaz gráfica de usuario. Ahora podría estar teniendo otra pregunta. ¿ Por qué necesitamos interactuar con el sistema de archivos usando estos comandos cuando podemos hacer lo mismo en Windows? Bueno, la respuesta es que puedes hacerlo de cualquier manera. Pero si aprendes estos comandos, podría serte útil en el futuro. Por ejemplo, si fuera a trabajar en sistema operativo Linux, no tiene sistema operativo Windows allí. Tienes que interactuar con el sistema de archivos usando estos comandos. Y estos comandos tampoco son difíciles de aprender. En realidad son bastante autoexplicativos. Por ejemplo, tenemos MKDIR stands para make directory. Y como su nombre lo indica, te ayudará a crear un directorio o una carpeta. Y luego tenemos stands de CD para cambiar directorio. Te ayudará a cambiar de un directorio a otro directorio. Y este es el comando que usamos para navegar dentro del sistema de archivos. Y luego tenemos los stands de PWD para directorio de trabajo actual, que solo imprimirá la dieta en la que estamos actualmente mientras trabajamos en Git Bash. Si alguna vez te preguntas en qué directorio estás trabajando, entonces este es el comando a ejecutar. Y luego tenemos Ls stands para lista. Y esto simplemente enumeraría abajo todos los archivos en un directorio en particular. Este comando combinado con el guión de opción a, enumera todos los archivos, incluidos los archivos ocultos. Y luego finalmente, tenemos nuestros soportes M para remover. Y como podrías estar adivinando, esto nos ayudará a eliminar una carpeta o un archivo. Ahora bien, algunos de estos comandos irían con ciertas opciones. exploraremos en un rato. He creado una carpeta de prueba por el bien de esta conferencia. Y aquí es donde vamos a experimentar con todos esos comandos. En primer lugar, lanzemos Git Bash. Puedes lanzar Git Bash ya sea desde el menú Inicio o simplemente puedes simplemente hacer clic derecho y hacer clic en Git Bash aquí, esto lanzaría Git Bash en el directorio actual. Vas a ver una pantalla que se ve algo así. Comencemos creando una nueva carpeta. Por lo que obtiene el comando que necesito usar. Es MKDIR significa directorio make. Y voy a proporcionar el nombre de la carpeta o el directorio que quería crear. Llamémoslo mi app o lo que sea. Por lo que esto ha creado un nuevo directorio con el fin de asegurarse de que efectivamente ha creado un directorio. Vamos a ejecutar el comando ls para enumerar abajo todos los archivos en el directorio actual. Y seguro vemos el directorio que acabamos de crear. También podemos añadir un guión de opción a para enumerar todos los archivos, incluidos los archivos ocultos. Pero por el momento, en este territorio, no tenemos ningún archivo oculto que mostrar. Pero este comando será útil en el futuro, sobre todo cuando queremos explorar el directorio de regalos, que se ha escondido. Ahora vamos a entrar en el directorio de aplicaciones. ¿ Cómo hago eso? Debido a que el comando cd para cambiar el directorio. Y quería mencionar ese directorio, pulsa Enter y actualmente estamos dentro del directorio MyApp. Para asegurarnos de que estamos dentro de este directorio. Ejecutemos el comando PWD para comprobar el directorio de trabajo actual, y esto imprimiría mi directorio de aplicaciones. Ahora vamos al directorio padre de mi app. Entonces, ¿cómo hago eso? Hacemos cd space, dot dot slash. Si quieres ir al directorio de abuelos, entonces solo tienes una barra más de punto punto. Y eso hará el truco. No obstante, solo me gustaría ir al directorio padre. Ahora vamos a hacer ls comando para enumerar abajo todos los archivos. Ahora digamos que quiero borrar esta carpeta, obtiene el comando, es RM, y el nombre de la carpeta. Pero esto no va a eliminar la carpeta. Bueno, no elimina la carpeta porque este usuario no tiene el permiso para hacer eso. O esta carpeta podría estar teniendo archivos en ella. Y nos está pidiendo que primero eliminemos esos archivos. Sólo entonces ¿ nos permitirá eliminar esta carpeta? No obstante, sabemos que esta carpeta no tiene ningún archivo en ella. Entonces tiene que ser la otra razón. Para evitar esto, tenemos que incluir una opción junto con el comando RM, y que es el guión r, f. R significa recursivo y F significa fuerza. Recursivo significaría que estamos diciendo, ¿ no sólo queremos eliminar esta carpeta, sino también todos los archivos que contiene? Y esfuerzo significa fuerza. En otras palabras, queremos forzar la eliminación de la carpeta independientemente de los permisos. Voy a especificar el nombre de la carpeta. Y esta vez sí elimina la carpeta. Si hacemos ls ahora, ya no muestra esa carpeta. Así que tómate de cinco a diez minutos e intenta experimentar y jugar con estos comandos. Básicamente solo intenta crear carpetas, eliminar carpetas, echar un vistazo a lo que hay dentro de las carpetas, etc. 9. 0108 ¿Qué es exactamente Git Commit: Probablemente hayas oído hablar de git commit, pero ¿qué es exactamente? Echemos un vistazo. Imagina que estás jugando un videojuego. Y supongamos que has avanzado lo suficiente en el juego que no quieres arriesgarte a perder. Se guarda el juego en ese punto en tiempo dando un mensaje significativo, se continúa jugando el juego y hacer algún progreso. Y una vez más, tienes ganas de salvar el juego. Y tú sólo empiezas dando un mensaje significativo. Y si algo fuera a salir mal con tu juego, sólo tienes que echar un vistazo a toda la lista de salvados que te hacen y cargar el juego en un punto en particular. Ahora, debes tener en cuenta que el guardar aquí no es en realidad una copia de seguridad. Es algo así como una instantánea. Por ejemplo, no puedes simplemente copiar el archivo guardado y llevarlo a otro sistema donde esté instalado el mismo juego y poder cargar el juego desde ese punto guardado. No es posible. No obstante, si se trata de una copia de seguridad, tomas copia de seguridad de todo el juego por completo. Por ejemplo, si el juego está dentro de una carpeta, simplemente copiarías toda la carpeta, llevarías a otro sistema e iniciarías el juego donde quieras empezar. Guardado aquí es esencialmente como una instantánea, pero no exactamente una copia de seguridad. Analogía similar se puede explicar con los puntos de restauración de Windows. Es posible que estés creando varios puntos de restauración dando un mensaje significativo. Y si algo sale mal con tu sistema, tal vez un virus o algo así, realmente deseo que eso no suceda. Pero si algo así sucede, basta con echar un vistazo a toda la lista fuera restaurada una vez que haya creado, elija uno de ellos y restaure el sistema a su estado anterior. Así como has restaurado puntos para Microsoft o opción de guardar para un juego, tienes git commit. Para tu proyecto. Vas a hacer algún progreso en tu proyecto. Por ejemplo, supongamos que has blogged en la característica uno. Y entonces sientes que has hecho lo suficiente para salvar el proyecto o comprometer el proyecto. Eso lo haces usando el comando git commit. Y luego continúas con el proyecto. Trabajas en otra característica y luego comprometes el proyecto con un mensaje significativo. Y si algo sale mal con tu proyecto, entonces get te permitirá volver al estado anterior del proyecto o revertir un archivo en particular a sus versiones anteriores, etc. Al igual que guardado no es un copia de seguridad en un juego. Git commit no es en realidad tomar una copia de seguridad de todo tu proyecto, sino más bien tomar una instantánea de tu proyecto en esa instancia particular de tiempo. Al igual que en eso has creado un proyecto con todos estos archivos. Y ahora sientes que has hecho lo suficiente para guardar el proyecto o comprometer todos los cambios al repositorio. Ahora no puedes simplemente ir y ejecutar el comando git commit y mencionaste todos los archivos a los que quieres venir. No funciona de esa manera. Desafortunadamente, hay un paso adicional involucrado antes de entrar. Y hay una razón para eso. Por ejemplo, podrías estar teniendo otros archivos en el proyecto que no están destinados a ser comprometidos. No quieres que otros miembros del equipo puedan acceder a estos archivos. Por ejemplo, podría ser tener algunos archivos autogenerados o podría estar teniendo ciertos archivos que están destinados sólo a ser utilizados localmente, pero no deberían estar disponibles para el mundo exterior. Y ahí es donde tenemos un paso adicional donde necesitas dejar que consigan sin motor todos los archivos que querías rastrear. Actualmente, todos estos archivos en tu directorio de trabajo no son rastreados por Git. Es necesario decirle explícitamente cuáles son todos los archivos que quería rastrear. Eso lo puedes hacer con el comando git add. Desea usar este comando git add. Y habias mencionado todos los archivos en este caso, vamos a mencionar por archivo de capa, archivo C y D y ejecutar el comando que esencialmente copiaría todos esos archivos en el área de ensayo. Y es aquí cuando get comenzará a rastrear estos archivos. Una vez que hagas eso, vas a usar el comando git commit para ordenar de cometer todos los cambios a un repositorio local, o a veces denominado como base de datos de objetos. Y este no es el único caso en el que podrías estar necesitando git add git commit. Echemos un vistazo a un caso de uso más. Imagina que tienes un par de características sobre las que caminar. Y simultáneamente trabajaste tanto en las características y asumes que los cambios de característica uno fueron dentro del archivo a y el archivo B. Y la característica dos cambios fueron en el archivo C y D. Ahora queremos que estas dos características sean pasando a diferentes commits, no en un solo comentario. ¿ Cómo hacemos eso? ¿ Si no hay concepto de puesta en escena? Y si fuéramos a usar el comando git commit, eso cometería todos estos cambios, no queremos eso. Entonces con el comando git add, primero agregaremos todos los archivos relacionados con la característica uno. Y luego comprometeremos los cambios con un mensaje significativo, así como se nos da un mensaje significativo mientras guardamos un partido. También vamos a hacer lo mismo en se baja cometa. Ahora, una vez que haya terminado con eso, vamos a agregar el archivo C y D y comprometerse como característica a. A lo largo de un periodo de tiempo. Vamos a mantener todos esos comentarios en nuestro repositorio local. Y de esa manera podremos echar un vistazo a todos los datos históricos, sería capaz de recompensar nuestro proyecto a su estado anterior. O podemos hacer lo que el archivo particular a una versión particular de su historia pasada. O podríamos querer echar un vistazo a la diferencia entre la versión actual del archivo y sus versiones anteriores, así sucesivamente y así sucesivamente. que vamos a explorar todo eso en Seguroque vamos a explorar todo eso enlas próximas conferencias. Y eventualmente vamos a empujar todos estos cambios a un repositorio centralizado como GitHub. Y eso es que todos los demás miembros del equipo podrían acceder a tus cambios y también a todos tus comentarios y datos históricos. No obstante, ese es el tema de otro capítulo. También debo mencionar que cuando empecé a usar Git, me uní a una comunidad GitHub local. Ahora les hizo esta pregunta. ¿ Por qué necesitamos tener un par de pasos para cometer los cambios? ¿ Por qué no podemos simplemente tener un comando que se parece a esto? Vamos a mencionar git commit guión m. y luego vas a dar un mensaje. Y luego vas a enumerar abajo todos los archivos que quieres comprometer que podrían estar correspondiendo a la característica dos, por ejemplo. Bueno, no obtuve ninguna respuesta satisfactoria de ellos. De hecho, si hablas otros sistemas de control de versiones como Mercurial o subversivos, no tienen este paso adicional de agregar los archivos antes de comprometerse. 10. 0109 Inicialización del proyecto y exploración de carpeta de puntos git: Veamos qué significa conseguir inicializado un proyecto. Para entender mejor esto, supongamos que tengo un contrato de freelance, mientras que me pidieron crear una aplicación web para mi cliente. Dentro de mi sistema, he creado esta carpeta con el nombre mi app, dentro de la cual voy a introducir todos los archivos necesarios para crear una aplicación mínima en funcionamiento. Ahora podría crear todos esos archivos usando la nueva opción aquí. Pero en realidad voy a hacerlo usando Git Bash solo para que estés familiarizado con todos esos comandos de Linux. Y los comandos que necesito usar se llaman touch. Y luego voy a especificar el nombre del archivo. Por simplicidad, simplemente voy a llamarlo como un punto TXT. Ahora, obviamente no tiene sentido tener un archivo TXT para escribir el código fuente. Pero no estamos realmente interesados en crear aplicaciones aquí queremos aprender, meternos en, hacer ciertas suposiciones. Del mismo modo, voy a crear dos rod dxdy. Me equivoqué el nombre. Y tres dot dx, dy. Cambiemos el nombre a dos puntos TXT. Entonces tengo todos estos archivos creados. Pero actualmente ninguno de estos archivos en realidad son administrados por Git. Por ejemplo, si yo fuera a ejecutar el comando git commit ahora, va a lanzar un mensaje diciendo que no es un repositorio Git o cualquiera del directorio padre. Por lo que necesitamos hacerle saber que necesita para administrar tu proyecto. Y la forma en que lo dices es mediante el uso un comando git en él significa inicialización. Una vez que conseguimos inicializar el proyecto, esencialmente estamos pidiendo llegar a configurar un escrito, que necesita configurar dentro nuestro proyecto para ahora comenzar a administrar un proyecto. Crearé versiones sobre las que se lo pedimos. Y si te das cuenta, en realidad ha creado una carpeta oculta con el nombre dot get. Aquí es donde tenemos esta zona de puesta en escena de la que hemos hablado antes. Y aquí es donde tenemos la base de datos de objetos que se habló antes. En caso de que no puedas ver esta carpeta, entonces necesitas habilitar la opción para mostrar los archivos y carpetas ocultos. Dentro de Windows, debe ir a la pestaña Ver, hacer clic en Opciones, hacer clic en Cambiar carpeta y opciones de búsqueda. Y una vez más dentro de la pestaña de vista, deberías poder localizar esa opción para habilitar o mostrar los archivos ocultos. Y aquí está. Da clic en esta opción que dice mostrar archivos ocultos, carpetas y unidades. Presiona Aplicar y Ok, y ahora deberías poder encontrar esta carpeta. Echemos un vistazo a lo que hay dentro. Ahora, obviamente, en realidad no vale la pena profundizar y tratar de entender todo lo que hay aquí dentro. Exploraremos algunos de estos en el resto del curso como y cuando nos parezca apropiado. Pero por ahora, sólo te voy a dar una visión general de lo que hay dentro de esta carpeta. Tenemos esta carpeta hooks dentro de la cual tenemos montón de scripts. Estos guiones definirían lo que hay que hacer antes y después de un evento en particular. Por ejemplo, ya estamos al tanto del evento commit. Y luego tenemos el script con el nombre pre-commit. Como su nombre indica, hace algo antes de ejecutar la lógica de commit real. Así que consigue mi ejecutar este script antes de ejecutar la lógica de commit. Entonces podríamos estar teniendo cosas como validar la sintaxis, etcétera. Si realmente tienes curiosidad en cuanto a lo que hay dentro de los scripts, puedes hacer clic derecho y abrirlo con Notepad Plus, Plus. Y sólo tienes que ir a través de todos estos comentarios y tratar de tener una idea de lo que está haciendo. Pero no te recomiendo que lo hagas. No te confundas. Entonces tenemos la carpeta de entrada dentro la cual tenemos este archivo de exclusión. Vamos a abrirlo con Notepad Plus, Plus. Si hay algún archivo en tu proyecto que no quieras considerar, aquí es donde los incluirías. También puedes usar patrones. Por ejemplo, puedes decir star dot log. Y ahora get ignoraría todos los archivos con cualquier nombre, pero tiene la extensión dot log. Sólo un ejemplo. Y por cierto, excluir archivo es algo que es local a una computadora. Y lo que agregues aquí solo es aplicable dentro de tu propio depositante, dentro de tu sistema local. Si quieres tener exclusiones en todos los miembros del equipo, entonces hay una cosa separada para eso llamado gitignore. Hablaremos de ello en próximos capítulos. A continuación, tenemos la carpeta de objetos. Aquí es donde los buenos alimentos almacenan todos los datos históricos o el historial de versiones. Esto es a lo que nos referimos como la base de datos de objetos. Bueno, actualmente esta carpeta no tiene muchos datos. Pero una vez que hagamos pocos comentarios, vas a ver que esta carpeta se llena. Vas a ver que se crean un montón de carpetas. Carpeta de objetos dentro. Tenemos la carpeta ribs, pero eso no habla de ello porque para entender esto, hay que saber qué es un objeto commit, hashing, etcétera. Entonces vamos a saltarlo por ahora. Archivo de conflictos es algo que exploraremos en la próxima conferencia. El archivo de descripción tiene algo que ver con Git web. Y como no sabes conseguir web, no tiene sentido para mí hablar de ello. Ahora mismo. La cabeza tiene algo que ver con la ramificación. Entonces hablaremos de ello. Cuando hablamos de sucursales. Sigamos adelante. Algo que también debo mencionar es que meterse en ella es una operación segura. Es decir que asumamos que he trabajado en mi proyecto por un tiempo y he hecho algunos comentarios y luego asumo accidentalmente que ejecuto el comando una vez más, dentro de nuestro proyecto. Esto no va a hacer ningún daño. Todo quedaría como está, como si no ejecutáramos este comando en absoluto. No obstante, si eliminas esta carpeta, entonces eso te va a causar problemas. Vas a perder todos los datos históricos, todo el historial de versiones, etcétera. Y entonces necesitarías reinicializar el proyecto, pero ejecutando el comando git init y empezar desde cero. O necesitas revisar el proyecto desde el repositorio centralizado, que exploraremos en los próximos capítulos. Pero como regla general, siempre debes recordar no meterte con esta carpeta a menos que sepas lo que estás haciendo. El hecho de que esté oculto por defecto debería decirte que no está destinado a ser utilizado por desarrolladores como tú y yo, sino para ser utilizado por sí mismo. Sin embargo, puede haber instancias en las que es posible que deba traer algunas ediciones o hacer algo dentro de esta carpeta. Por ejemplo, ya hemos hablado del archivo info excluyen, donde es posible que desee agregar algunas exclusiones. Pero por lo demás, en la mayoría de los casos no quieres meterte con esta carpeta. Sólo déjalo para conseguir. 11. 0110 Configuración de credenciales de Git y exploración de configuraciones de sistemas globales locales: De acuerdo, veamos cómo podemos configurar las credenciales de Git e intentar entender su propósito real. Ahora tenemos un proyecto inicializado por get con un montón de archivos. Tratemos ahora de ejecutar el comando git commit y veamos qué pasa. Obtienes 12. Amablemente le pido, por favor dígame quién es usted. Ahora. El agua está pidiendo Local commit cambios para ti, pero ¿quién eres el ****? Y también ha proporcionado instrucciones en cuanto a cómo podemos presentarnos a conseguir es ejecutando este comando. Pero esto no se trata solo de que te presentes para conseguir este propósito realmente real de configurar estas credenciales. Por ejemplo, digamos que uno de los miembros de tu equipo recibió un defecto o un bug asignado a su nombre, diciendo que no lo estamos, la función no está funcionando como se esperaba. En el proceso de analizar el problema, quieren echar un vistazo a todos los cambios históricos en ese archivo. Y luego se topan con un cambio introducido antes, que parece haber causado el problema o parecería haber roto una característica. ¿ Adivina qué? Van a conocer el nombre de la persona y la dirección de correo electrónico de la persona que hizo esos cambios. Se van a contactar con ellos y pedirles que arreglen el bicho. Pero cómo consigue no. Todo esto es cuando configuras estas credenciales adentro, obtienes, cuando haces un commit y empujas todos esos cambios al repositorio centralizado, que va a ser GitHub. También almacenará esta información en cuanto a quién ha hecho qué cambios, e incluye su nombre así como su dirección de correo electrónico. Entonces, si introduce buen código, alguien volverá y te alabará. Son. Si presentas mal código, alguien volverá y te culpará. En la mayoría de los casos siempre es la culpa de todos modos, pero no hay comentarios al respecto. Entonces veamos cómo podemos configurar las credenciales y get ya nos ha proporcionado cómo hacerlo. Entonces usemos ese comando, git, config guión, guión global. Cuando configuramos esta opción global, lo que esto significa es que estas credenciales están disponibles en todos los proyectos, todos los buenos proyectos que creas dentro tu sistema pertenecientes a este usuario en particular. Si usted dijo este dos sistema, por ejemplo, entonces estas credenciales serían un valioso sistema. Es decir, cada usuario en el sistema tendrá todas estas credenciales aplicables. También tenemos una opción más que dice local. Eso significa que estos convictos sólo están disponibles para el repositorio actual en el que estás trabajando. Entonces primero intentemos con local. A lo mejor voy a poner primero el nombre. Puedes establecer cualquier nombre de tu elección, pero tiene que ser tu nombre. Y voy a golpear Enter. Y voy a configurar correo electrónico también. De acuerdo, ahora echemos un vistazo a dónde están realmente pobladas estas. Entonces eso está dentro de la carpeta. Recuerda que no antes conferencia, mencioné que hablaremos de este archivo de configuración. Bueno, aquí es donde se pondrían todas esas credenciales. Ahora intentemos establecer estas credenciales a nivel global. Esta vez, esto no se rellenaría en el directorio Usuarios dentro de tu C Drive. Déjame jalar eso hacia arriba. Por lo que dentro del directorio del usuario, deberías poder localizar la configuración de Git. Y esto se reflejaría por allá. Y de manera similar, si tuvieras que establecer las credenciales de todo el sistema, puedes hacerlo. No espero que tu computadora sea utilizada por múltiples personas y todas están contribuyendo a tu trabajo. Pero de todos modos, vamos a configurar esto para el sistema es que aunque se necesita tener permiso. Para que eso no lance get desde el menú de inicio como administrador. Y luego podremos establecer las credenciales, obtener config. Lo siento, El supuesto de ser sistema cambia el nombre de usuario. Voy a decir que esto ha caminado y estos quedarían reflejados dentro de los archivos del programa. Deja que te lleve allí. Dentro de Archivos de Programa, obtenga el directorio ETC. Vas a ver el archivo de configuración de Git. Y aquí es donde se rellenarían las credenciales. Por cierto, también debo mencionar que las credenciales locales anularán las credenciales globales. Y las credenciales globales anularán las credenciales de nivel de sistema. Entonces consigue, trataremos de obtener las credenciales locales rápido. Si no están disponibles. Tratará de buscar las credenciales globales. De lo contrario, la última opción serían las credenciales de este sistema. Si ninguno de estos está establecido, entonces obviamente van a ver un error. También puedes echar un vistazo a las credenciales ejecutando un comando git config list. En algún lugar de aquí, vas a ver el nombre y el correo electrónico como celular. También puedes dar una opción para ver un nivel particular de credenciales, digamos locales por ejemplo. Y también puedes ser más específico sobre qué información dentro de Config. Quieres echarle un vistazo, va a echar un vistazo al nombre de usuario por ejemplo. Y va a imprimir el valor de la misma. 12. 0111 Staging y estado de verificación y verificación: Veamos cómo podemos escenificar archivos inestables dentro del repositorio Git. Y como he mencionado antes, necesitamos preparar expedientes antes de que planeemos comprometerlos. Por lo que actualmente tenemos tres archivos dentro de nuestro directorio de trabajo. Planeemos comprometerlos. Déjame ampliar la ventana para que tengas una mejor vista. Además, déjame teclear el comando clear para borrar la pantalla para que obtengamos una vista fresca. Voy a hacer una ls para listar todos los archivos. Y actualmente tenemos tres expedientes. Si intenté hacer git commit, ahora, nos va a quejar diciendo que tenemos archivos sin seguimiento dentro de nuestro proyecto. Necesitamos tener al menos un expediente. Tract van a tener al menos un archivo en zona de ensayo para poder comprometerse. Y de eso se está quejando. Ahora, ¿cómo guardamos estos archivos? Obtiene el mando, Bueno, bueno ya nos ha dado una pista. Es bueno en. Entonces hagámosle git add. Y podría simplemente enumerar abajo todos los archivos que quería comprometer. Por ejemplo, un espacio TXT punto para puntear TXT, así sucesivamente y así sucesivamente. Esto sería útil si desea seleccionar dos en cuanto a qué archivos desea que venga como parte de una característica en particular. No obstante, en este caso, me gustaría comprometerme todo. Así que podría usar un estilo de carácter comodín. También puedo usar un patrón. Por ejemplo, puedo decir star dot TXT, y esto escenificaría todos los archivos con cualquier nombre que tenga extensión punto TXT. Entonces vamos a ejecutar este comando. Esto es lo que necesitamos. Por lo que esto ahora ha puesto en escena todos nuestros archivos en el área de puesta en escena. ¿ Cómo nos aseguramos de que haya escenificado todos nuestros archivos? Bueno, hay un comando para comprobar para ver el estado que git status. comando de estado de Git nos mostrará una lista de archivos sin seguimiento, lista de archivos que se están rastreando, archivos que se modifican, etcétera. Este comando te será útil para comprobar el estado de nuestro proyecto a medida que avanzamos en este curso, entenderás más sobre este comando. Por lo que después de ejecutar este comando, nuestros archivos se listan bajo cambios para ser comprometidos. Y también ha convertido el color de estos archivos a verde, lo que representa que estos archivos ahora están siendo rastreados o estos archivos están en zona de puesta en escena en este momento. Lo que dice en caso anterior donde todos estos archivos se listan bajo archivos sin seguimiento y están marcados en rojo. Ahora, supongamos que quería eliminar uno de estos archivos del área de puesta en escena, tal vez porque accidentalmente lo he agregado tal vez porque accidentalmente lo he agregadoaquí. ¿Cómo hacemos eso? Bueno, Dios ya nos ha dado una pista cuanto al comando que necesitamos ejecutar al escenario un archivo que es get RM con opción de guión, guión en caché. Siempre que digo que los cacheados están indexados o escenificados, todos queremos decir lo mismo. Tengan eso en cuenta. Así que consigue RM guión, guión en caché. Y voy a enumerar en los archivos que quería subir al escenario. Si quiero en el escenario todos los archivos, podría usar un carácter comodín como ese. Y esto quedaría en el escenario todos los expedientes. Déjame hacer eso. Por lo que esto tiene unstated todos nuestros archivos para asegurarse de que tiene en el escenario todos nuestros archivos. Usemos el comando git status. Y como se puede ver ahí de nuevo a la sección de archivos sin seguimiento y ahí una vez más marcado en rojo. Vamos a volver a agregarlos de nuevo. Permítanme esta vez crear en el escenario un solo archivo, tal vez dos puntos TXT. Es necesario asegurarse de que utiliza esta opción en caché. Si no usas esta opción, entonces este comando tendrá un significado diferente, cual hablaremos en próximas conferencias. Esto tiene en escena dos puntos TXT. Háganoslo saber, comprobar para ver el estado de nuestro proyecto. Y como puedes ver, dos puntos TXT ahora aparece bajo archivos sin seguimiento. Pero como los otros dos archivos se listan bajo cambios para convertirse en él. Así que tómate un momento e intenta experimentar con estos comandos para poner en escena archivos inestables y comprobar estos datos simultáneamente. No comprometas los cambios por el momento. Vamos a hablar de ello en la próxima conferencia. Pero no lo dudes ni tengas miedo de experimentar con todos estos comandos podrías estar sintiendo estos comentarios son bastante simples y directos en este punto en el tiempo. Pero a medida que avanzamos en este curso y medida que introduzco cada vez más comandos git, comenzarás a sentir que son muy confusos. Por lo que la única arma que tienes para evitar ese confuso estado de ánimo. Su práctica, no puedo enfatizar lo importante que es practicar todos estos comandos, lo contrario, pronto te confundirás. Nos vemos en el próximo. 13. 0112 Comprender el compromiso con múltiples usecases: Veamos cómo podemos comprometer nuestros cambios en el repositorio Git. Por cierto, cuando digo repositorio Git, podría referirme a nuestra carpeta de proyecto con la carpeta dot git. O también podría referirme al almacén de datos de objetos del que hemos hablado antes. Depende del contexto. Para evitar la confusión, voy a llamar a nuestro directorio de trabajo son nuestra carpeta de proyecto como repositorio Git. Voy a referirme a la base de datos de objetos como la base de datos de objetos solo para evitar confusiones. Por lo que actualmente tenemos todos estos archivos en su lugar. Asegurémonos de que todos estos archivos estén escenificados. Voy a hacer git status. Tenemos un archivo que no está escenificado. Entonces hagamos git, agrega dos puntos TXT para escenificarlo. Hagamos el estado git una vez más. Y tenemos todos nuestros expedientes en escena. Voy a decir git commit guión m. y luego vamos a proporcionar un mensaje significativo. ¿ Por qué necesitamos proporcionar este mensaje? Bueno, básicamente describe los cambios que le estás comprometiendo a ello más adelante en el tiempo, si tú o alguien más de tu equipo, qué echar un vistazo a todos los cambios históricos o compromiso histórico. Ellos también llegan a conocer qué comité mirando su mensaje. Por ejemplo, podrías estar cometiendo cambios para corregir un error o agregar una función. Como buena práctica. En aplicaciones en tiempo real, seguimos un formato específico para este mensaje. El primero va a ser combinación de caracteres alfanuméricos, que es esencialmente un defecto o un ID de función que elijas de tu herramienta de seguimiento de defectos. Si estás trabajando para una organización, entonces podrías estar teniendo una herramienta de rastreo de defectos o características. Recoges esa identificación y la ingresas por aquí. Por ejemplo, podría ser algo así como WI, algunos códigos numéricos. W es sinónimo de artículo de trabajo. Podría ser otra cosa para ti. Y luego vas a producir mensaje descriptivo. E incluso este mensaje, ¿escogeríamos del título del defecto de la herramienta de seguimiento de defectos? Voy a decir mi app de trabajo o lo que sea. Vamos a golpear Enter. Y todos los cambios que se escenificaron ahora estarían comprometidos. Y para asegurarnos que tenemos todos los archivos comprometidos, hagamos el estado git. Y no muestra nada, lo que significa que no tenemos ningún archivo para volvernos adictos. Ahora sigamos adelante y hagamos una modificación en uno de los archivos existentes en nuestro directorio de trabajo. Para eso, voy a usar el comando echo solo para llenar uno los archivos con un texto. Mi texto en el archivo uno por ejemplo. Y voy a volcar este mensaje dentro de un archivo txt de punto. Este comando equivale a abrir el archivo TXT de un punto e ingresar el texto, mi texto en el archivo uno. Déjamegolpear Enter. Ahora voy a usar el comando cat para ver lo que hay dentro del gesto TXT de un punto te mostré que tenemos este mensaje allá e imprime el texto dentro de OneNote dxdy. Todo bien. Ahora este es un cambio que hemos introducido, lo que significa que necesitamos escenificar esto para comprometerlo. Entonces vamos a hacer git status una vez más. Esta vez va a decir que tenemos un archivo el cual está modificado. Por lo que necesitamos hacer git add para agregar este archivo y llevarlo al área de puesta en escena. Estado de Git. Se pone verde, lo que significa que está listo para comprometerse. Voy a usar una vez más el comando commit. Comete los cambios. Quitemos la identificación del defecto por el momento. Permítanme simplemente dar un mensaje significativo. Archivo modificado, uno, por ejemplo, pulsa Enter, get status. Y claro, tenemos nuestros cambios comprometidos. Ahora consideremos un caso de borrar un archivo. Entonces para eso voy a usar el comando RPM significa quitar. Y luego voy a especificar el nombre del archivo. Vamos a sacarlo a punto txt, postura diferente. Ahora este comando no es específico para obtener, este es un comando típico de Unix. Pulse Enter. Haré ls para ver si se borró y efectivamente se borró. Ahora este es un nuevo cambio que se introduce en el proyecto. ¿ Adivina qué? Tenemos que escenificarlo y luego hacerles saber que hemos eliminado el archivo. Y así se refleja en la base de datos de objetos también. Entonces git status va a mostrar que el archivo ha sido eliminado, pero este cambio no está por etapas. Por lo que git añadir punto dxdy. Buen estado. Y tenemos cambios que están listos para ser editados. Una vez más, git commit con un mensaje significativo. Esta vez, déjame no entrar ningún mensaje y presionar Enter y ver qué pasa. Bueno, abriría editor de texto que habíamos elegido mientras instalábamos Git. En mi caso, tiene Notepad Plus Plus para ti podría ser otra cosa. Aquí, necesitamos ingresar el mensaje que de otra manera entraríamos con opción de guión m cuando decir que archivo eliminado. Para guardar el archivo y simplemente cerrarlo. Y ha comprometido nuestros cambios. Usamos el comando RM con el mood, el archivo. Y luego habíamos hecho git add command para escenificar esos cambios. No obstante, podemos hacer estos dos pasos en un solo objetivo es mediante el uso del comando salir de este momento en lugar de solo RM, estoy diciendo obtener RM. Esto no sólo eliminará el archivo, sino que también escenificaremos esos cambios en el área de puesta en escena. Vamos a eliminar tres puntos dx, dy por ejemplo. Yo haré ls. Y como se puede ver, archivo se eliminó. Pero si hago git status, a diferencia de en el caso del comando RM, esta vez los cambios ya están escena y puedes comprometer directamente los cambios. Git commit, guión ellos. Se eliminaron tres archivos. Ahora echemos un vistazo a toda la lista de commits que hemos realizado ejecutando el comando git log master. Master es el nombre de la sucursal y también es la rama predeterminada. Vamos a hablar de sucursales en un momento posterior en el tiempo. Pero por ahora, solo ejecuta ciegamente este comando para ver toda la lista de commits que has hecho. El más reciente se mostraría en la parte superior. Como se puede ver. Tenemos nuestro primer commit, pero mi mensaje de app de trabajo. Y después modificamos el archivo uno, borramos los archivos para ser eliminados. Tres expediente. También puedo ver al autor que ha hecho eso. Es mezquino en este caso para ti. Sería lo que hayas introducido mientras configuras las credenciales. Cuando tengamos un repositorio centralizado y cuando tengamos un equipo trabajando en un proyecto, podrás ver toda la lista de commits realizados por varios miembros del equipo. Y si tuvieras que detectar un commit que está causando problemas o que podría estar rompiendo una característica. Puedes hacerte con el autor escribiéndoles un correo electrónico. 14. 0201 sha1 algoritmo de hash: Olvidémoslo por un segundo y tratemos de entender qué es el algoritmo hashing de Chavan. El algoritmo hash siobhan, o a veces referido como función hash, tomaría cualquier cantidad arbitraria de datos como entrada. Y nos va a dar un HashCode de 40 caracteres tiene una salida. El tamaño de la entrada no importa. Podría ser tan pequeño como un byte, o podría ser tan grande como un GB o incluso un TB. Pero la salida resultante siempre va a ser un código hash de 40 caracteres. Incluso si la entrada es solo un solo alfabeto, todavía vas a ver un HashCode de 40 caracteres como salida. Estas son algunas de las características de la función hash. misma entrada resultaría en el mismo HashCode, no importa cuántas veces ejecute, puede proporcionar la misma entrada que va a resultar en exactamente el mismo HashCode. No se pueden generar datos a partir de un código hash dado. Aunque es posible convertir datos a un código hash, no es posible de la otra manera. Es decir, si te doy un HashCode, no puede generar datos a partir de él. Es realmente difícil encontrar otra entrada que resulte en el mismo HashCode, pero no es imposible. Podrías tener otra entrada que podría resultar en exactamente el mismo HashCode. Pero la probabilidad de encontrarlo para que ni siquiera tengas que preocuparte por ello. Aquí hay otro caso de uso donde HashCode podría usarse siempre que usemos los registros de su sitio web ingresando el nombre de usuario, contraseña y otros detalles. En lugar de almacenar la contraseña y dibujar el formato de texto dentro de la base de datos, vamos a almacenar el código hash de esa contraseña para que el siguiente término usuario intente iniciar sesión. Vamos a volver a ejecutar el algoritmo hash en la contraseña que ingresan. Y luego vamos a ver si la salida resultante coincidiría con la de la base de datos. Si ambos coinciden, el usuario sería autenticado y se le otorgaría acceso. El beneficio de almacenar código hash en lugar de almacenar la contraseña sin procesar en formato textual es que si un hacker hackea su sistema, obtiene acceso a códigos hash, pero no a las contraseñas reales. No pueden hacer nada usando el HashCode. Por ejemplo, no pueden iniciar sesión usando el HashCode en nombre de un usuario. Todo el algoritmo hash se usa como medida de seguridad. Se llega a utilizar un set para un propósito diferente. Y es identificar de manera única diversos objetos y obtener. Y vamos a hablar de ello en la próxima conferencia. Ahora intentemos generar código hash desde Git Bash usando los comandos git. El comando a ejecutar es buen objeto hash, pero antes de eso, usemos el comando echo con algún texto. Voy a usar el carácter pipe y luego decir get hash object entrada estándar. Al usar el carácter pipe estamos diciendo lo que sea que sea la salida de este comando sería la entrada de este comando. Esencialmente, estamos tratando de obtener el hashCode de este texto en particular. Vamos a darle a Enter. Obtuvimos un HashCode para ese texto. Y no importa cuántas veces ejecute el mismo comando, vamos a ver exactamente el mismo hashCode. Pero si hago incluso un pequeño cambio, el código hash resultante sería completamente diferente de lo que acabamos de ver. Por ejemplo, digamos que acabo de agregar un carácter y golpear Enter. Verás que estos dos códigos hash difieren significativamente. Vas a entender más sobre HashCode, conferencias entrantes. 15. 0202 Git Internals (todo sobre la base de datos de objetos) Parte 1: Con el fin de explicar mejor cómo buenos gestores y almacena los datos dentro de la base de datos objeto. He borrado todo dentro de nuestro proyecto. Entonces toda nuestra historia pasada de compromiso, todos los cambios que hemos introducido ahora se han ido para siempre. Lo que tenemos aquí es esencialmente un directorio completamente nuevo. Y ahora voy a lanzar Git Bash aquí y crear un montón de archivos y directorios. Quiero crear un par de archivos en esta carpeta. Entonces voy a usar el comando touch one dot dx dy y dx dy. Esto ha creado un par de archivos. Además de esto, también voy a introducir un subdirectorio dentro de nuestro proyecto. Da la orden de crear un directorio completamente nuevo. Es MKDIR significa directorio make. Lo voy a nombrar como activos. Entonces tenemos activos que se recrean. Vamos adentro y creemos montón de archivos ahí también. Voy a crear, quiero usar el comando touch one subdata dxdy, substance o sub directory, solo para nuestro entendimiento. Y dos sub dot archivo TXT. Pongamos también algún contenido en este archivo. Volvamos al directorio padre, que es nuestro directorio raíz del proyecto. Voy a usar el comando echo. Archivo uno de próxima generación. Vamos a poblarlo dentro de un archivo TXT de un punto. Y de igual manera, vamos a poblar algún texto dentro del otro archivo, stool, dxdy. Un sub, esto va a ir dentro de un sub dot dx dy, que está dentro del subdirectorio assets. Entonces aquí está nuestra estructura de directorios. Tenemos directorio de activos y un par de archivos dentro del directorio raíz del proyecto. Y dentro de activos que son verdaderos. Tenemos estos dos expedientes. Actualmente no se inicializa esta carpeta. Entonces hagamos precisamente eso. Entra en él para conseguir inicializar este proyecto. Y git agrega todos los archivos. Estado de Git para ver el estado. Y como pueden ver, todo está escenificado. Ahora cometamos los cambios. Git commit. Mi primer comentario. Estodebería funcionar. En la próxima conferencia, vamos a entender los diferentes tipos de objetos que tenemos en Git y cómo se almacenan todos estos archivos dentro de la base de datos get object. Te veré en la siguiente. 16. 0202 Git Internals (todo sobre la base de datos de objetos) Parte 2: Hablemos de lo bueno que en realidad almacena los datos dentro de la base de datos de objetos. En nuestra conferencia anterior, habíamos creado un proyecto con montón de archivos y nos comprometimos esos cambios. Y aquí está la estructura del proyecto que teníamos. Tenemos la carpeta my app, que es el directorio raíz del proyecto. Dentro de la cual tenemos un punto te lleva a puntear TXT y también un subdirectorio llamado assets. Dentro del directorio de activos, tenemos un sub dot dx dy y dx dy. Ahora echemos un vistazo a cómo estos archivos se almacenan realmente dentro la base de datos para lo cual necesitamos entender varios tipos de objetos que consiguen tiene. Primero tenemos el objeto Blob para todos y cada uno de los archivos únicos a los que acudes. Hay un objeto blob creado dentro de la base de datos. Cada uno de los objetos blob almacenaría el contenido de su archivo correspondiente. Por ejemplo, podríamos tener un objeto Blob creado para un punto dxdy con todo su contenido. Cada uno de los objetos blob también tendrá un hash único. Y como habrás adivinado, este hash se generaría usando el algoritmo hash de Siobhan. Y la entrada de ese algoritmo sería el contenido del archivo. En realidad no es usar el algoritmo de Siobhan para asegurar la aplicación o algo así. Lo está utilizando para crear un identificador único para sus objetos. Y el contenido que se almacene dentro del blob no estará en formato legible por humanos. Se almacenará en formato comprimido. Así conseguiría poder almacenarlo, gestionarlo y recuperarlo de manera eficiente . Sin embargo, get también ofrece ciertos comandos usando los cuales sería capaz leer el contenido dentro del blob. Eso lo vamos a explorar en próximas conferencias. Ahora bien, como hay cuatro archivos que habíamos comprometido anteriormente, van a haber para blobs creados dentro la base de datos junto con sus correspondientes contenidos de esos archivos. A continuación tenemos tres objeto. Objeto árbol correspondería a todos y cada uno de los directores del proyecto, incluyendo el directorio raíz del proyecto. Y al igual que con el objeto Blob, objeto de árbol también va a tener una caché única para identificar de manera única un objeto de árbol en particular. Además de eso, tendrá referencias son esencialmente mantendrá los códigos hash de otros objetos blob o tres objetos o combinación de ambos. Por ejemplo, tenemos un par de carpetas dentro de nuestro proyecto. Y así todos van a ser par de tres objetos creados para cada uno de estos directorios. Por lo que tendremos un objeto de árbol creado para el directorio de activos. Y dentro de ese objeto sostendrá las referencias son hashCode de sus archivos. En este caso, este objeto de árbol mantendría el HashCode OPT sub un punto TXT y sometido o TXT. Esencialmente estos son los hashes de los blobs que corresponde a sub un punto T se extiende hasta el punto TXT. Y luego vamos a tener otro objeto de árbol creado para el directorio del proyecto padre. Y va a tener HashCode fuera de sus propios archivos. Además de eso, también llevará a cabo el hashCode del subárbol, que corresponde al directorio assets. Y por supuesto, cada uno de estos tres objetos tendría su código hash único para identificarlos de manera única para que puedan ser referidos desde algunos otros objetos. A continuación, tenemos el objeto commit. Una vez más, este tendrá su propio hash único. Y este hash se generará en base a la información de commit, como el nombre del autor, dirección de correo electrónico, el mensaje que se ingresó, la hora en que ha ocurrido el commit, etc. y commit mantendría la referencia o hashCode del árbol padre. Además de eso, también tendrá información sobre el nombre del autor, dirección de correo electrónico, el mensaje que se mecanografió mientras se cometía, etc. Y a excepción del primer combate, el commit objeto también llevará a cabo una referencia o hashCode del comentario anterior. Conocerás la importancia de ello en las próximas conferencias. Por los cambios que acabamos de cometer. Es así como almacenaría la información en la base de datos. Entonces tenemos tres objetos que corresponden a todos y cada uno de los directores del proyecto. Y luego también tenemos objetos Blob que corresponde a todos y cada uno de los archivos dentro del proyecto. Ahora no es necesariamente que si tienes diez archivos creados dentro de tu proyecto, tendríamos diez blobs creados dentro de la base de datos de objetos. No necesariamente tiene que ser así. Por ejemplo, si tienes dos archivos que tienen exactamente el mismo contenido, y ambos generarían exactamente el mismo HashCode, por ejemplo. Entonces get no creará dos objetos blob diferentes para eso, solo creará un objeto blob y se referirá a él en su lugar. En fin, más sobre ello en próximas conferencias. 17. Visualización y lectura de objetos Git de interiores y objetos: Teóricamente hemos entendido lo bien que realmente maneja y almacena los datos dentro de la base de datos de objetos. Ahora echémosle un vistazo prácticamente para poder explicar mejor las cosas. También te voy a mostrar una representación gráfica de lo que estamos haciendo ahora mismo en el lado derecho de la pantalla para que tengas una mejor imagen de lo que estamos haciendo. Por lo que actualmente solo tenemos un commit. Echémosle un vistazo. Entonces hago git log para echar un vistazo a toda la lista de commits. Actualmente solo tenemos uno. Y como pueden ver, tenemos información del autor, fecha, e incluso el mensaje de commit. Además de eso, también tenemos código hash de 140 caracteres. ¿ Se puede adivinar de qué se trata este código hash? Bueno, aquí está el hashCode del objeto commit correspondiente a este commit. Ahora, ¿cómo echamos un vistazo al contenido dentro de este objeto cometa? Bueno, este HashCode en sí dará una pista de cómo podemos navegar a este objeto commit. Déjame mostrarte lo que quiero decir. Estoy dentro del directorio de proyectos. Déjame agrandarlo para ti. Voy a ir dentro de la carpeta dot git. Y adivina en qué carpeta necesitamos meternos. Esa es carpeta de objetos. Ahora aquí tenemos montón de carpetas que no existían antes de que nos comprometiéramos los cambios. Ahora si miras el hashCode y sacas los dos primeros caracteres, dice 95. Tenemos que ir dentro de esa carpeta. Y luego se ve un archivo con el nombre, que es esencialmente los caracteres restantes del HashCode. Entonces tenemos 95 ECE, así sucesivamente. 95 es el nombre del directorio y el resto de caracteres es el nombre del archivo. Y esto es a lo que nos referimos como el objeto commit. Si intentas echar un vistazo al contenido dentro de él usando un Bloc de notas Plus, Plus, no podrás leerlo porque lo almacenará en un formato diferente que no es legible por nosotros. La única forma en que puedes leer el contenido que contiene es ejecutando el comando get kept file. Y luego vas a proporcionar la opción guión P significa bonita impresión. Y va a proporcionar el hashCode del objeto que desea imprimir bastante. Podría copiar todo el código hash, o podría simplemente copiar los primeros caracteres y pegar aquí. Y esto imprimiría a Watson dentro del objeto cometa. Si deseas echar un vistazo al tipo del objeto, la opción para eso es el guión d para imprimir el tipo. Y esto ha llegado a objetar. Vamos a imprimir bonito ese objeto una vez más. Entonces aquí, como he mencionado anteriormente, tiene información sobre la computadora del autor e incluso el mensaje de commit. Además de eso, también tenemos un HashCode, que en realidad es el hashCode del objeto árbol padre. Entonces echemos un vistazo a lo que hay dentro del objeto árbol. Y voy a usar el mismo comando para imprimir bastante lo que hay dentro del objeto árbol. Sólo puedo copiar primeros caracteres. Pégalo aquí. Y si le pegas a Enter, vas a ver qué hay dentro de él. Ya que tenemos que volver al directorio raíz, tenemos un subdirectorio y un par de archivos. Y si se echa un vistazo a lo que hay dentro de este objeto de árbol, tienes un par de blobs. Cada blob correspondería a archivo individual. En este caso es un punto dx dy y dx dy. Y entonces también está apuntando a otro árbol, o está teniendo HashCode apagado y otro árbol o el subárbol. Para que podamos ir al interior del sub árbol también. Hagamos eso. Obtiene la salida. Van a ser los blobs de los dos archivos dentro de la subcarpeta. Un sub punto toma en sub punto TXT. Y por cierto, puedes ubicar estos objetos dentro de la carpeta de objetos. Así como habías localizado el objeto commit. No es diferente. Ya que soy la carpeta de objetos. Encontrarás una carpeta. Entonces este es el objeto sub árbol del que estábamos hablando. Y de manera similar, también puedes encontrar los objetos blob. Por ejemplo, hablemos de este blob. Empieza con 99, así que vamos a ir dentro de ese directorio. Y este es un objeto Blob. Tratemos de imprimir bastante este objeto blob y deberíamos poder ver el contenido dentro de él. Y una vez más, si lo abrieras con Notepad Plus, Plus o algo así, no podrías leer. Y se ve el texto que hay dentro de este archivo. Así es como esencialmente obtenemos almacena los datos dentro de la base de datos de objetos. Y la comprensión de esto es muy importante para que entiendas cómo los temas que vamos a discutir y los próximos capítulos. 18. 0205 Cómo se comportan los objetos de Blob: Hablemos de los objetos Blob y cómo se gestionan dentro del repositorio Git. Imagina que he creado un proyecto completamente nuevo con el siguiente archivo, un punto TXT, y tiene el siguiente texto en él. Hola de conseguir. Ahora en el momento en que agrego este archivo a esta área de puesta en escena, get realmente intentará generar un código hash a partir del contenido de un archivo TXT de un punto. Y get entonces comprobará para ver si ya tenemos algún objeto en la base de datos de objetos que corresponda a este código hash. Si no hay ninguno, entonces seguiría adelante y crearía un objeto Blob con todo el contenido de un archivo txt de punto, por supuesto, n formato comprimido. Ahora supongamos que he creado un archivo más, digamos dos puntos TXT, con el mismo texto exacto que al áspero un punto TXT hola de conseguir, una vez más, asuma que he agregado este archivo en el área de puesta en escena. Getwidth. Una vez más, intenta generar HashCode a partir del contenido del archivo TXT de dos puntos. Y esta vez get, notaremos que ya tenemos un objeto que corresponde a este hashCode. Entonces get no creará otro objeto blob. El motivo de esto es bastante obvio. ¿ Por qué querríamos crear exactamente el mismo objeto blob cuando ya tenemos uno? ¿ Por qué no usamos simplemente la existente? Tiene sentido ¿verdad? Ahora echemos un vistazo a todo esto en la práctica. Por el bien de este ejemplo y evitar cualquier tipo de conclusión. He creado una nueva carpeta con el nombre Pestaña Pruebas. Y aquí es donde vamos a experimentar y ver qué puede hacer get blobs por nosotros. Entonces déjame lanzarme y ser golpeado en esta carpeta. Primero lo primero, vamos a conseguir inicializa el proyecto. Y déjame seguir adelante y crear un archivo con algún contenido en él. Yo uso el comando echo. Voy a volcar este mensaje dentro de un archivo txt de punto. Este comando no sólo creará un módulo de archivo TXT de punto tambiénlo poblará un módulo de archivo TXT de punto también con este contenido Hola de conseguir. Ahora entremos al directorio de objetos y veamos cómo se comporta. Déjame indicar este archivo, un punto txt, git add one dot dx dy. Y en el momento en que hago eso, vemos una nueva carpeta creándose dentro de los objetos directamente. ¿ Adivina qué es este archivo? Bueno, este es el objeto Blob para un archivo TXT de un punto que acabamos de crear. Entonces sí, los blobs se crean cuando nueva etapa el archivo no es necesariamente cuando se comprometen los cambios. Cuando cometes los cambios creará el objeto cometa así como los tres objetos que corresponden a manojo de blobs. De hecho, ese es el propósito de cometer operación. Es crear una instantánea, guardó el proyecto en esa instancia particular de tiempo. Vamos a hablar de instantánea en la próxima conferencia. Volvamos. Ahora veamos qué pasaría si creara otro archivo con exactamente el mismo contenido. En cuanto a ese TXT a menudo punto, voy a usar el mismo comando. Pero esta vez voy a poblar el mismo mensaje en archivo punto TXT. Escenemos ese expediente. Haré git status. Y tenemos estos dos archivos escenificados. Pero si te das cuenta, no hay nuevo objeto creado para dos puntos TXT. Y ya te he explicado el motivo de eso. Como ya tenemos un objeto Blob con el mismo contenido exacto, get no entra en crear otro objeto. En otras palabras, el momento en que agregamos el extra bajo el área de puesta en escena, se intenta generar el hashCode de este contenido. Y tiene chequeo para ver si tenemos algún objeto existente en la base de datos que corresponda a ese hashCode. Para dos puntos TXT, sí tenemos blob existente y por lo tanto no creó otro bloque. mismo principio es aplicable aunque se tuviera que modificar un archivo. Por ejemplo, digamos que quería modificar el texto dentro para rock dxdy de archivo a por ejemplo, vamos a reemplazar el texto dentro para punto archivo TXT. Vamos a escenificar este expediente. Ahora, ¿puedes hacer una conjetura si vamos a ver una nueva carpeta creándose dentro de la carpeta de objetos, la respuesta es sí, claro. Tenemos un nuevo objeto blob creado porque este contenido aquí mismo es único y no hay ningún objeto blob existente para esto. Vamos a crear también un archivo más, archivo TXT de tres puntos con el mismo contenido que a ese menudo punto TXT. Y vamos escaleras ese archivo git status. Y tenemos estos tres expedientes por cometer. Un punto dx dy y dx dy, o tener exactamente el mismo contenido mientras haces ruta dxdy está teniendo una textura diferente. Ahora, cometamos los cambios. Bueno, esto no son ofertas, sino lo que sea. Vamos a darle a Enter. Y como pueden ver, tenemos tanto commit como el objeto tree creado también, justo después de entrar en los cambios. Ahora echemos un vistazo a lo que hay dentro del objeto árbol. Obtendré log para hacerme el hashCode del objeto commit. Elemento del archivo cat de Git B. Comprobemos lo que hay dentro de este objeto de árbol. Entonces tanto un punto dx, dy, así como tres puntos TXT, deberían estar apuntando al mismo objeto blob exacto. Si observa que tanto una entrada TXT de un punto dxdy están apuntando al mismo objeto blob exacto. Mientras que para dos puntos TXT, es un objeto Blob diferente. 19. 0206 colección de basura y archivos de paquetes: Ahora podrías estar teniendo una pregunta. Cada vez que añadimos un archivo o modificamos un archivo y lo llevamos al área de puesta en escena, vamos a ver que el objeto blob se crea dentro de la base de datos de objetos. Y get ni siquiera los borrará. Aunque tuvieras que inestables los archivos del área de puesta en escena. Es eficiente hacerlo o está ocupando demasiado espacio? La respuesta es, no es del todo eficiente por supuesto. Pero bueno tiene este concepto de recolección de basura, que sucede periódicamente o cuando ejecutas ciertos comandos, como get pull por ejemplo, vamos a hablar de git pull, git push comandos, capítulos entrantes seguro. Pero hay ciertos comandos que también activarán la recolección de basura. El concepto de recolección de basura es algo similar al de recolección de basura en otros lenguajes de programación. Por ejemplo, tenemos recolección de basura en lenguaje de programación Java donde todos los objetos no referenciados serían destruidos. Y igual que el caso con Git. No es un 100% eficiente seguro, pero también tiene mecanismo para administrar eficientemente los objetos. De hecho, podemos ejecutar la recolección de basura manualmente. Vamos a conseguir GC. Y si se nota cómo los objetos que existían antes ya no existen. Ahora bien, ¿esto significa que todo ha ido para siempre? La respuesta es no. Todavíatenemos todo eso. Por ejemplo, si ejecutas este comando, todavía vamos a ver como esa información objeto e incluso puedes leer el contenido dentro de este objeto blob. Ahora, ¿cómo es posible esto? No tenemos esas carpetas de objetos, pero aún así pudimos leer esos objetos. Bueno, está dentro de este Directorio trasero. Esencialmente, esa operación de recolección de basura ha comprimido aún más todos esos objetos en un solo archivo de paquete. También tenemos idx, nuestro archivo índice. Y esto dirá qué objeto se encuentra en qué archivo posterior. Actualmente, como todo el proyecto es muy pequeño, solo tenemos un archivo de un solo paquete. Pero a medida que cada vez tenemos más archivos introducidos en un proyecto, vas a ver nuevos archivos de paquete que se introducen. Un índice entraría en escena en ese momento. Pero en fin, esto no es algo lo que realmente tengamos que preocuparnos. También puedes verificar Watson dentro del archivo PAC. Déjame lanzar Git Bash en esta carpeta. Y el comando a usar es get, verifica back, guión v. Y luego voy a especificar el nombre del archivo empacado, y esto imprimiría todos los objetos que contiene. Algo que también debo mencionar es que la tecnología es adictiva. Si queremos aprender todo. cielo es el límite en cuanto a cuán profundo podemos ir y entender todos y cada uno de los conceptos. Pero, ¿vale la pena? Esa es la pregunta. En realidad no quieres aprender todo ahí fuera. Eso simplemente no vale la pena. Porque ya tenemos muchas cosas que cubrir y conseguir es sólo el punto de partida y tu viaje de DevOps. Para mí como instructor, necesito saber e investigar sobre todo. Qué bien tiene que ofrecer para que pueda filtrar lo que se necesita y lo que no se necesita para ti. De hecho, dudo siquiera en hablar de estos conceptos, pero sentí que la comprensión de esto es muy importante para entender todos los conceptos futuros que vamos a hablar de capítulos entrantes. Pero por lo demás, dudo en hablar todos estos conceptos que no juegan ningún papel en tu Gettier. Eso lo puedo hacer si quiero. Yo sólo puedo enseñarte cosas sólo para demostrar que tengo conocimiento sobre eso. Pero eso no tiene sentido para ti ni para mí. Mi trabajo es hacer tu trabajo fácil, no complicar tu trabajo. Y preferiría e intentar mi mejor esfuerzo para enseñarte sólo las cosas que son absolutamente necesarias para tu trabajo. Tienes que tener eso en cuenta y no intentes aprender todo. Ese es uno de los mayores aprendizajes que tuve en mi carrera. Yo sólo traté de aprender todo. De hecho, la tecnología es muy adictiva. Cuanto más exploras, más quieres saber más y no vale la pena. Es algo así como un entretenimiento en sí mismo, una manera extraña tal vez, pero es para mí. Tengo que llevarme ese dolor no a ti. 20. 0207 Git Snapshot Lo que significa hacer una instantánea: Vamos a tratar de entender lo que es una buena instantánea. Antes habíamos creado un proyecto donde teníamos par de archivos en el directorio raíz del proyecto. Y luego también tenemos sub directorio dentro del cual tenemos un par de archivos más. Si pudieras recordar de nuestras conferencias anteriores. Esta era la estructura de objetos que teníamos cuando hicimos nuestro primer commit. Permítanme simplificar este diagrama para que se vea más compacto. Ahora supongamos que he introducido otro archivo, c3 dot dxdy con el siguiente texto hola de conseguir. Y guardé esto dentro del directorio raíz del proyecto, se queda este archivo. Y luego cometí los cambios. Ahora se puede visualizar cómo sería la estructura de los objetos? Para el segundo commit que hacemos? ¿ Te imaginas algo como esto? Por lo que tenemos un nuevo blob creado para el archivo recién introducido. Además de eso, ¿esperas llegar a crear Blobs para todos y cada uno de los archivos del proyecto? La respuesta es, por supuesto que no. En su lugar, git creará un blog para el nuevo archivo. Y el objeto de árbol raíz del nuevo commit contendrá el hash de ese nuevo blob. Y para todos los demás archivos, ya que permanecieron como están y no se modifican, git simplemente se referirá a sus blobs existentes y a tres objetos. En esencia, el contenido del objeto árbol y la segunda columna, sería exactamente igual el condensador del objeto árbol en nuestro primer commit, excepto que habrá una entrada adicional para el archivo recién introducido. Además de eso, se comprometen objeto también llevará a cabo la diferencia o el hashCode del commit anterior o su padre vienen en. Conocerás la importancia de esto en capítulos posteriores. Entonces, ¿qué es esta instantánea aquí? Bueno, esencialmente cada vez que haces un commit, estás tomando una instantánea del estado del índice o del área de puesta en escena en el momento en que realizas el commit. Esencialmente captura cómo se veía cada archivo en el momento en que haces el commit. Si fueras a retroceder en tiempo a uno de los commit anteriores, git tendrá la capacidad de restaurar todos los archivos tu directorio de trabajo a lo que eran cuando hiciste el comentario. ¿ Cómo es eso posible? Es por la instantánea. Ahora veamos todo esto en la práctica. Estoy dentro de nuestra buena vieja carpeta de mi app. Déjame seguir adelante y crear un nuevo archivo. Entonces tenemos tres dot dx, dy con algún texto en él. Git add git commit. Segundo commit. Por último, estamos haciendo un segundo comentario. Ahora sigamos adelante y exploremos el commit y los tres objetos. Haré git log para echar un vistazo a toda la lista de commits. Y por cierto, hablando del combate padre, cuando ejecutamos este comando git log, ha mostrado los detalles sobre nuestro reciente commit. Y entonces este objeto de comentario está teniendo los detalles de su commit padre, que es este. Y así git procederá y mostrará sus detalles también. Para este commit sin embargo, dado que este es el primer commit que hicimos, no tiene ningún commit padre. Y así este comando dejará de ejecutarse. De todos modos, entenderás más sobre los commits de los padres y los próximos capítulos. Así que sigamos adelante y exploremos lo que hay de adentro hacia afuera. Comprometimiento reciente. Get kept file, guión P. Y como puedes ver, tenemos el hashCode del objeto de árbol raíz. Además de eso, también tenemos el hashCode del commit padre, que es este. Y luego la información del autor, etcétera. A ver qué hay dentro de este archivo. Entonces aquí están los contenidos del objeto árbol. Comparémoslo con el objeto árbol de nuestra primera conexión. Si notas, el hashCode del objeto sub tree es exactamente el mismo. Hashcode de un punto dx dy y dx dy son exactamente iguales excepto para el recién introducido para archivar tres dot dx dy. Entonces eso explica. 21. 0208 Viajes en tiempo con Git: Veamos cómo podemos llegar los viajes en el tiempo. Es decir, te lo voy a demostrar en un rato. Digamos que caminas por la característica uno y cometes todos esos cambios como parte de tu primer commit. Y supongamos que todos esos cambios fueron dentro de un punto TXT. Y entonces su cliente dice que necesitaba otra característica en su aplicación. Por lo que quieres tomar y trabajar en él, hacer otro commit, y asumir que todos esos cambios fueron dentro de punto archivo TXT. Una vez más, a tu cliente se le ocurre una idea creativa. Necesitaba una función más en su aplicación. Y una vez más, trabajas en esa característica, haces otro commit. Y luego digamos que has introducido tres puntos TXT donde tienes todos esos cuentan con tres cambios. Ahora digamos que por alguna razón el cliente ha decidido no tener la función tres por la razón que sea. Y que quería volver a la versión anterior de esta aplicación. Entonces, ¿cómo revierte todos los tres cambios de característica? Bueno, en este ejemplo, es bastante fácil. Simplemente borras el archivo TXT de tres puntos y luego haces otro commit. Sin embargo, como comentamos en uno de nuestros capítulos anteriores, desviar cambios no es un trabajo fácil porque en aplicaciones del mundo real, posible que tengas cambios dispersos en múltiples archivos. Y es realmente difícil revertir todos esos cambios sin estropear las cosas. Es posible que termines rompiendo características que están funcionando antes. Afortunadamente con get sería capaz de volver a copia de trabajo anterior de nuestro proyecto. Ahora también debo mencionar que cualquiera que sea el enfoque del que voy a hablar para ir a la versión anterior del proyecto no es en realidad el enfoque recomendado. El enfoque recomendado es usar ramas, las que hablaremos en el próximo capítulo. Y en el siguiente capítulo, también entenderás por qué este no es el enfoque recomendado para desviar tus cambios. Pero por ahora, echemos un vistazo a esto en acción. 22. 0209 Time Travel en práctica: De acuerdo, veamos cómo podemos viajar en el tiempo y llegar con un ejemplo rápido. Y una vez más, para evitar confusiones, acabo de limpiar todo dentro la carpeta del escritorio y vamos a hacer todo desde cero. Déjame lanzar y Git Bash. Mi plan es hacer tres commits. Y suponemos que cada comentario correspondería a rasgos individuales. Obtener inicializado el proyecto. Toca un punto TXT, git add. Nos vamos a quedar como ese archivo, git commit. Y llamémoslo como sea. Vamos a repetir el proceso para que la característica agregue también. Llamémoslo dos puntos TXT. Git agrega dos puntos TXT y git commit. Característica dos. Hagamos un último commit que representa la característica tres. Y git commit contó con tres. Ahora hagamos git log para echar un vistazo a toda la lista de objetos. Déjame agrandar esta carpeta para que simultáneamente podamos echar un vistazo a lo que está pasando aquí mientras ejecutamos los comandos. Por lo que actualmente tenemos estos tres expedientes. Ahora, supongamos que quería recompensar y volver a una de las versiones anteriores del proyecto. Digamos que quería volver a cómo se veía mi proyecto. Yo hice característica para venir a. El comando que necesito usar es en realidad switch. Ahora, toma nota de que este comando puede no estar funcionando para usted si tiene versiones anteriores de Git instaladas. Por lo que descarga e instala la última versión de Git solo entonces caminará este comando. Si sigues insistiendo en usar versiones anteriores de gaped, entonces hay otro comando llamado git checkout. Necesitas escribir esto. Y si tienes instalada la última versión, como en mi caso, entonces ambos comandos funcionarían sin ningún problema. No obstante, prefiero usar interruptor. Y luego vamos a proporcionar el HashCode del combate al que queremos dedicarnos. Déjame pegar el código. No tienes que pegar todo el código. En realidad bastarían los primeros personajes. Ahora bien, si le doy a Enter, vamos a obtener una pista de get's diciendo, si quieres despegarte, cabeza en el commit, cabeza en el commit, inténtalo de nuevo con opción de desprender. Bueno, lo que sea que estemos haciendo en este momento se llama en realidad estado jefe desapegado. Vas a entender al respecto en el próximo capítulo y conseguir esto también diciendo que se espera una sucursal. Pero se hizo commit. Como dije antes, lo que sea que estemos haciendo en este momento no es en realidad el enfoque recomendado. El enfoque recomendado es en realidad utilizar ramas. Una vez más, hablaremos de ello en el próximo capítulo. Eso es lo que incluso recomienda Git. Se espera que utilicemos rama y no cometa. Vamos a proceder incluyendo la opción de separar guión guión. Y si te das cuenta en el momento en que ejecutamos ese comando, ya no ves archivo TXT de tres puntos. E incluso si fueras a echar un vistazo a toda la lista de commits, haciendo git log. Se va a imprimir sólo dos commits. Esencialmente. Acabamos de retroceder en el tiempo para traer de vuelta al proyecto lo que era cuando hicieron función para comprometerse. Es equivalente a, no he hecho cambios después de que hice característica para venir a. ¿ Qué tan guay es eso? En realidad se puede ir al futuro también. Y no me equivoco al decir eso. Permítanme llegar con el HashCode de la característica tres. Esta vez. Déjame ejecutar git checkout y Strauss, que luego voy a especificar el hash de la tercera commit, nuestro árbol de características commit. Y echa un vistazo a lo que sucedería dentro de nuestro directorio de trabajo. Bueno, ya ves tres dx, dy otra vez, estamos de vuelta al futuro. ¿Qué tan guay es eso? Ojalá haya algo así en nuestras vidas. Es decir, podría simplemente retroceder en el tiempo, arreglar las cosas, tal vez invertir en Bitcoin, y volver al futuro. ¿ Qué tan genial sería? Sólo es posible y consigue, por el momento. Es una locura, pero al mismo tiempo, poco espeluznante para ser honesto, pero ese es el poder del bien. Pero de todos modos, intenta experimentar con esta característica. Sólo juega con él. Y no te molestes por terminologías como cabeza, rama, etcétera. Vamos a hablar de todo eso en el próximo capítulo. Una cosa más que debo mencionar es que cada vez que estamos cambiando o revisando otro commit, Get pudo traer de vuelta el directorio de trabajo a lo que era cuando hicimos ese comentario. Y ha ocurrido muy rápido. El motivo por el que sucede tan rápido es por el concepto de instantánea que habíamos discutido en una de nuestras conferencias anteriores. En otros sistemas de control de versiones. Cuál es la historia en realidad la diferencia de archivos en comparación con sus commits anteriores. Y cuando agregamos la herramienta para devolver el proyecto a cierto estado, en realidad va a resumir todas las diferencias para recrear los archivos a lo que eran cuando hicimos el commit. No obstante, en caso de get, todo se trata de Snapshot. Básicamente, todos y cada uno de los objetos commit apuntan a una instantánea o al objeto de árbol raíz, que tiene toda la información de todos los archivos que residen en nuestro directorio de trabajo y todos sus objetos blob correspondientes. Entonces es relativamente más rápido. Olvídate de recuperar el contenido de los objetos Blob y casi al instante o rápidamente cargar casi al instante o rápidamentetodos los archivos en el directorio de trabajo. Ese es el poder de almacenar una instantánea en comparación con el almacenamiento de las diferencias son conjuntos de almohadillas como discutimos en una de nuestras conferencias anteriores. Es como cuando estás jugando un juego, vas de ida y vuelta entre múltiples puntos de venta. Algo parecido a eso. Espero que tenga sentido. 23. 0301 Vida sin ramas: Veamos cómo existía su vida antes de las ramas git. Y se puede decir por esta imagen que debe ser una experiencia muy frustrante. Imagina que tenemos a Bob que es asesor de inversiones y remitente, que es freelancer. Bob asunder para crear una solicitud para él. Y remitente ha creado una aplicación y Bob está bastante contento con cómo funciona la aplicación. Y ahora Bob ha decidido agregar algunas características más a su aplicación. Y remitente ha aceptado trabajar en esas características. Ahora asuma que remitente ha comenzado a caminar en la característica uno y ha comprometido todos esos cambios y se lo ha mostrado a Bob. Bob está bastante contento con cómo está funcionando la característica uno. Y ha dado señal verde para seguir trabajando en otras características. Por lo que remitente ha seguido trabajando en la función para también. Y envió un correo electrónico a Bob pidiéndole que verificara la función. Pero esta vez Bob está bastante ocupado con estos clientes. Y así no había tenido tiempo de revisar esta característica. No obstante, algunos allí han decidido seguir trabajando en otras características porque si sigue esperando la respuesta de Bob, tal vez no pueda cumplir con la fecha límite del proyecto. Por lo que entregó la función tres y función para también, y ha enviado un correo electrónico a Bob pidiéndole que verifique todas estas características. Bob verificó todas las características. Y por alguna razón Bob no está contento con el largometraje para terminar que ha decidido eliminar por completo esa característica de su aplicación. Entonces cenicilla lo pensó un poco y se dio cuenta de que es realmente difícil deshacer todos esos cambios. Porque si intenta deshacer todos estos cambios, podría terminar rompiendo algunos de los rasgos que andaban caminando. Otra cosa que está en la idea de hacer es volver a una de las versiones anteriores del proyecto ejecutando el comando gets que son git checkout. Pero el problema con eso es que Cinder no solo se librará de la función a los cambios, sino que también se deshará de la función tres y característica para los cambios que están funcionando bien. Y Bob está bastante contento con estas características. Esto es sólo la punta del iceberg en cuanto al tipo de problemas que podríamos enfrentar cuando no usamos ramas. Por ejemplo, en aplicaciones del mundo real, es posible que no seas la única persona que estará trabajando en la aplicación. Podrías tener la base de código y la lista de historiales de commit, decidir sobre un repositorio centralizado y múltiples miembros del equipo y podría ser de varios equipos, estaría contribuyendo a ese proyecto. Todos harían sus propios commits, introduciendo sus propias características. Ahora no podemos arriesgarnos a volver a una de las versiones anteriores y arriesgarnos a perder todo el esfuerzo del equipo. Otro problema que podrías enfrentar sin ramas es cuando quieres trabajar en múltiples entidades simultáneamente. Déjame explicarte lo que quiero decir. Supongamos que está asignado con todas estas características y tiene que terminarlas antes de una fecha límite. Llamémoslos cuentan con F1, F2, F3 y F4. Si bien no se recomienda que realice varias tareas, a veces use situation podría exigirle trabajar en múltiples cosas simultáneamente. Por ejemplo, supongamos que comenzó a trabajar en la característica F e hizo algunos cambios relacionados con F1 dentro de su directorio de trabajo. Y luego hay que escribirle un correo a alguien. Y en base a cuál sea la respuesta, querrías continuar con la característica uno. Mientras esperas la respuesta. No se espera que veas YouTube o algo así. Tu jefe esperaría que asumieras otra tarea. Tal vez empezar a trabajar en función para, por ejemplo, recoger la característica dos y empezar a trabajar en ella. Introducir código relacionado con la característica dos. Y entonces digamos que dependes de alguien más para que también lo haga. Y hay que esperar la respuesta. Por lo que tomas la característica tres también. Mientras administras todas estas funciones, esperas respuestas y actualizas el código en consecuencia. Tu jefe te pediría que enviaras una actualización de la función por ti. Te contaremos que está en progreso a pesar de que no has comenzado en la función por solo para mantenerlos contentos, podrías decirle que está en progreso. Por lo que estás un poco obligado a empezar a trabajar en función por ahora. Y luego de repente se llega a responder por la característica uno. O alguien de tu equipo te pide que entregues función tres porque dependen de ellos. Espero que estés llegando a donde esto lleva. Cuando tengas todos estos cambios parciales de todas las características dentro de tu proyecto. Esto llevaría a mucho lío y mucha frustración. Hablemos de un problema más realista que podrías enfrentar si no usas ramas. Imagina que tienes un repositorio centralizado donde todos los miembros del equipo estarían contribuyendo a la base de código. Y ahí viene esta nueva señora que acaba de unirse al equipo. No tenía experiencia en programación. Acaba de graduarse de la universidad y unirse a la organización. Y se le asignó un largometraje en el que trabajar. Mientras trabaja en el largometraje, sintió que hay demasiados cambios para volver. Por lo que pensó en hacer un commit parcial en la base del código. Por lo que ella comete esos cambios. Y obviamente, como se puede esperar, esto no es una cosa ideal de hacer. Pero ella es nueva en el equipo. Ella no sabe muchas cosas. Sigue aprendiendo e hizo un compromiso parcial. Y el resto de los miembros del equipo comenzarían a tomar esos nuevos cambios porque necesitan obtener el código más reciente para comenzar a trabajar en sus propias características encima del código existente. Y contribuyen al proyecto, introduciendo su propio conjunto de cambios e introduciendo nuevas características o correcciones de errores. Ahora por ese compromiso parcial hecho por esta jovencita, todos los futuros commits podrían en realidad romperse también. O peor aún, en realidad podría romper las cosas maduras, funcionando bien antes. Ahora es comprensible que sea nueva el equipo y esté obligada a cometer errores, pero albergó a todos los miembros mayores del equipo que hicieron un trabajo justo. Pero sin embargo tienen que asumir la culpa porque su código no está funcionando como se esperaba debido a los cambios introducidos por esta jovencita. Ahora esto es sólo una consecuencia del error cometido por un miembro del equipo. ¿ Qué tal si varios miembros del equipo introducen todas esas ideas medio cocinadas en la base principal del código? Pronto se convertirá en una pesadilla. Pronto se volverá difícil de manejar, no poder cumplir con los plazos del proyecto, demasiados problemas para solucionar, etcétera. Entonces supongo que ahora necesito aprender sobre las ramas git. Absolutamente. Entonces, ¿a qué esperas? Cada uno cumple con esas cosas dañadas. De acuerdo. Cilindro fácil. Ese es el plan. Por eso estoy aquí. Yo estoy aquí para enseñarte. Gracias. Gracias. De nada. 24. 0302 Qué son las ramas de Git: De acuerdo, tratemos de hacernos una idea de cuáles son nuestras ramas git. Ahora sí tengo que mencionar que con este video solo, es posible que no puedas entender ni obtener una imagen completa en cuanto a qué son las ramas git. Es necesario ver el resto de las conferencias en este capítulo para tener una imagen completa de lo que nuestras ramas git, cuál es el propósito, por qué existieron, y cómo resuelven todos los problemas habíamos hablado antes. Entonces vamos a seguir adelante y tratar de conseguir como el personal, lo que voy a conseguir ramas. ramas de Git son una característica tan importante en git que incluso el logotipo en sí está teniendo un símbolo que representa obtener ramas. Para que puedas entender el significado de esta característica en git. Ahora quiero hacerte una pregunta. ¿ Qué es lo primero que te viene a la mente cuando escuchas la palabra rama? ¿ Te imaginas algo como esto? Bueno, no te equivocas. Aquí. Si observa tenemos una rama principal y luego también tenemos subsucursales las cuales provienen de la rama principal. Y cada una de estas ramas están teniendo su propio conjunto de hojas. Bueno, esto es sinónimo de lo que las ramas son n obtener también. Entonces n get, podrías tener una rama maestra creada por get al inicializar el proyecto y hacer tu primer commit. No tenemos que crear manualmente esta puerta, ha hecho eso por nosotros. Y todos los comentarios que hemos hecho hasta ahora se fueron dentro de esta rama por defecto, rama maestra, a pesar de que no estamos al tanto de ello. Y entonces también podríamos tener ramas de características que vienen de la rama maestra. Así como tenemos rama principal y sub-sucursales en una rama del mundo real, también tenemos rama maestra y sucursales de características en bueno. Y así como cada una de las ramas tendría su propio conjunto de hojas, incluso en Git, tenemos convectos que residen en cada una de estas ramas. Y todas estas ramas evolucionarían de forma independiente. Por ejemplo, si realiza una commit y presenta una rama, esos cambios no estarán disponibles en ninguna de las otras ramas. Igual que el caso con otras ramas. Si haces un comentario y master branch, entonces esos cambios no estarán disponibles en otras sucursales. Si quieres hacer un commit en una rama determinada, necesitas cambiar a esa rama y hacer un commit en esa rama. Y esos cambios comprometidos no estarán disponibles en otras sucursales. Y cuando cambies a una rama, git hará que el directorio de trabajo se vea como se veía cuando hiciste la última commit en esa rama en particular. Eventualmente, el objetivo de todas estas ramas de características en mayoría de los casos sería fusionarse en la rama maestra. Lo que significa que ahora tendremos todos los cambios introducidos en esta característica ramas dentro de la rama maestra. Ahora, obviamente, esto puede no estar teniendo todo sentido para ustedes en este momento. Así que vamos a descomponerlo y ver cómo este proyecto pudo haber evolucionado desde el principio. Por lo que cuando inicialmente como el proyecto y hacer su primer commit, usted tiene una rama maestra creada por el bien. Y digamos que usted ha hecho un par de comentarios. Estos comentarios irían al interior de la rama maestra. Entonces tenemos el primer commit que no tiene ningún padre. Y luego tienes el segundo commit, que tiene el primer commit como su commit padre. Y ahora digamos que estás asignado para trabajar en la característica uno. En lugar de comprometer todos esos cambios de característica uno dentro de la rama maestra. Lo que vas a hacer es ejecutar un comando para crear una rama de entidad. Y esto solo crearía la rama de características. Y una vez que hagas eso, necesitas cambiar a esa rama para poder hacer commits en esa rama de características. Por lo que ejecutarías un comando para cambiar a esa rama. Y una vez que hagas eso, vas a empezar a introducir toda la característica que uno cambia. Cuando haces el primer comentario. Tenemos un objeto de comentario cuyos padres serían el último commit de la sucursal desde donde creaste esta sucursal. En este caso, es la rama maestra. Por lo que el primer comentario que hiciste dentro de la característica una rama apuntaría ahora a la última commit de la rama maestra. Y luego digamos que has hecho un par de comentarios dentro de la rama de funciones. Ninguno de los cambios que hemos introducido en la característica una rama estaría disponible en la rama maestra. Porque como he mencionado antes, todas estas ramas evolucionarían independientes entre sí. Ahora digamos que has decidido trabajar en otra cosa y querías aportar todos esos cambios dentro de la rama maestra. Por lo que volverías a cambiar a rama maestra y hacer un comentario. Tome nota de que estos dos commits o tener exactamente el mismo padre y cualesquiera que sean los cambios que haya introducido con este nuevo commit dentro la rama maestra no serán disponibles dentro de la rama de características. La característica una rama solo tendría todos los cambios introducidos en rama maestra hasta el momento en que creó la característica en la rama e hizo la primera commit. Además de todos los cambios que has introducido en la característica uno. De acuerdo, Digamos que has hecho un comentario más dentro de la rama maestra. Y es en este punto en el tiempo, digamos que se te pide que trabajes en función para adivinar lo que vas a crear otra rama más, llamémosla característica a rama. Y luego tienes que cambiar a esa rama para poder hacer commits dentro de la característica a rama, vas a hacer un commit. Y esta vez quedaría atrapada dentro de característica para ramificarse. Y este objeto commit estaría apuntando a la última commit arriba de la rama maestra, porque es la rama maestra desde donde hemos creado esta característica a rama. Y todos los commits subsiguientes que vas a hacer serían rastreados dentro de la característica a rama. Ahora, una vez más, es posible que desee volver a la rama maestra y hacer un montón de comentarios y no dimensión característica a rama tendrá cambios que ha introducido en rama maestra hasta la hora en que creó la característica para ramificar e hizo el primer commit. Y todos los comentarios que has introducido en función a rama, pero no tiene ninguno de los cambios que has introducido en ninguna de las otras ramas. Al igual que por ejemplo, cuentan con una rama. Eventualmente quieres fusionar todos los cambios que has introducido en esta característica se ramifica en la rama maestra para que tengas todos los cambios dentro de la rama maestra. Ahora, obviamente, podrías estar teniendo muchas preguntas sobre cómo esto resolvería todos los problemas que habíamos hablado antes. ¿ Y qué es exactamente sucursal? ¿ Cómo funciona internamente? Y cómo se logra a lo que significa cuando cambias a una rama diferente, tú, y encontrar respuestas a todas esas preguntas en próximas conferencias. Y por cierto, he mencionado que hacemos commits dentro de la rama maestra. Normalmente no tendemos a hacer commits directamente dentro de la rama maestra. Siempre creamos una nueva rama, función beta o una corrección de errores. Y luego una vez que estemos seguros de todos los cambios, una vez que los probemos, consigamos revisarlos, solo entonces fusionaremos todos esos cambios dentro de la rama maestra. Entonces, esencialmente, lo que tendría la rama maestra es la llamada commit de fusión. Hablará de merge commits en próximas conferencias. No quiero hablar de ello ahora mismo y confundirte más. Te veré en la siguiente. 25. 0303 Cómo las sucursales solucionaron nuestros problemas: De acuerdo, hasta ahora tenemos alguna idea sobre las sucursales. Ahora echemos un vistazo a cómo las sucursales resuelven los problemas de los que habíamos hablado antes. Hablemos de ellos uno por uno. Imagine que se le pide que trabaje en múltiples funciones simultáneamente. Esta vez, vas a tener múltiples ramas, cada una correspondiente a función individual. Es muy fácil para ti realizar múltiples tareas porque digamos que querías trabajar en la función uno. Simplemente vas a cambiar a esa rama y seguir trabajando en la característica uno. En algún lugar en medio de tu trabajo, es posible que hayas decidido trabajar en otra característica, digamos característica a tal vez porque estás esperando una respuesta por correo electrónico o lo que sea. Entonces, ¿adivina qué? Se fue a cambiar a un largometraje a rama y seguir trabajando en el largometraje dos. Y como los cambios de pelaje introducidos en una rama no tendrán ningún impacto en las otras ramas. No hay posibilidad de que te confundas con los cambios de código introducidos para múltiples funciones. Tenemos contextos separados para todas y cada una de las características. Y evolucionan de manera independiente el uno del otro. Por lo que ramas tiene una especie de resolver el problema de no ser capaz de multitarea entre múltiples características. Ahora supongamos que algún programador inexperto se unió al equipo. ¿ Adivina qué? Ellos sólo pueden crear una rama, experimentar. Todo lo que quisieron experimentar, cometer errores, aprender de esos errores, y traer actualizaciones. Por último, cuando estén listos con los cambios. Y una vez después de la prueba todos esos cambios, los miembros sénior del equipo en realidad pueden revisar todos los cambios de código. Y sólo entonces aceptarán todos esos cambios para fusionarse con la corriente principal del desarrollo. Entonces no hay alcance de que un miembro en el equipo se meta con el código y le cueste el trabajo de otros también. Ahora digamos que querías deshacerte de una de las características, entonces no tienes que tomar su fuerte de deshacer todos los cambios y arriesgarte a crear problemas. O no tienes que volver a uno de los commits anteriores y arriesgarte a perder todo el esfuerzo del equipo que vino después de él. En su lugar, puedes simplemente eliminar la sucursal y levantarla. La característica que no quieres. No tendrá ningún tipo de impacto o influencia en el trabajo ajeno. Otra ventaja con ramas es que puedes hacer commits parciales. Sin ramas que hicimos commits parciales, podría correr el riesgo de introducir nuevos errores en su aplicación están rompiendo algunas de las características de trabajo. No obstante, con las ramas, puedes hacer múltiples commits parciales, especialmente si tu característica es muy grande. Y una vez que termines, simplemente vas a fusionar todos esos cambios en la rama maestra. Espero que tenga sentido. 26. 0304 Cómo funcionan las ramas de Git y lo que es exactamente una rama: De acuerdo, Tratemos de entender cómo funcionarían las ramas. Pero antes de eso, entendamos qué es exactamente una rama. Si yo fuera a definir una rama, una rama sería simplemente una referencia a un commit, o en otras palabras, es sólo un puntero a un commit específico. Ahora tal vez te estés preguntando ¿cómo es que algo tan simple como esto puede hacer tanto por nosotros? Lo hace. Déjame explicarte lo que quiero decir. Vamos a configurar eso. Simplemente inicializa el proyecto usando el comando git init. Y como branch es una referencia a un commit en particular, necesitamos al menos un commit para tener una rama. Y por eso no estás viendo nada en este momento. crearía una rama la primera vez que hacemos un commit. Y esa rama es la rama maestra, que sería creada por el propio Git. No tenemos que hacer eso manualmente. puede pensar en ello como simplemente un archivo con el nombre Master, cuyo contenido va a ser el hashCode de un commit específico. Y una rama siempre apunta al último commit en esa rama. Actualmente solo tenemos un solo commit. Esta rama maestra señalaría ese commit. Ahora digamos que hice un nuevo commit, entonces la rama apuntaría ahora a ese nuevo commit, así sucesivamente y así sucesivamente. Y hacer un nuevo commit y rama señalaría ese nuevo commit. Ahora digamos que tengo que caminar sobre la característica uno. Vamos a ejecutar un comando para crear otra rama. Llamémoslo cuentan con una rama. En el momento en que ejecutes ese comando, git creará una nueva rama, esencialmente un nuevo archivo con la característica de nombre uno, cuyo contenido sería el hashCode de un commit específico. ¿ Cuál sería? ¿ Se puede hacer una conjetura? Bueno, sería el último commit fuera de la rama desde donde hemos creado feature one branch. Por lo que apuntaría a este compromiso. Ahora digamos que he hecho un par de commits más. ¿ A dónde crees que irían esos comentarios a Mel? Entraría en master porque esta es la rama activa actual. Por lo que esos dos comentarios irían al interior de la rama maestra. Y como se puede adivinar, maestro ahora señalaría ese commit muy reciente en esa rama en particular. Ahora digamos que querías hacer algunos comentarios dentro de la rama característica. Bueno, hay que ejecutar un comando para cambiar a esa rama. Y una vez que hagas eso, todos los commits que vas a hacer serán rastreados dentro de la rama de la característica uno. Si hago un commit ahora, ¿cómo crees que se vería el diagrama? Bueno, una sucursal siempre señalaría el último comentario sobre esa rama. Característica. Una rama señalaría ahora este nuevo commit. Y este nuevo commit tendrá la rama maestra commit como su padre. Entonces es en este momento tendremos dos commits teniendo exactamente el mismo padre. Ahora digamos que hice un par de comentarios más. ¿ Dónde crees que se rastrearían esos comentarios? Bueno, ya que el largometraje una rama es el actual actor Branch, esos comentarios estarían yendo dentro del largometraje una rama. Y por supuesto, característica una rama apuntaría ahora a la última commit en esa rama. Ahora bien, mi pregunta para ustedes, imaginen que he añadido un archivo en cada uno de estos comentarios. Ahora bien, si fuera a mirar el directorio de trabajo, ¿cuáles son todos los archivos que van a ver? ¿ Puedes adivinar? Bueno, cada vez que cambies a una rama, git reescribirá el directorio de trabajo para que se vea como se veía cuando hiciste el commit más reciente en esa rama a la que acabas de cambiar. Por lo que en este caso, las actuales ramas de actores cuentan con un lote. Entonces vas a ver todos estos archivos a, B, C, y F, G, H. No vas a ver los archivos D y E. Y ahora si fueras a cambiar a rama maestra, vas a ver archivos a, B, C, D, E , pero no F, G, H Archivos. Espero que tenga sentido. Te veré en la próxima. 27. 0305 Branches in Action (creación de Branches y exploración de la reposición de git): De acuerdo, Vamos a ver ramas en acción con un ejemplo rápido. Una vez más, crearé una nueva carpeta, mi app, y aquí es donde vamos a experimentar todo sobre las ramas. Voy a lanzar Git Bash aquí. Permítanme crear un archivo comprometido en la rama maestra. Y vamos a empezar desde ahí. Voy a que me inicialicen el proyecto. Y luego toca un punto TXT para crear ese archivo. Git agrega un punto TXT para permanecer como ese archivo. Y antes de que cometa los cambios, déjame llevarte a conseguir refs, jefes directorio. Aquí es donde crearía lista a menudo ramas. Déjame volver a Git Bash y déjame comentar este cambio. Git commit guión m. Primer commit en la rama maestra. En el momento en que comete estos cambios, vas a ver un nuevo archivo siendo creado por gaped. Echemos un vistazo a lo que hay dentro de este archivo. Tomar nota del nombre del archivo es el nombre de la rama, la rama por defecto que Dios ha creado para nosotros. Es maestro. Y el hashCode es el hashCode del commit que acabamos de hacer. Si vuelvo a Git Bash y hago git log, el hashCode que ves aquí es exactamente el hashCode que ves dentro del archivo maestro. Entonces, esencialmente, el maestro de rama está apuntando a este cometa en particular en este momento. Hagamos un comentario más y veamos qué va a pasar. Toca archivo TXT de dos puntos, git, agrega dos puntos TXT. Y entonces una vez más, comprometamos el cambio. Llamémoslo segundo commit y rama maestra. Y echemos un vistazo al contenido dentro del archivo maestro. Entonces cat dot consigue cabezas refs y luego el archivo master. Y como se puede ver, Maestro ahora está apuntando al último commit en esta rama actual. Entonces si hago git log, vas a ver que la rama maestra en realidad está apuntando a la muy reciente commit que hemos hecho. Ahora intentemos crear una nueva sucursal. Y el comando para eso es git branch. Y luego vas a especificar el nombre de la sucursal que quieres crear. Llamémoslo característica uno. Entonces esto ha creado característica una rama, pero todavía estamos en rama maestra. Y se puede decir mirando aquí, dice Maestro, por lo que actualmente estamos en rama maestra. Si hago un commit ahorita, que venga no estará disponible. Cuenta con una rama. Pero si te das cuenta, también ha creado otro archivo dentro del directorio heads con la característica de nombre uno y obtiene el contenido dentro de él. Bueno, será el hashCode de la última rama commit off desde donde creamos feature one branch. Entonces, esencialmente, si echas un vistazo al contenido del archivo feature one, va a apuntar a la última commit de la rama maestra. Como se esperaba. Ahora si hago un nuevo commit donde crees que entrarían los cambios, sería dentro de la rama maestra porque ese es el acto actual a sucursal. Entonces déjame hacer un compromiso. Holandés tres puntos dxdy, git añadir tres puntos dxdy. Y vamos a hacer un tercer commit dentro de rama maestra. Si hago ls, van a ver todos esos tres expedientes. Pero si cambio a característica de una rama, por lo que sí consigo interruptor y el nombre de la sucursal a la que quiero cambiar. Característica uno. También puedes usar el comando git checkout y el nombre de la rama head away. Como puedes ver, hemos cambiado a contar con una rama. También puedes contarlo mirando aquí. Ahora bien, ¿puedes adivinar cuáles son todos los archivos van a estar viendo si hago ls? Bueno, sólo deberíamos poder ver un punto dx dy y dx dy. Y no se liberó dxdy porque se crea texto de tres puntos y rama maestra, después de que creamos esta rama característica. Como puedes ver, solo estamos viendo un punto d x en archivos rho TXT, que se espera. Ahora como estamos dentro de la característica una rama, todos los comentarios que voy a hacer ahora estarían atrapados dentro de la característica una rama. Hagamosun comentario. Quiero crear un archivo, toque. Llamémoslo, que son nombres de archivos TXT de 13 puntos como este, solo para que sepamos que esto pertenece a contar con una rama. Por el momento. Git add. Nos vamos a quedar como ese archivo, git commit m, añadiendo característica 13 archivo en el que una rama, lo que sea. Entonces hicimos el comentario si lo hago ls ahora, quieres ver todos estos archivos. Déjame volver. El directorio de trabajo. Vas a ver todos estos archivos. Bueno, echemos un vistazo a lo que pasaría si me cambiara a rama maestra. Entonces uso consigue qué comando. O también podría usar git checkout y luego el nombre de la sucursal. En el momento en que hago eso se puede ver se ha actualizado el directorio de trabajo que se adapta a rama maestra. Por lo que obtener está al tanto de la instantánea de la última rama master de diamantes commit. Y va a hacer que el directorio de trabajo luzca como se veía cuando hicimos el último commit en rama master. Y si tuviera que volver a cambiar a la rama de características, una vez más, vas a ver que el directorio de trabajo se actualiza en consecuencia. No vemos tres puntos, dxdy. Y la rama de características apuntaría ahora al último commit hecho en esa rama. Entonces, si echas un vistazo al contenido de la característica una rama, el HashCode ahora se actualiza, apuntando a la última commit en una rama futura. Si haces git log, verías que ese es el último commit hecho en esa rama. Ahora es realmente crucial que entiendas cómo funciona exactamente esto. Quiero que experimentes con esto. Crea archivos en múltiples ramas, cambia entre múltiples ramas y trata de entender qué tan bien se comporta con las ramas. Si no practicas, es casi seguro que te confundirás muy pronto. Por lo que no dudes en practicar. Sientes que lo estás sabiendo todo, pero cuando realmente practicas, podrías tener sorpresas. Entonces no dudes en experimentar con esto. Tómate un tiempo y practica lo que acabo enseñar y asegúrate que te sientas cómodo con las ramas. 28. 0306 Comprensión de 'HEAD' cabecera independiente en acción: Entendamos lo que está por delante y consigamos. Mi rama es una referencia a un commit, relacionado con la cabeza el punto a una rama o a un commit específico. Cuando la cabeza apunta a un commit específico, se llama estado jefe desapegado. Déjame explicarte lo que quiero decir. Cuando se tiene un proyecto sin otras ramas excepto la rama maestra, por defecto, head señalaría la rama maestra. Ahora suponga que tiene dos ramas, master y cuenta con una rama. Digamos que has cambiado a contar con una rama. El titular señalaría ahora a contar con una rama. Y en base a la cabeza, conocerá a qué rama necesita para comprometer los cambios. Si la cabeza apunta a rama maestra, git hará los comentarios dentro de la rama maestra, o la cabeza apunta a alguna otra rama como característica una rama. Git hará commits dentro de la característica una rama. También puedes tener la cabeza apuntando a un commit específico. Y ya habíamos echado un vistazo a un ejemplo de lo mismo en una de nuestras conferencias anteriores. Por ejemplo, podrías decir git checkout o good switch. Y luego vas a especificar el hashCode de un commit particular a los objetos. El jefe entonces señalaría ese commit y get en particular actualizará el directorio de trabajo del proyecto para que se vea como se veía cuando hiciste ese commit en particular. ¿ Y cuáles son los comentarios que usted hace durante el estado jefe desligado? Todos esos comentarios se perderían una vez que cambiaras de nuevo a una de las sucursales. lo que podría preguntarse por qué nos está permitiendo pagar o cambiar a un commit en particular. Bueno, podría haber casos de uso en los que es posible que desee volver al estado anterior del proyecto. Por ejemplo, digamos que te gustaría echar un vistazo a cómo ve nuestro proyecto cuando hiciste un commit en particular, Digamos que te gustaría recuperar algunos de los cambios que fueron eliminados anteriormente en uno de los comentarios anteriores. Bueno, puedes revisar el commit en particular. Echas un vistazo a todos los cambios, tal vez copias el código que se eliminó, y usas ese código en tu proyecto actual. Una vez después de cambiar de nuevo a la rama u otro caso de uso de estado de cabeza separada sería, digamos que quieres retroceder en tiempo y hacer pocos commits experimentales. Pero no quieres que todos esos commits estén disponibles en tu base de código. Y una vez que termines, simplemente volverías a cambiar a una de las ramas y todos esos commits experimentales se perderían. Ahora echemos un vistazo a todo esto en acción. De acuerdo, Actualmente estamos dentro de la característica una rama. En primer lugar, tratemos de localizar dónde reside realmente la cabeza. Dentro de la carpeta git. Vas a encontrar este archivo con el nombre cabeza. Dado que ahora estamos en función de una rama, la cabeza está apuntando a contar con una rama. A ver qué va a pasar. Si cambiamos a rama maestra. Echemos un vistazo al contenido del archivo head dot get. Y como se puede ver, cabeza ahora está apuntando a rama maestra. Ahora echemos un vistazo a la lista de commits en esta rama maestra, git log. Y como pueden ver, actualmente tenemos tres commits. Y también se puede ver aquí que la cabeza está apuntando a la rama maestra. Si tuvieras que cambiar a contar con una rama, digamos. Y haz git log por ejemplo. Vas a ver que la cabeza está apuntando a contar con una rama. Si quieres echar un vistazo a toda la lista de sucursales disponibles, va a decir git branch. Y luego vas a ver toda la lista de sucursales. Y como la rama actual o la ACT a rama o llamada la rama de cabecera es una característica una rama, se destaca en verde. También vemos una marca estelar que nos da una pista de que esta es la rama real o la rama actual. Entonces si hago git log, se puede ver que actualmente tenemos tres commits. Ya hemos echado un vistazo a cómo podemos revisar o cambiar a uno de los comentarios anteriores en una de nuestras conferencias anteriores. Entonces no voy a hacer eso. En su lugar usaría un comando diferente llamado Git checkout. O también podrías usar buen interruptor. Usemos eso porque es el más reciente. Y entonces vas a decir cabeza todas las gorras. Y entonces vas a usar este símbolo, sea lo que sea. Y luego vas a especificar el número de commits a los que te gustaría volver. Digamos si digo uno aquí, entonces podemos ver el depositario o el directorio de trabajo, cómo se veía uno hace commit. Déjame ejecutar este comando. Y esta vez si hago git log, ok, este comando básicamente no funcionó. Nos está pidiendo que agreguemos esta opción despegamos. Entonces hagámoslo rápidamente. Ahora hagamos git log. Y sólo vas a ver un par de comentarios. Ahora actualmente estamos en estado jefe desapegado. Entonces déjame tratar de hacer un comentario aquí. Toca tal vez Apple dot dx, dy. Y luego git, agrega apple dot TXT. Conseguir venir en, guion ellos. Algún mensaje. No importa. Si hago git log. Sin duda verías ese compromiso. Pero una vez que vuelva a cambiar a una de las ramas, ya no verías este commit. Este commit se perdería. Entonces haré git checkout. O también se podría decir, Good Switch característica uno, git log. Y ya no verías el comentario que acabamos de hacer. 29. 0307 Deshacer los cambios con Git Reset HEAD: De acuerdo, veamos cómo podemos deshacer nuestros cambios son revertir los comentarios que hemos hecho. Con el fin de ahorrarle tiempo. En realidad he creado una carpeta nueva o un proyecto completamente nuevo. Y básicamente tenemos estos tres expedientes. Cada uno de estos archivos fueron comprometidos en sus propios comentarios. Por ejemplo, si hago git log, ves que tenemos tres commits. En el primer comentario, he cometido un archivo TXT de un punto. En el segundo comentario me comprometí a punto archivo TXT y entrar commit. Hemos cometido archivo TXT de tres puntos. Esto es sólo para ahorrar su tiempo. Hemos estado creando proyectos y creando archivos y agregándolos al área de puesta en escena y comprometiendo esos cambios por un tiempo. Espero no tener que acompañarte a través de esto una y otra vez. No tenemos otras sucursales por el momento. Tenemos la rama maestra por defecto. Echemos un vistazo a cómo podemos hacer también cambia nuestro grupo de deshacer de confirmaciones. Y también vamos a hablar de un par de comentarios más que me parecen relevantes para hablar en este momento. Entonces digamos que accidentalmente he cometido estos cambios y quería deshacer esos cambios. Ahora hay tres opciones para mí. Simplemente puedo deshacer este commit, pero mantener los archivos en el directorio de trabajo. Esaes la opción uno. opción dos es que puedo deshacer este commit, mantener los cambios en el directorio de trabajo, y también tener esos archivos en escena. Y luego la tercera opción, deshago este commit así como elimino todos los cambios que se hicieron en este comentario. Entonces déjenme demostrar todos esos escenarios. Y el comando para eso es git reset. Y voy a decir cabeza. ¿ Cuáles son los símbolos? Nosé cuál es el símbolo. Supongo que se llama Tilda. Si no me equivoco espero tener razón. Y luego voy a dar un número aquí. Si especifico dos aquí, me gustaría deshacer a comentarios. Probemos con un commit. Golpeé Enter. Entonces lo que esto ha hecho es que esto ha deshecho el último commit. Pero todavía tenemos los archivos dentro del directorio de trabajo, pero no en área de puesta en escena. Entonces si hago git log ahora, solo vas a ver primero, segundo commit. Pero si hago ls, vas a ver archivo TXT de tres puntos. Porque como he mencionado antes, todavía tenemos los cambios en el directorio de trabajo. Si hago git status ahora, ves que este archivo no está escenificado. Para que podamos introducir todos los cambios que queríamos introducir. Hacer todas las actualizaciones. En cuanto he hecho algunos cambios en el archivo TXT de tres puntos que ahora quería comprometer. Por lo que puedo llamar a esos cambios en cuanto haya hecho esos cambios, voy a git agregar archivo dot txt de nuevo. Y luego reharé el commit git log. Ahora, ya ven que tenemos todos esos tres comentarios. Ahora veamos qué pasaría si ejecutara este comando con opción suave, esto para Lambda, este combate. Pero todavía tenemos los archivos dentro del directorio de trabajo así como en el área de puesta en escena. Ejecuto este comando. Registro de Git. Sólo se ven dos commits. Y si haces ls, vas a ver los tres expedientes. Si haces git status, también verás que esos cambios están en escena. Para que sólo pueda cometer esos cambios. Yo voy a hacer ese comentario. Y la vida vuelve a la normalidad. Ahora digamos que he cometido un terrible error. Y simplemente me gustaría no sólo deshacer esos cambios están bajo el commit, sino que también me gustaría deshacerme de todos los cambios que he hecho en ese comentario. Bueno, la opción para eso es que necesitas usar git reset head tilda, número de comentarios a los que te gustaría volver. Y luego vas a usar duro la opción. Ahora si haces git log, obviamente verías dos commits. Pero si lo haces ahora ls, sólo vas a ver dos expedientes. Es como si nunca hubiera hecho el tercer comentario en absoluto. 30. 0308 Recuperar el misterio perdido con reflog: Ahora supongamos que has cambiado de opinión. Sientes que has deshecho accidentalmente la remontada y te gustaría recuperar todos esos cambios. Bueno, hay una manera para eso. Afortunadamente, get, mantendremos estos objetos commit y su repositorio por un buen periodo de tiempo antes de que decida eliminarlos. Cuando hace la recolección de basura y todo. Entonces echemos un vistazo a si podemos recuperar todos esos cambios. En primer lugar, necesitamos hacernos con el hashCode del commit. Esos cambios quisieran recuperar. Entonces, ¿cómo sabemos el commit ID? En este momento solo podemos desplazarnos hacia arriba y obtener el ID de commit. Pero es posible que no puedas desplazarte hacia arriba cada vez. Por ejemplo, si cierro esta ventana y vuelvo a abrir, se ha ido. Entonces, ¿cómo nos sacan del commit ID? Bueno, get ofrece un comando que nos ayudará a salir por solo que ese comando es log, nuestro log de referencia. Siempre que actualizamos a nuestros amigos en el repositorio local. Pero al ejecutar un comando, los registros de referencia tienen un registro de eso. Y puedes ver todos esos registros ejecutando este comando. Aquí, puedes hacerte con el hashCode de ese commit. Bueno ahora solo podría agregar git checkout e ir a ese commit. Y eso nos llevaría a un estado jefe desapegado. No obstante, puedes simplemente copiar todos esos cambios, traer todos esos cambios y hacer un nuevo commit. Pero tenemos una mejor manera de lidiar con eso. Entonces, en lugar de hacer git checkout y luego especificar el hashCode de ese commit. Lo que vamos a hacer es que voy a especificar la opción guión b, y voy a especificar un nombre. Y este nombre esencialmente va a ser nombre de la rama que estamos a punto de crear. Por ejemplo, digamos nueva rama. Por cierto, para nombres de ramas, nunca usaríamos espacios en blanco. Quisiéramos usar guión en su lugar. Entonces lo que hace este comando es cuando tenemos esta opción guión b, esto no solo creará esta rama en particular, sino que también cambiaremos a esa rama. Y va a apuntar a este comentario. Ejecutemos este comando. Y como pueden ver, hemos cambiado a esa nueva sucursal que acabamos de crear. Y si hago git log ahora, se puede ver que tenemos el tercero y los otros dos comentarios son en realidad de la rama maestra y escalan la rama desde donde creamos esta rama. Pero, ¿cómo conseguimos los tres cambios de commit en nuestra rama maestra? Bueno, eso lo podemos hacer con emerge. No hemos hablado de fusiones. Hablaremos de ello en próximas conferencias. Pero tal vez solo te lo demostraré rápidamente, sólo para darte una idea de lo que es una fusión. Entonces para eso, me gustaría volver a la rama maestra. Voy a usar el comando git, fusionar, especificar la rama que me gustaría fusionar en rama maestra. En este caso es nueva sucursal. Ahora si hago git log dentro de la rama master, vas a ver que tenemos esos nuevos cambios. Lo que acabamos de hacer es llamada fusión de avance rápido. Nuevamente, vamos a hablar de más solo en próximas conferencias. No lo pienses demasiado. Una última cosa que me gustaría mencionar es que cuando revisas los cambios o revisas un commit. Pero si ya has empujado esos cambios al repositorio remoto, entonces va a crear un problema. Ahora como no hemos hablado repositorio centralizado y colaboración en equipo, no voy a hablar de la Seder, pero como regla general, solo recuerda, si quieres deshacer el Commit, hazlo antes de presionar todos esos cambios en el repositorio remoto. 31. 0401 Fast Forward Merge: El objetivo de tener una característica o una rama fija de error es eventualmente fusionar todos esos cambios dentro de la corriente principal de la evolución, que normalmente sería la rama maestra. En este video, hablemos de lo que es la fusión de avance rápido. Imagina que tienes un proyecto con rama maestra y con estos tres comentarios. Y es en este punto en el tiempo, he decidido trabajar en el largometraje uno. Y así he creado una característica una rama y también he hecho un montón de commits en ella. Ahora digamos que no tenemos ningún otro comentario adicional en rama maestra. Una vez después de haber creado la rama característica, Digamos que he terminado con todo el trabajo tengo que hacer dentro de la característica una rama. He probado todos esos cambios. Y ahora quiero tener toda la característica una rama cambia dentro de la rama maestra. O en otras palabras, quiero fusionar característica una rama en la rama maestra. Ahora una pregunta para ustedes, ¿qué puedo hacer aquí para que rama maestra, tendremos todos los cambios de característica una rama. Pausa el video e intenta descifrarlo. Bueno, déjame darte una pista. Voy a reescribir este diagrama de esto a esto. No he hecho nada. Acabo de levantar la característica una rama pero hacia arriba. Pero esto debería darte alguna pista lo que podemos hacer para tener todos los cambios de la característica uno dentro la rama maestra. Daleuna oportunidad. Bueno, te daré otra pista. Estamos llamando a esto una fusión de avance rápido por la razón. ¿ Cuál es la parte de FastForward en eso? Bueno, ¿qué tal si le pedimos a Master que apuntara a la última commit o característica de una rama. ¿ No resolvería el problema? Esencialmente, rama maestra ha pasado remitida a montón de cometas. Rama maestra ahora está apuntando a un commit que tiene una instantánea que apunta a todos los cambios de rama maestra más todos los cambios en la característica una rama. Y ya que terminamos con feature one branch y he fusionado todos esos cambios dentro de la rama maestra. Podemos seguir adelante y eliminar esta rama por completo. Ahora la fusión de avance rápido solo funcionaría si no haces ningún comentario dentro de la rama maestra después de crear la rama de entidades. Ahora, otra pregunta para ustedes. Acabamos de ver cómo podemos fusionar todos los cambios de la característica una rama en rama maestra usando la fusión de avance rápido. Ahora tendría sentido decir que quería fusionar todos los cambios de rama maestra en la rama característica una. No tiene sentido porque característica una rama ya está teniendo todos los commits son todos los cambios de rama maestra. Sin embargo, si has hecho algún comentario en rama maestra después de crear la rama de funciones, esa es una historia completamente diferente. Y vamos a hablar de ello en próximas conferencias. En el siguiente video sin embargo, vamos a echar un vistazo a toda esta inacción. Nos vemos en la siguiente. 32. 0402 Fast Forward se combina en acción: Para explicar Fusionar de avance rápido, he traído el proyecto a este estado. Tenemos la rama maestra con estos tres archivos, ABC, y ahí se entregan en tres commits diferentes. Del mismo modo, tenemos una rama característica con los archivos D, E , F, y todos se entregan en tres comentarios diferentes también. Ahora echemos un vistazo a avance rápido mucha inacción. A la izquierda tenemos el Git Bash. A la derecha, tenemos el directorio de trabajo. Se puede observar simultáneamente lo que está sucediendo en el directorio de trabajo mientras ejecutamos comandos en el Git Bash. Por lo que actualmente estoy en sucursal maestra y así estás viendo archivos ABC. Si tuviera que cambiar a la rama de características, entonces vas a ver que el directorio de trabajo rellenaría con todos los archivos, que incluye cambios de rama maestra así como la rama de características. Ahora echemos un vistazo a cuál compromete esta marca solo apuntando. Voy a hacer git refs, jefe maestro. Y de manera similar, echemos un vistazo a lo que la característica ramifica queriendo. Y si hago git log, se puede ver que la rama de la característica está apuntando a la última commit, pero la rama maestra está apuntando a su último commit en la rama maestra, que sería esta. Ahora no puedo fusionar rama maestra en la rama de entidades porque las ramas de entidades ya tienen todos los cambios de rama maestra, no tiene sentido. Por lo que necesitamos cambiar de nuevo a rama maestra. Y luego obtendrán que queremos traer todos los cambios de la rama de características a la rama maestra. Y una vez que ejecute ese comando, deberíamos poder ver la rama maestra apuntando a este commit. Por lo que obtiene el comando git merge nombre de la rama que quieres fusionar. En este caso es característica de una rama. Y como pueden ver, el resumen muestra que estos son todos los archivos que ahora forman parte de la rama maestra. E incluso el directorio de trabajo se actualiza con todos esos archivos. Si echas un vistazo a qué rama maestra apunta, entonces apunta al commit exacto. Esa rama característica está apuntando. Eso es un avance rápido mucho para ti. Ahora podemos seguir adelante y eliminar la rama de funciones, pero vamos a hablar de ello en la próxima conferencia. Una cosa que me gustaría mencionar es que tal vez no quieras eliminar siempre la sucursal una vez que hayas terminado con ella. A veces es posible que quieras conservarlo por un tiempo porque podría haber instancias en las que podrías necesitar hacer esos cambios de último minuto. O podría haber ciertas correcciones que quieras entregar como parte de la misma sucursal. Por lo que vas a usar la misma rama de características nuevo para hacer todos esos cambios, probarlos, conseguir que se revisen, y luego eventualmente fusionar todos esos cambios en la rama maestra. Y sí, puedes reutilizar la misma rama y puedes fusionar la misma sucursal una y otra vez. Sin embargo, la mayoría de las veces creamos otra rama para correcciones de errores o cualquiera de esos cambios de último minuto y luego fusionamos esos cambios en la rama maestra. Otra cosa que me gustaría mencionar es que normalmente sucede en GitHub en una tapicería centralizada. Ya que no hemos explorado GitHub, no tiene sentido para mí hablar de ello ahora mismo. Pero, sin embargo, la fusión también es el depositario local de Londres en ciertas instancias. Nos vemos el siguiente. 33. 0403 Eliminación de la rama y recuperación: Veamos cómo podemos eliminar una sucursal para poder explicar esto. Nuevamente, trajo el proyecto de vuelta a este estado. Actualmente estoy dentro de la foto una rama. Si traté de eliminar la rama cuando estoy realmente en ella, entonces arrojará un error diciendo que no se puede eliminar una rama jet dot. Déjame tratar de hacer eso. Entonces el comando que necesito usar para eliminar las ramas, git branch. Y luego voy a usar la opción guión D, asegúrate de que sea d minúscula y luego voy a especificar el nombre de la rama. Vamos a ver un error y dice no se puede eliminar característica de sucursal una descatalogada en la carpeta fugaz. Voy a volver a cambiar a rama maestra para poder eliminar característica una rama. Si trato de eliminar ahora, llegar a es en realidad nos va a dar una advertencia de que ninguno de los cambios en la característica de una rama, lo que en realidad la mayoría en cualquier otra rama. Y como se puede ver como diciendo, la característica de rama uno no está completamente fusionada. Pero, ¿cómo sabe que esta rama no está fusionada? Se echará un vistazo a la última commit de feature one branch. Y advierte que no hay otra rama que apunte a ese commit. Get nos da una advertencia. Además de eso, también nos está sugiriendo si aún queremos eliminar esa rama, entonces podemos seguir adelante y hacerlo con la opción de guión d. Esta es D mayúscula en comparación con la D minúscula, que habíamos utilizado anteriormente. Y get en realidad nos ha proporcionado el comando predeterminado. Yo sólo puedo pegarlo por aquí. Y esto eliminaría la sucursal. Y por supuesto perderemos todos los cambios introducidos en la característica una rama. Cuando eliminamos esta rama, git en realidad nos ha proporcionado el hashCode del último commit por si acaso queremos hacer algo con ella. Ahora supongamos que he cometido un error al borrar esta rama y quería recuperarla. ¿ Qué es un comando que me ayude a recuperar esta rama? Una vez más, ya estás familiarizado con eso. Lo habíamos utilizado en una de nuestras conferencias anteriores. Bueno, es git, checkout guión b. y luego vas a especificar un nombre de sucursal. Podemos dar cualquier nombre de nuestra elección. Pero yo voy a hacer el mismo nombre, pizza uno. Entonces vamos a especificar el hashCode del combate al que quieres que apunte esta rama. Esencialmente lo que está haciendo este comando es no solo crear la característica de rama uno, sino que también cambiaremos a esa rama con la última commit siendo esta commit con esta característica HashCode, se crearía una rama, y esa rama estaría apuntando a este commit que acabamos de eliminar. Si ejecutas este comando después de un tiempo muy largo, después de eliminar la rama, es posible que ya no puedas ver este commit y en realidad perderías los datos. Entonces recuperemos esa rama una vez más. Y como pueden ver, hemos cambiado a esa nueva sucursal. Y si haces git log, puedes ver que la rama está apuntando a la misma commit exacta. En realidad, la forma correcta verlo ha echado un vistazo a lo que hay dentro de la característica de un archivo de rama. Y como era de esperarse, está apuntando a este compromiso. Ahora podemos seguir adelante y fusionar todos los cambios cambiando de nuevo a rama maestra. Y eso es algo que ya vimos en nuestra conferencia anterior. Git, fundir característica uno. Y esto camina. Ahora puedes seguir adelante y eliminar esta rama con la opción d minúscula y no hay problema alguno. Echemos un vistazo a la lista de sucursales. Y ya verás que la única sucursal que tenemos es ahora la Maestra. 34. 0404 comprendiendo el compromiso de fusión y fusión de tres vías: Hablemos de fusionar a tres vías y obtener. Digamos que este es el estado actual de nuestro proyecto. Tenemos la rama principal con tres commits, m1, m2, y m3. Y luego también tenemos la rama característica con los commits F1, F2, y F3. E imagina que en cada uno de estos commits, entregamos un solo archivo. Por ejemplo, en M1 commit, entregamos m1 punto TXT. En M2 commit, entregamos m2 dot TXT, así sucesivamente y así sucesivamente para todo el resto de los comentarios. Ahora no voy a mantener los nombres de los archivos en este diagrama sólo para mantenerlo limpio. Ahora supongamos que mientras estoy trabajando en los cambios de característica uno, tengo dos comentarios adicionales y rama maestra. Ahora una pregunta para ustedes, si decido fusionar la característica uno en master ahora, ¿podemos esperar realizar una fusión de avance rápido en este caso? La respuesta es no, no podrá hacer eso. De acuerdo, supongamos hipotéticamente que bien ha hecho una fusión de avance rápido. Por lo que ahora tenemos la rama maestra apuntando a la última característica de commit off una rama. ¿ Se puede adivinar lo que va a pasar? Bueno, queríamos perder cambios introducidos y m cuatro y m phi combatientes porque no caen bajo la jerarquía de padres del commit que la rama maestra está apuntando. Esto no es algo ideal de hacer y lo bueno no realiza fusión de avance rápido en este caso. Sin embargo, lo que el rendimiento de TI es llamada fusión de tres vías. Entonces lo que esencialmente hace es cuando decidimos fusionar la característica uno en rama maestra, fuimos a ir dentro de la rama maestra y pedir get para realizar la fusión. Y cuando lo digamos así consigue creará artificialmente un commit con lo que lo iniciamos. Este commit tendrá dos padres. En otras palabras, este objeto commit apuntaría a otros dos objetos comunes y esos comentarios salen los últimos comentarios de ambas ramas, este commit se llama merge commit. Y la instantánea resultante de este commit, la combinación de cambios introducidos en ambas ramas. Esencialmente, si quieres ver el directorio de trabajo de la rama maestra después de realizar la fusión, vas a ver todos los cambios introducidos en ambas ramas. Una vez que terminemos con la fusión, podemos seguir adelante y eliminar la característica una rama. Tome una nota eliminando característica una rama solo eliminaría esa rama, pero no las commits que están en la rama de la característica. Porque merge commit hace referencia a commit. Por lo que la rama característica, por lo get no será capaz de eliminar eso, que get no será capaz de eliminar eso, están calificados para la recolección de basura. Ahora lo que estamos hablando en este momento es el mejor de los casos. la mayoría de las ocasiones tenemos los llamados conflictos de fusión. Por ejemplo, si agregué el mismo archivo en ambas ramas. Y entonces cuando intentamos fusionar estas ramas, get nos va a decir que hay conflicto de cambios en ambas ramas sólo después de que resolvamos ese conflicto de fusión. Bueno, el git fusionan todas las ramas. ir a hablar de conflictos de fusión en próximas conferencias. Y tal vez te estés preguntando por qué esto se llama fusión de tres vías. Bueno, vas a encontrar respuesta a eso también en próximas conferencias. Una vez después hablamos de los conflictos de fusión. A continuación, vamos a echar un vistazo un ejemplo de fusión de tres vías, suponiendo que no tenemos ningún tipo de conflictos. Te veré en la siguiente. 35. 0405Three Way Fuge en acción: Con el fin de explicar impulsó mucho al extranjero el proyecto a este estado. Inicialmente comprometí M1, M2, M3 en rama maestra, y luego creé el cambio de rama de funciones a él e hice tres comentarios por ahí también. F1, F2 y F3. Una vez más cambié a master e hice commits adicionales, M4, M5. Y ese es el estado actual de nuestro proyecto. Y sin mencionar, para todos y cada uno de los commit, he comprometido sus archivos específicos. Ahora veamos cuánto se hace. Actualmente estoy dentro de master. Y así podrás ver todos esos cinco archivos correspondientes a todos esos cinco commits. Si tuviera que cambiar a contar con una rama, vas a ver M1, M2, M3, y F1, F2 y F3, pero no m cuatro y m phi, que vinieron en rama maestra después de que creamos feature one branch. Y esta es la razón por la que no podemos realizar una fusión de avance rápido. Ahora volvamos a cambiar rama maestra y realizar la fusión y ver qué va a pasar. Git merge característica uno. Y tenemos que hacerlo desde dentro de la rama maestra porque queremos traer toda la característica que uno cambia en la rama maestra. Y cuando ejecuto este comando, en realidad ha abierto el editor de texto predeterminado que he elegido al instalar el bueno. En mi caso, es Notepad Plus, Plus. En tu caso, podría ser otra cosa dependiendo de lo que hayas elegido al instalar Git. Y lo que nos está pidiendo es introducir algún tipo de mensaje. Este es el mensaje que se asociaría con el commit de fusión. Puedo cambiar el texto a otra cosa en maestro, algo de ese tipo. Guarde el archivo y cierre la ventana. Y esto ha creado el commit de fusión. Alternativamente, mientras ejecuto este comando, también puedo proporcionar la opción guión m y proporcionar el mensaje. De esa manera get no abrirá el editor de texto. De acuerdo, ahora echemos un vistazo a get log n z Si Dios ha creado un commit de fusión. Y efectivamente, sí creó el commit de fusión. Y también ha mencionado que esta comisión se basa en estos dos commits. Estos no son más que los últimos cometas de ambas ramas. Entonces tenemos este hashCode de la rama maestra, y esto pertenece a la rama de características. Echemos un vistazo a lo que hay dentro de este objeto merge commit. Entonces lo voy a copiar. Voy a presionar Q para volver a la línea de comandos para que pueda teclear algunos comandos. Git cat, guión b y hashCode del commit de fusión. Y si te das cuenta que está apuntando a estos dos commits. Una es la última commit, la rama maestra, que sería esta. Y esta es la última de la rama de largometrajes. Echemos un vistazo a lo que hay dentro de este objeto arbóreo. Voy a usar exactamente el mismo comando. Y veamos qué hay dentro de ese objeto arbóreo. Ydéjame expandirme. Este objeto arbóreo es en realidad combinación de todos los cambios realizados en ambas ramas. Así que se ven todos estos archivos, F1 punto TXT, después de dxdy, F tres, M1, M2, M3, M4, y M5. E incluso en directorio de trabajo, vas a ver ahora todos los cambios de la rama de características. , si vuelves a la rama de funciones Sin embargo, si vuelves a la rama de funciones, notarás que no hay cambios realizados aquí. Es exactamente el mismo directorio de trabajo que antes, la hipoteca. Ahora podemos realmente seguir adelante y eliminar la característica una rama. Pero antes que nada, volvamos a rama maestra porque no podemos eliminar la rama en la que estamos actualmente. Entonces voy a usar el comando get. Voy a decir git branch guión D, característica uno. Y esto ha eliminado la sucursal. 36. 0406 Comprensión de conflictos: Hablemos de conflictos de fusión y asumamos que he hecho un commit en rama maestra, llamémoslo M1. Y como parte de este comentario, he introducido el archivo producto punto TXT con par de líneas de código. Ahora, obviamente no tiene sentido escribir código y punto archivo TXT. Es necesario hacer una suposición de que esto es algún tipo de archivo fuente, como el archivo Java Python o lo que sea. Ahora también debo mencionar que normalmente nunca tendemos a hacer commits en rama maestra. Lo que solemos tener en rama maestra, o los llamados commits de fusión, que ya hemos discutido anteriormente. Cuando hablamos de repositorio centralizado y colaboración en equipo. Comprenderás cómo todo el mundo crearía sus propias ramas para caminar sobre sus propias características y luego fusionar todos esos cambios en la rama maestra en el repositorio centralizado. Y luego, cuando actualicemos localmente el proyecto, vamos a conseguir todos esos commits de fusión realizados por otros miembros del equipo en nuestra rama maestra. Si esto suena confuso, entonces tendrás que aguantar hasta que hablemos de repositorio centralizado y colaboración en equipo. Por ahora, por el bien de este ejemplo, supongamos que estamos haciendo commits en la rama maestra. Yo hice M1 commit, introduciendo este archivo producto punto TXT con un par de líneas de código. Y luego hice otro commit, llamémoslo m2. Esta vez he actualizado el producto dot archivo TXT con un par de líneas más de código. Asumamos ahora que he decidido trabajar en otro largometraje. ¿ Adivina qué? Voy a crear una rama de características, trabajar en ella, introducir todos esos cambios. Y entonces habremos hecho un commit en el que he modificado el archivo TXT de punto del producto escribiendo un par de líneas adicionales de código que son relevantes para la característica uno. En tanto, volví a cambiar a rama maestra. Entonces nuestro archivo de proyecto se vería algo como esto porque rama maestra está apuntando a m para comprometerse. Y luego supongamos que hice una rama maestra más comprometida actualizando el archivo TXT de punto de producto, como estás viendo aquí. Ahora una pregunta para ti. Digamos que he decidido fusionar rama característica en la rama maestra. Y ejecuto el comando y llego a fusionar la rama. ¿ Esperarías llegar a realizar la fusión? La respuesta es no. ¿Por qué? Porque tenemos un par de versiones de producto dot archivo TXT. En rama maestra tenemos producto punto TXT que estás viendo a la izquierda. Y en la rama de funciones tenemos el archivo que estás viendo a la derecha. Cuando pedimos bueno fusionar, no puede guardar ambos archivos. Consiga esto confuso en cuanto a cuál de estos cambios necesita guardar o necesita guardar cualquier cambio en absoluto. Obviamente, no es lo suficientemente inteligente como para hacer ediciones de acuerdo a nuestras necesidades. Por lo que nos dejará a nosotros hacer todos los cambios, resolver los conflictos. Sólo entonces obtendrá realmente seguir adelante y realizar la fusión y crear una confirmación de fusión. Esencialmente cuando ejecutas el comando para fusionar, arrojará un error diciendo que se ha encontrado complejo en algunos de los archivos. Y sólo después de resolverlos ¿seguirá adelante y fusionará los cambios y creará merge commit? Ahora bien, ¿por qué esta fusión se llama fusión de tres vías? Tal vez te preguntes, bueno, es básicamente porque esta fusión implica tres instantáneas, los dos últimos comentarios y el convecto que es un ancestro inmediato de ambos estos comentarios. Este colega, comparará el archivo en la instantánea del ancestro inmediato con los archivos en las últimas instantáneas en ambas ramas. Ahora si no lo entendiste, está completamente bien. realidad no vale la pena conocerlo. Para explicarlo. Bueno, en realidad tengo que ir profundo y otra vez, meterme en esos HashCode y todo, lo cual no quiero porque no es para nada lo que solo recuerda que a este tipo de modelo se le llama una fusión de tres vías. Y eso debería bastar. Y el modo de avance rápido también se llama como para emerger porque solo implica un par de instantáneas. A continuación, vamos a echar un vistazo a todo esto en acción y ver cómo podemos resolver los conflictos. 37. 0407 Combinar conflictos en acción Parte 1: De acuerdo, echemos un vistazo a los conflictos de fusión, la inacción. Y para ello tengo una carpeta nueva que actualmente no tiene nada. Todo lo vamos a hacer desde cero. En este video, intentaremos crear un escenario donde tengamos conflictos. Y luego en el siguiente video veremos en realidad cómo podemos resolver esos conflictos para poder fusionar las ramas. Primero lo primero, vamos a inicializar el proyecto. Ahora asuma que obtuve un proyecto de uno de los clientes, mientras que me pidió crear una aplicación de gestión de productos. Dentro del proyecto, podría estar teniendo estos archivos. Es posible que tengamos un archivo de producto que tendrá el código fuente relacionado con el producto. Y luego podríamos tener un archivo de inventario, y luego tal vez un archivo de administración también. Ahora, obviamente estos archivos no pueden ser archivos TXT de punto. Es necesario hacer una suposición de que estos son algún tipo de archivo fuente como Java, python, Node.JS o lo que sea. Ahora vamos a seguir adelante y poblar algo en este archivo, simulando que en realidad estamos escribiendo código fuente. Comencemos con el archivo txt de punto de producto. Así. Tienes que asumir que esto es en realidad algún tipo de código fuente. Guarde el archivo y ciérrelo. Y voy a hacer lo mismo para los otros dos expedientes también. Guarde el archivo y ciérrelo. Hagamos lo mismo para el archivo admin. Guarda y cierra eso. Escenemostodos estos expedientes. Git add. Utilizaré carácter comodín para escenificar todos los archivos. Y cometamos esos cambios. Lo que sea, algún mensaje. Ahora supongamos que empecé a trabajar en otra característica. Y así tengo que crear otra rama para trabajar en todos esos cambios relacionados con las características. Voy a usar el comando git checkout guión b, y luego el nombre de la rama. Por lo que este comando creará una rama característica así como cambiar a ella. Por lo que actualmente estamos dentro de la característica una rama. Vamos a hacer algunas ediciones y estos dos archivos inventario así como producto dot txt archivo. Pero vamos a dejar el archivo admin dot TXT tal cual. Simplemente voy a agregar un par de líneas más de código. Pero voy a decir característica al inicio de estas líneas, solo para que sepamos que estas líneas se introducen en la rama característica. Conoces el propósito de esto en sólo un poco. Voy a hacer lo mismo para el inventario dot txt file. Así, guarda el archivo y ciérralo. Escenemos todos estos cambios. Algún mensaje y comete todos los cambios. Permítanme cambiar de nuevo al maestro una vez más. Despejemos la pantalla e intentemos actualizar el archivo TXT del punto del producto. Pero deja estos dos tamaños de archivo. Obviamente no vamos a ver todos esos cambios relacionados con funciones aquí porque cambiamos de nuevo a rama maestra. Cerremos el archivo, escenifiquemos estos cambios y comprometamos esos cambios. Así. Entonces sólo para reiterar lo que hemos hecho, tenemos todos estos tres expedientes no se habían presentado demanda como es como es antes de crear la sucursal. El archivo de inventario se actualiza en la rama de funciones, pero no en la rama maestra desde ese momento en que creamos la sucursal, pero el archivo de producto se ha modificado en ambas ramas. Ahora se puede hacer una conjetura ¿cuál de estos archivos tendrá conflictos? Cuando intentamos fusionarnos, los cambios continuarán a partir del siguiente video. 38. 0408 Combinar conflictos en acción Parte 2: Todo eso. Tratemos de realizar la fusión y veamos qué pasaría. Actualmente estoy dentro de la rama maestra y cuándo ejecutar el comando git merge feature one. Bueno dice que ha generado conflictos en el archivo TXT de punto de producto. Y dice que la fusión automática falló, corrige los conflictos y luego comete el resultado. Eso es bastante autoexplicativo. Además de eso, gateway también está diciendo que nuestro proyecto está en estado de fusión. En la gestión del estado. Git formateará todos esos archivos en conflicto de una manera que nos resulte más fácil entender lo complejo y resolverlos. Ya sabrás a lo que me refiero en sólo un rato. Pero intentemos ejecutar el comando git status y veamos qué tiene que decir. Dice que tenemos caminos sin fusionar. Y nos está pidiendo que arreglemos el complejo y luego ejecutemos el comando git commit. ¿ Y si decidimos salir de este estado fusionado? Podemos ejecutar este comando con dash, dash, compré opción, este voy a comprar el estado emergente y traer de vuelta el proyecto como estaba antes de ejecutar el comando merge. Tiene etapa el archivo TXT de punto de inventario porque no tiene ningún conflicto. Está listo para fusionarse. Pero mientras que para el archivo TXT de punto de producto, se categoriza bajo rutas no fusionadas. Por lo que todos los archivos que se enumeran en esta sección, necesitaremos resolver los conflictos y pedir get para cometer todos esos cambios para completar la operación de fusión y crear el commit de fusión. Ahora echemos un vistazo al contenido del archivo TXT de punto de producto. Si bien nuestro proyecto se encuentra en estado de fusión. Quería decir cat product dot archivo TXT. Y puedes ver que es un poco diferente de cómo podrías haber esperado. Verías lo mismo aunque tuvieras que abrir el archivo en un editor externo. Lo que esto significa esencialmente es esta sección de código pertenece a head, lo que significa que esta llamada pertenece a la rama donde tenían esto apuntando. Estos son los cambios introducidos en la rama maestra esencialmente. Entonces tenemos este conjunto de cambios que se introdujeron en la característica una rama. Si has comprado el estado emergente diciendo git merge guión, guión comprado. Se vería que todo ese formato se ha ido. Y nuestro proyecto es esencial en finca como si nunca hubiéramos ejecutado el comando de fusión en absoluto. Tratemos de fusionarnos de nuevo y veamos cómo podemos resolver estos conflictos. Ahora como programador, tienes que decidir cuál de estos cambios te gustaría conservar. O si quieres conservar ambos cambios, puedes seguir adelante y hacer eso también. Literalmente puedes hacer agua que queremos hacer. Y una vez que termines, solo pide get para cometer esos cambios y crear los objetos de fusión. Cómo terminar la fusión de ambas ramas. Entonces necesito deshacerme de estos extraños personajes que ha introducido. Y entonces tal vez me gustaría eliminar esta línea de código, pero quédate con todos estos tres. Sólo un ejemplo. Qué, oh, eso tiene sentido. Te gustaría conservar ese código. Guárdelo y ciérralo. Y una vez resuelvas todos esos complejos manualmente, puedes seguir adelante y decir git commit. Antes de entrar, necesitamos realmente poner en escena este archivo, producto dot archivo TXT. Y entonces podemos seguir adelante y con los cambios está pidiendo que ingresemos un mensaje de commit. Estoy contento con el predeterminado. Quería guardar este archivo, cerrarlo. Y esto ha creado con éxito un commit de fusión, lo que significa que nuestro margen ya está hecho. Y así ya no verías el status más gen. Ahora echemos un vistazo al contenido dentro de todos estos archivos. El archivo admin dot TXT quedaría tal cual porque nunca se modifica en ninguna de las ramas. De todos modos. En el fichero de inventario, vas a ver todos esos cambios de funciones añadidos. Y estos se fusionaron de la rama de largometrajes. Poner en el archivo txt punto del producto. Tendría el código que hemos actualizado mientras resolvemos los conflictos. Además, espero que estés teniendo una idea de la necesidad de tener una herramienta más robusta para administrar tu proyecto y sus archivos. Y también poder visualizar todos los cambios históricos, etcétera. Y ahí es donde entrarían en escena herramientas como Visual Studio, Code, GitHub , Desktop, tree source, etcétera . vamos a explorar en próximas conferencias. 39. 0409 Instalación y configuración de código de Visual Studio para trabajar en Git: De acuerdo, es hora de instalarlo y usar una de las herramientas disponibles para ayudarnos a administrar nuestro proyecto de una mejor manera, porque no podemos seguir usando el sistema de archivos de Windows y Git Bash para trabajar en nuestro proyecto. A medida que un proyecto se vuelve más complejo, necesitamos algún tipo de herramienta que nos ayude a gestionar nuestro proyecto de una mejor manera y poder ver algunos de los cambios históricos o lista de commits que habíamos hecho. Echa un vistazo a la lista de ramas mismo tiempo que puedes realizar algunas de las operaciones sin tener que ejecutar comandos en el Git Bash. Entonces hay muchas herramientas disponibles en línea y no hay una sola herramienta que sea apta para todo tipo de cosas. Si vas a la página oficial de gate, que es Git SCM.com, python SCM.com. Y si vas a esta sección de líneas de cuadrícula, vas a ver que han enumerado están recomendando todas estas herramientas. Si usas alguna de estas herramientas, no debería ser difícil para ti usar ninguna de las otras herramientas disponibles aquí. Porque aunque difieren en términos de interfaz gráfica de usuario, prácticamente ofrecían la misma funcionalidad exacta. Github, escritorio y árbol de fuentes, o dos de las opciones más populares. Pero vamos a estar usando Visual Studio Code. El motivo por el que estoy recomendando esto es porque Visual Studio Code es uno de los editores de código populares. Es una de las opciones más populares en cuanto a desarrollar aplicaciones JavaScript Python, y tiene soporte para host de otros lenguajes de programación. Pero lo que diferencia el código de Visual Studio de algunas de estas herramientas son valiosas aquí es que su capacidad para instalar extensiones. Y así es como vamos a instalar una buena extensión. Y eso te dará algunas de las características que ofrecen algunas de estas herramientas. Estas herramientas de aquí. Visual Studio Code es más una herramienta holística, lugar de solo apuntar a obtener específicamente. Una vez que estés acostumbrado a usar Visual Studio Code, debería ser muy fácil para ti entender algunas de estas herramientas Y puertas. Si quieres elegir una de estas herramientas, entonces puedes seguir adelante y hacerlo si te sientes cómodo con eso. Pero voy a estar usando Visual Studio Code con una rápida búsqueda en Google. Llegamos a esta página. Adelante y descarga Visual Studio, dependiendo del sistema operativo que estés usando. Eso ya lo he hecho. Déjame lanzar el instalador. Instalarlo es bastante sencillo. Simplemente puedes dejar todo a los valores predeterminados a menos que quieras cambiar algo. De acuerdo, está instalado. Vamos a lanzar Visual Studio Code. Lo primero es lo primero, vamos al Explorer y cuándo abrir el proyecto haciendo clic en Abrir carpeta. Voy a elegir mi app que habíamos creado antes. Además de eso, voy a ir a la sección llamada extensiones. Yo buscaría Get. Obtener lente es una de las opciones populares. Obtener gráfica también es una buena opción. Vamos a instalarlo. De acuerdo, en el siguiente video, vamos a ver cómo podemos manejar conflictos de fusión en el código de Visual Studio. Por lo que eso te dará cierta exposición a Visual Studio Code así como mob las operaciones get que podemos realizar en él. Nos vemos el siguiente. 40. 0410 Explorar el código VS y realizar operaciones de GIT: De acuerdo, Antes de que realmente echemos un vistazo a cómo crear conflictos de fusión y resolverlos en código de Visual Studio. Permítanme simplemente guiarlos por el estado actual de nuestro proyecto. Si recuerdas, habíamos fusionado nuestros cambios de la característica uno a la rama maestra. Estos son todos los listados de archivos de nuestro proyecto. Simplemente puede hacer clic en ellos para echar un vistazo a su contenido. Y si vas a esta sección control de fuentes, también puedes ir ahí pulsando Control Shift G. Y como habíamos instalado esta extensión buena gráfica, deberías poder mirar este ícono. Aquí puedes ver todos los cambios históricos que habíamos introducido. También puedes ver la representación gráfica de toda la lista de commits que habíamos hecho, las ramas que habíamos creado, e incluso la fusión que habíamos realizado anteriormente. Este es el primer commit que hicimos en rama maestra, y luego creamos una rama de características. Ahí hicimos un comentario. Y luego hicimos un comentario y rama maestra y eventualmente característica ramas fusionadas dentro de la rama maestra. Para crear el comando de fusión. No hizo clic en uno de estos commits y echó un vistazo a los cambios introducidos en ese commit en particular haciendo clic en un archivo en particular. Y se pueden ver los cambios. Ahora vamos a seguir adelante y crear conflictos en los que nosotros, los humanos somos naturalmente buenos. Volvamos a Explorer. Pero antes de eso, veamos cómo podemos crear una nueva sucursal. Voy a crear una nueva sucursal aquí mismo. Entonces voy a hacer clic derecho en este commit en particular y decir Crear Rama. Llamémoslo característica para ramificar, lo que sea. Y también me gustaría cambiar a esa sucursal. Por lo que marco esta casilla de verificación crear sucursal. Entonces cambiamos a esa característica a rama que acabamos de crear. Se lo puedes decir echando un vistazo aquí. Aquí puedes ver toda la lista de sucursales. Una vez que hagas clic en él, podrás ver toda la lista de sucursales. Si deseas cambiar a una de las sucursales, simplemente haz clic en ella. Por lo que sólo deseamos dominar rama. Y entonces eso es lo que estás viendo aquí dentro. Permítanme cambiar de nuevo a característica dos ramas y hacer un commit. Voy a ir al Explorer. Permítanme hacer algunas modificaciones y la función de fichero de inventario a los cambios en el fichero de inventario o lo que sea. Voy a volver a esta sección control de fuentes. Voy a dar clic en este icono de cheque. Al hacer eso. Me está mostrando un mensaje diciendo que no hay cambios escenificados por venir. ¿ Te gustaría escenificar todos los cambios y comprometerlos directamente? Si le pego sí, ahora mismo, va a escenificar los cambios antes comprometerse sin que yo tenga que hacer eso. O si quieres hacerlo por tu cuenta, puedes hacerlo también. Simplemente haga clic derecho en este archivo que actualmente se encuentra bajo la categoría de cambios. Y luego dar clic en los cambios de escenario. Esto movería ese archivo a la categoría de cambios por etapas. Y ahora si vienes a, no deberías tener ningún problema ni lo que sea. Pero entremos algún tipo de mensaje de commit. Lo que sea. Da clic en este icono y acaba de hacer un nuevo commit y cuentan con dos ramas. Echemos un vistazo a la gráfica. Y como pueden ver, ahora tenemos un nuevo commit agregado en la gráfica. Y aquí está. Ahora volvamos a la rama maestra. Hagamos ediciones en este mismo fichero de inventario. Entonces, para crear conflictos, guarde el archivo. Vuelve aquí. Esta vez. Vamos a golpear la S. Si no te gusta volver a ver este prompt, entonces simplemente puedes presionar nunca. Volvamos para obtener gráfica una vez más. Y como pueden ver, ahora tenemos una nueva rama commit y master. Ahora intentemos realizar la fusión. ¿ Cómo realizamos mucho en Visual Studio Code? Pero esta extensión, bueno, es bastante fácil. Simplemente haga clic derecho en una de las ramas. Voy a hacer clic en función a sucursal. Y se puede elegir esta opción que dice fusionarse en rama actual. ¿ Cuál es la rama actual es decir máscara? Bueno, es simplemente la rama a la que tenía esto apuntando. En otras palabras, es la rama maestra. Demos click en él y veamos qué pasa. ¿ Nos está preguntando si queremos crear un nuevo commit, aunque sea posible la fusión de avance rápido? No me gusta contestar. Sí, fusionar. Como era de esperar, tenemos un inventor de autofusión de conflictos o dxdy. Y luego dice que tenemos un conflicto. Deshazlo, ve a Explorer, ve a ese archivo. Y esta vez nos tiene formato de esta manera, al igual que antes. Pero usamos hoy Dios nos dio pocas opciones. Si observa, acepte los cambios actuales, acepte los cambios entrantes o los cambios que vienen de la entidad a la rama, a la rama maestra. O aceptar ambos los cambios. O también puedes comparar los cambios. Se puede elegir. Cualquiera de estas opciones son si quieres hacer tu propia edición, por lo que puedes hacer eso también. Simplemente borra todo y trae tus propios cambios o edita el existente. Lo que sea. Agreguemos como para mantener tanto los cambios o clic en esto que dice aceptar qué cambios. Ahora guarde el archivo. Volver al control de fuente. Antes de que lo cometamos. Escenemos estos cambios son bastante escenificados. Demos clic en esta casilla de verificación. Estoy contento con el mensaje existente. Y adivina qué? Esto acaba de crear el commit de fusión. Ahora bien, si estás usando una herramienta diferente, no el Código de Visual Studio, entonces deberías poder mirar todas estas operaciones de una u otra manera. Sólo puede cambiar la interfaz gráfica de usuario. Pero en todas esas herramientas, se puede realizar prácticamente el mismo conjunto de operaciones. Por ejemplo, si vas a la página oficial del árbol de fuentes, solo echar un vistazo a esta imagen, puedes decir mucho. Entonces tenemos una historia que muestra los cambios históricos. También tienes esta gráfica, igual que la que tenemos en el Código de Visual Studio. También puedes ir a esta sección de ramas para echar un vistazo a las ramas y hacer algo con eso, como crearlas, eliminarlas, etcétera. También puedes realizar commits. Y algunas de las otras operaciones que no hemos explorado. Vamos a explorar en próximas conferencias con seguridad. Pero espero que hayas conseguido el punto. No importa qué herramienta utilices. En última instancia, cada herramienta tiene el mismo propósito, que es simplificar tu trabajo. Ahora supongo que podemos eliminar esta rama. Ya no lo necesitaríamos. Entonces voy a hacer clic derecho en esta rama y decir Eliminar rama. Puede hacer la misma característica, una rama también. Y por supuesto, la marca líder no elimina sus commits. Como habíamos discutido antes. Espero que tenga sentido, ¿verdad? Para hacer lo que acabo de hacer en Visual Studio Code y tener una idea de cómo está funcionando todo. Y no te dejes intimidar mirando esta herramienta. Esbastante sencillo. Tool es simplemente como un editor de texto con algunas características realmente geniales. Está ahí para hacernos la vida más fácil, no más difícil. Nos vemos el siguiente. 41. 0411 Git Rebase vs Merge: Hablemos de git rebase. rebase de Git es una especie de alternativa para fusionarse. Sirve más o menos el mismo propósito que con la operación de fusión. Pero dicho eso, no se puede sustituir uno por otro. No podemos sustituir a VBS con la fusión, y viceversa, no podemos reemplazar la fusión con la rebase. Tiene sus propios pros y contras y cada uno tiene su propio propósito. Y de eso vamos a hablar en esta conferencia y en el próximo par de conferencias. En primer lugar, intentemos entender qué es exactamente rebase. En caso de fusión de tres vías, GET solicita crear un commit de fusión cuya instantánea constituiría los cambios de ambas ramas. Si bien esto no suena como un problema, sí empezamos a ver algunos problemas con él, sobre todo cuando nuestro proyecto se hace cada vez más grande. En primer lugar, la fusión crearía este commit de fusión adicional, que podría ser innecesario. En segundo lugar, crea el problema de los llamados spaghetti commit history. Si realizas demasiadas operaciones de fusión en tu proyecto. Así es como podría verse nuestro historial de proyectos. Ahora bien, si fueras a echar un vistazo a todos los commits históricos realizados, tal vez digamos que has ejecutado comando git log en la rama maestra. Todo lo que nos vas a ver montón de commits merge. No se llega a ver los cambios introducidos una ramas individuales. Tienes que navegar por la jerarquía padre para poder ver todos los cambios o comentarios relacionados con la rama. Esto va a crear mucha confusión. Rebus puso tipo de abordar estos problemas que vemos con merge commits. Para entender cómo funcionan exactamente las rebajas, supongamos que no hemos realizado la fusión de estas dos ramas. Y este es el estado actual de nuestro proyecto. Ahora supongamos que estoy en la característica una rama y he ejecutado el comando git rebase. De lo bueno que haríamos ahora es en primer lugar, se tratará de encontrar el ancestro común de ambas ramas, que en este caso es N3 commit. Y luego almacenará temporalmente todos estos cambios introducidos en la característica uno. En algún lugar del repositorio. Entonces señalaría la característica una rama a la punta de la rama maestra, que en este caso es m phi commit. Git volverá a aplicar todos esos commits almacenados uno por uno. Esto es como que hemos creado la rama AT MY commit e introducido todas esas características conducen a cambios en la rama de la característica. Anteriormente nuestras ramas de características basadas en M3 commit. Ahora después de ejecutar el comando rebase, ahora se rebasa en m phi. Ahora, mientras haces esta operación, bien podrías ver conflictos. Podemos resolverlos así como habíamos resuelto conflictos en caso de operación de fusión. Fuimos a ver un ejemplo de eso en próximas conferencias. Ahora bien, si echas un vistazo a este diagrama, te das cuenta de que en realidad podemos realizar una fusión de avance rápido así. Ahora adivina qué? No se presentaron comentarios adicionales. Un commit allo son lineales con la operación de fusión. Si tuviste ese problema de spaghetti commit history con rebase, tenemos desarrollo lineal como estás viendo aquí, que hace que sea más fácil para nosotros echar un vistazo a la historia de commit. Y si tuvieras que ejecutar el comando git log ahora, no solo verás cómo se introdujeron los cambios en la rama maestra, sino también todos los comentarios relacionados con las funciones, así como de manera lineal. Ahora podrías estar pensando que podemos empezar a usar rebase y nunca tendríamos que usar merge nunca más. Podrías estar equivocado. Hay ciertos escenarios donde rebase es lo ideal para hacer, y hay otro conjunto de escenarios donde mucho es una mejor opción. Entenderás más al respecto Up next. 42. 0412 Realiza la reconstrucción en código VS: De acuerdo, echemos un vistazo a un ejemplo de git rebase. Pero antes de eso, déjame que te acompañe por el estado actual de nuestro proyecto. En realidad he creado un proyecto completamente nuevo para este propósito y he hecho un montón de commits. Deja que te acompañe a través de lo que exactamente he hecho. Desde la rama maestra como parte del primer commit, acabo de introducir estos archivos TXT, inventario de administración y archivos TXT de punto de producto. Y en cada uno de esos archivos, acabo de agregar un par de líneas de texto como si hubiéramos escrito algún código. El siguiente commit también fue dentro del maestro. Y antes de eso, por supuesto que he creado una rama que se basa en el primer commit. Como parte del segundo commit, como nos sugiere el mensaje, admin Edits y master. Acabo de agregar una línea de texto dentro del archivo admin dot TXT, así. Y luego hice mi primer commit en la rama de características y hace el mensaje sugiere ediciones de inventario de la característica una rama. Acabo de agregar una línea de texto dentro del archivo inventado o TXT. La próxima vez hizo commit en rama maestra. Y esta vez he añadido una línea de texto en el archivo TXT de punto de producto. Y luego hice un comentario más en la rama de funciones donde he editado el archivo TXT de punto de producto. Al final de la línea. Cuando realicemos la rebase, vamos a tener conflictos en archivo TXT de punto de producto porque tenemos un commit hecho en master donde hemos editado product dot TXT file, y lo mismo se hace en el característica rama también. La próxima vez hizo una rama maestra más comprometida. Bueno, esto no me hace falta realmente para explicar esto, pero he hecho este comentario solo para que la gráfica se vea como queremos. Básicamente actualmente esta línea azul representa la rama maestra, mientras que la línea roja representa la rama de entidad. No obstante, este puede no ser el caso siempre. Cualquiera que sea la rama que hagamos el último commit que se mostraría primero. Por ejemplo, si tuviera que hacer una rama de características de comentario más, rama de características se pondría azul y la rama maestra se volvería roja. Podría parecer confuso. Y es por eso que he añadido este commit adicional para que la rama maestra se muestre primero y luego la rama de características. Ahora antes de seguir adelante, es realmente importante que entiendas qué está pasando exactamente y cuáles son todos los cambios que hemos introducido en cada uno de estos commits. Por lo que voy a poner a disposición este proyecto para que lo descargues. Simplemente puedes importarlo al código de Visual Studio y echar un vistazo a toda la lista de cambios, entenderlo, y sólo entonces proceder. De lo contrario, comenzarás a confundirte. Si eres capaz de seguirte, eso es genial. Si no lo estás, entonces haz una pausa, entiende lo que está pasando aquí, y luego sigue viendo. Por lo tanto, como puede ver, la característica una rama se basa actualmente fuera de la primera confirmación en rama maestra. Ahora queremos rebasar la característica una rama a la última rama de commit off master. ¿ Cómo hacemos eso? Bueno, hagamos clic derecho en el último commit, la rama maestra. Y luego tenemos esta opción llamada rebase branch current on this commit. La rama actual es rama maestra. Cuándo cambiar a rama de función. Y sabemos que hemos empujado a con una rama porque este círculo aquí mismo está apuntando a contar una rama antes estaba apuntando a rama maestra. Ahora hagamos clic derecho en la última rama de commit off master y escojamos esta opción que dice rebasar rama actual. En esto, las ramas actuales cuentan con una rama. Y esto idealmente debería rebasar a menos que tengamos conflictos. Por supuesto, vamos a ver conflictos porque como he mencionado antes, hemos editado product dot archivo TXT en ambas ramas. Entonces vamos a dar clic en rebase. Como pueden ver, tenemos conflictos. Desestimaremos esto. Bueno, idealmente deberíamos estar viendo esos archivos con complejo déjame refrescar. Y ahí lo tienes. Podrás resolver los conflictos y de la forma que quieras. En mi caso, sólo quiero aceptar los dos cambios. Guarde el archivo. Y luego voy a presionar este ícono más para escenificar este archivo. Y luego puedo hacer clic en este icono de verificación para proceder realmente con la operación de rebase. Y el mensaje que se llena por defecto aquí es el mensaje de la característica de comentarios, una rama que en realidad está creando el conflicto. Obtenemos este editor abierto. Pero sólo voy a dejar el mensaje como está, cerrar el archivo. Y esto debería terminar la operación de rebase. Como puede ver, los primeros cuatro commits están fuera rama maestra y los otros dos comentarios pertenecen a la rama de entidades. Ahora podemos seguir adelante y realizar la Marcha de Avance Rápido. Entonces voy a cambiar de nuevo a rama maestra. Haga clic derecho en esta confirmación. Y entonces puedo elegir fusionarme en rama actual. Así que quiero fusionar característica una rama en la rama maestra. No quiero crear un nuevo commit para una fusión de avance rápido. Entonces así es como se realiza la rebase. Y si se nota, tenemos este desarrollo lineal, que es lo que estamos esperando con rebase. Nos vemos a continuación. 43. 0413 Git Rebase en Git Bash Skipping conflictos y Abortar la Rebasa: De acuerdo, veamos cómo podemos realizar git rebase desde Git Bash. Actualmente estamos en rama maestra me para cambiar a característica de una rama para poder ejecutar ese comando. Y por cierto, han devuelto el proyecto a cómo se veía al inicio de nuestro video anterior. Para que podamos rehacer las cosas y ver cómo funciona desde Git Bash. Voy a cambiar a sucursal de características. Se puede observar simultáneamente lo que está sucediendo en esta gráfica. Rebase de Git. ¿ Dónde quiero rebasar para hacer un commit? Esa rama maestra está apuntando a alguien que diga Maestro. Y como se puede esperar, vamos a ver los conflictos. Sigamos adelante y los disuelvamos. En mi conjetura, una vez más, no aceptaría ambos los cambios, guardaría el archivo, y volvería a Git Bash, fui a escenificar ese archivo, git add product dot archivo TXT. Y luego necesitamos ejecutar este comando. Git rebase, guión, guión continúan realizando la rebase. Y eso lo voy a hacer. También tienes la opción de saltarte. Si ejecutas este comando, git simplemente omitirá el commit que está causando los conflictos. Es como si no hubieras hecho la rama de funciones comentadas que está causando los conflictos. Si ejecuta este comando, tal vez después de realizar con éxito la rebase, es posible que desee volver a aplicar todos esos cambios manualmente. No obstante, como hemos resuelto el complejo, no tienes que usar esta opción, pero siéntete libre de experimentar con ella. Una vez ejecuto este comando. Nuevamente, nos va a mostrar el mensaje. Podemos mantenerlo como está. O si deseas cambiarlo, puedes seguir adelante y cambiarlo. Vamos a cerrar. Y como pueden ver aquí, hemos rebasado nuestra rama de funciones con la rama maestra. Vamos ahora a seguir adelante y realizar la parte de fusión, que vamos a cambiar de nuevo a master git merge feature one. Y como puedes ver, ambas ramas están igualadas. Si un comando bone from git log ahora, vas a ver todos los commits introducidos en ambas ramas de manera lineal, que es lo que necesitamos. Y por cierto, operación de rebase bien realizada. Y por alguna razón has decidido abortarlo, entonces puedes usar esta opción, git rebase, guión, guión que compré. Nos vemos a continuación. 44. 0414 Git Rebase interactiva: Sostenga eso, hablemos de rebase interactiva. Y para ello tengo 1 segundo trajo de vuelta el proyecto a lo que era antes. Antes de realizar la operación de rebase. Permítanme cambiar a contar con una rama y realizar la rebase. Quiero hacer clic derecho en la última commit off Master, haga clic en rebase rama actual en este comentario. Pero esta vez voy a elegir esta opción que dice rubia rebase interactiva en nueva terminal. Esto es equivalente a ejecutar el comando git rebase con dash, dash interact to option. Vamos a hacer clic en sí rebase. Y en esta ocasión abriremos el editor de texto. Aquí vas a ver lista de titulares de commits que forman parte de la característica una rama. Lo que la rebase interactiva nos permitiría hacer es que en realidad podemos realizar una gran cantidad de personalización en función de nuestras necesidades. Si ves tenemos un montón de comandos aquí, que podemos usar para decirle a git qué queremos hacer con los commits o característica de una rama. Por defecto, este comando se usa pick, lo que significa que queremos usar ese comité. Lo que eso significa esencialmente es que queremos que estos cometas de característica una rama sean candidatos para la operación de rebase. Pero puedes cambiar este comando a otra cosa en función de tu requerimiento. Por ejemplo, tal vez me gustaría usar este comando reward, que significa usar commit, pero agregó el mensaje de commit. Esencialmente, si quieres cambiar el mensaje a otra cosa, entonces puedes usar este comando. Vamos, quiero cambiar el mensaje de esta comisión en particular. Yhagámoslo. Me gustaría usar este comando drop. Dejar caer este compromiso en particular. Sé que este comentario va a crear conflictos porque editamos product dot txt file en este commit. Entonces voy a dejar caer esto. De igual forma, tienes un montón de otros comandos que puedes usar. Simplemente puedes pasar por la descripción y ver si se ajustan a tus necesidades. Guarde el archivo y ciérrelo. Entonces vamos a ver otro prompt pidiéndonos encadenar el mensaje de ese commit. Si recuerdas cuál es este commit en particular, habíamos utilizado el comando de recompensa. De ahí obtengo esto que nos lleva a encadenar el mensaje a otra cosa. Puedes cambiar esto a lo que quieras. Por supuesto, no digas bla, bla, escribe algo significativo. Quiero guardar el archivo y cerrar esto. Por lo que esta vez si te das cuenta sólo tenemos cinco commits. Porque soltamos uno de los commits en la rama de la característica donde hicimos cambios en el archivo TXT de punto del producto. Y también para la otra característica comentarista, una rama cambiaría el mensaje a bla, bla. Así que adelante y tratar de experimentar con rebase interactiva. Nosvemos a continuación. 45. 0501 Git Rebase vs Merge: Hablemos de git rebase. rebase de Git es una especie de alternativa para fusionarse. Sirve más o menos el mismo propósito que con la operación de fusión. Pero dicho eso, no se puede sustituir uno por otro. No podemos sustituir a VBS con la fusión, y viceversa, no podemos reemplazar la fusión con la rebase. Tiene sus propios pros y contras y cada uno tiene su propio propósito. Y de eso vamos a hablar en esta conferencia y en el próximo par de conferencias. En primer lugar, intentemos entender qué es exactamente rebase. En caso de fusión de tres vías, GET solicita crear un commit de fusión cuya instantánea constituiría los cambios de ambas ramas. Si bien esto no suena como un problema, sí empezamos a ver algunos problemas con él, sobre todo cuando nuestro proyecto se hace cada vez más grande. En primer lugar, la fusión crearía este commit de fusión adicional, que podría ser innecesario. En segundo lugar, crea el problema de los llamados spaghetti commit history. Si realizas demasiadas operaciones de fusión en tu proyecto. Así es como podría verse nuestro historial de proyectos. Ahora bien, si fueras a echar un vistazo a todos los commits históricos realizados, tal vez digamos que has ejecutado comando git log en la rama maestra. Todo lo que nos vas a ver montón de commits de merge. No se llega a ver los cambios introducidos una ramas individuales. Tienes que navegar por la jerarquía padre para poder ver todos los cambios o comentarios relacionados con la rama. Esto va a crear mucha confusión. Rebus puso tipo de abordar estos problemas que vemos con merge commits. Para entender cómo funcionan exactamente las rebajas, supongamos que no hemos realizado la fusión de estas dos ramas. Y este es el estado actual de nuestro proyecto. Ahora supongamos que estoy en la característica una rama y he ejecutado el comando git rebase. De lo bueno que haríamos ahora es en primer lugar, se tratará de encontrar el ancestro común de ambas ramas, que en este caso es N3 commit. Y luego almacenará temporalmente todos estos cambios introducidos en la característica uno. En algún lugar del repositorio. Entonces señalaría la característica una rama a la punta de la rama maestra, que en este caso es m phi commit. Git volverá a aplicar todos esos commits almacenados uno por uno. Esto es como que hemos creado la rama AT MY commit e introducido todas esas características conducen a cambios en la rama de la característica. Anteriormente nuestras ramas de características basadas en M3 commit. Ahora después de ejecutar el comando rebase, ahora se rebasa en m phi. Ahora, mientras haces esta operación, bien podrías ver conflictos. Podemos resolverlos así como habíamos resuelto conflictos en caso de operación de fusión. Fuimos a ver un ejemplo de eso en próximas conferencias. Ahora bien, si echas un vistazo a este diagrama, te das cuenta de que en realidad podemos realizar una fusión de avance rápido así. Ahora adivina qué? No se presentaron comentarios adicionales. Un commit allo son lineales con la operación de fusión. Si tuviste ese problema de spaghetti commit history con rebase, tenemos desarrollo lineal como estás viendo aquí, que hace que sea más fácil para nosotros echar un vistazo a la historia de commit. Y si tuvieras que ejecutar el comando git log ahora, no solo verás cómo se introdujeron los cambios en la rama maestra, sino también todos los comentarios relacionados con las funciones, así como de manera lineal. Ahora podrías estar pensando que podemos empezar a usar rebase y nunca tendríamos que usar merge nunca más. Podrías estar equivocado. Hay ciertos escenarios donde rebase es lo ideal para hacer, y hay otro conjunto de escenarios donde mucho es una mejor opción. Entenderás más al respecto Up next. 46. 0502 Realiza la revuelta en conflictos de código VS y manejo: De acuerdo, echemos un vistazo a un ejemplo de git rebase. Pero antes de eso, déjame que te acompañe por el estado actual de nuestro proyecto. En realidad he creado un proyecto completamente nuevo para este propósito y he hecho un montón de commits. Deja que te acompañe a través de lo que exactamente he hecho. Desde la rama maestra como parte del primer commit, acabo de introducir estos archivos TXT, inventario de administración y archivos TXT de punto de producto. Y en cada uno de esos archivos, acabo de agregar un par de líneas de texto como si hubiéramos escrito algún código. El siguiente commit también fue dentro del maestro. Y antes de eso, por supuesto que he creado una rama que se basa en el primer commit. Como parte del segundo commit, como nos sugiere el mensaje, admin Edits y master. Acabo de agregar una línea de texto dentro del archivo admin dot TXT, así. Y luego hice mi primer commit en la rama de características y hace el mensaje sugiere ediciones de inventario de la característica una rama. Acabo de agregar una línea de texto dentro del archivo inventado o TXT. La próxima vez hizo commit en rama maestra. Y esta vez he añadido una línea de texto en el archivo TXT de punto de producto. Y luego hice un comentario más en la rama de funciones donde he editado el archivo TXT de punto de producto. Al final de la línea. Cuando realicemos la rebase, vamos a tener conflictos en archivo TXT de punto de producto porque tenemos un commit hecho en master donde hemos editado product dot TXT file, y lo mismo se hace en el característica rama también. La próxima vez hizo una rama maestra más comprometida. Bueno, esto no me hace falta realmente para explicar esto, pero he hecho este comentario solo para que la gráfica se vea como queremos. Básicamente actualmente esta línea azul representa la rama maestra, mientras que la línea roja representa la rama de entidad. No obstante, este puede no ser el caso siempre. Cualquiera que sea la rama que hagamos el último commit que se mostraría primero. Por ejemplo, si tuviera que hacer una rama de características de comentario más, rama de características se pondría azul y la rama maestra se volvería roja. Podría parecer confuso. Y es por eso que he añadido este commit adicional para que la rama maestra se muestre primero y luego la rama de características. Ahora antes de seguir adelante, es realmente importante que entiendas qué está pasando exactamente y cuáles son todos los cambios que hemos introducido en cada uno de estos commits. Por lo que voy a poner a disposición este proyecto para que lo descargues. Simplemente puedes importarlo al código de Visual Studio y echar un vistazo a toda la lista de cambios, entenderlo, y sólo entonces proceder. De lo contrario, comenzarás a confundirte. Si eres capaz de seguirte, eso es genial. Si no lo estás, entonces haz una pausa, entiende lo que está pasando aquí, y luego sigue viendo. Por lo tanto, como puede ver, la característica una rama se basa actualmente fuera de la primera confirmación en rama maestra. Ahora queremos rebasar la característica una rama a la última rama de commit off master. ¿ Cómo hacemos eso? Bueno, hagamos clic derecho en el último commit, la rama maestra. Y luego tenemos esta opción llamada rebase branch current on this commit. La rama actual es rama maestra. Cuándo cambiar a rama de función. Y sabemos que hemos empujado a con una rama porque este círculo aquí mismo está apuntando a contar una rama antes estaba apuntando a rama maestra. Ahora hagamos clic derecho en la última rama de commit off master y escojamos esta opción que dice rebasar rama actual. En esto, las ramas actuales cuentan con una rama. Y esto idealmente debería rebasar a menos que tengamos conflictos. Por supuesto, vamos a ver conflictos porque como he mencionado antes, hemos editado product dot archivo TXT en ambas ramas. Entonces vamos a dar clic en rebase. Como pueden ver, tenemos conflictos. Desestimaremos esto. Bueno, idealmente deberíamos estar viendo esos archivos con complejo déjame refrescar. Y ahí lo tienes. Podrás resolver los conflictos y de la forma que quieras. En mi caso, sólo quiero aceptar los dos cambios. Guarde el archivo. Y luego voy a presionar este ícono más para escenificar este archivo. Y luego puedo hacer clic en este icono de verificación para proceder realmente con la operación de rebase. Y el mensaje que se llena por defecto aquí es el mensaje de la característica de comentarios, una rama que en realidad está creando el conflicto. Obtenemos este editor abierto. Pero sólo voy a dejar el mensaje como está, cerrar el archivo. Y esto debería terminar la operación de rebase. Como se puede ver, los primeros cuatro commits están fuera rama maestra y los otros dos comentarios pertenecen a la rama de entidades. Ahora podemos seguir adelante y realizar la Marcha de Avance Rápido. Entonces voy a cambiar de nuevo a rama maestra. Haga clic derecho en esta confirmación. Y entonces puedo elegir fusionarme en rama actual. Así que quiero fusionar característica una rama en la rama maestra. No quiero crear un nuevo commit para una fusión de avance rápido. Entonces así es como se realiza la rebase. Y si se nota, tenemos este desarrollo lineal, que es lo que estamos esperando con rebase. Nos vemos a continuación. 47. 0503 Git Rebase en Git Bash Skipping conflictos y Abortar la Rebasa: De acuerdo, veamos cómo podemos realizar git rebase desde Git Bash. Actualmente estamos en rama maestra me para cambiar a característica de una rama para poder ejecutar ese comando. Y por cierto, han devuelto el proyecto a cómo se veía al inicio de nuestro video anterior. Para que podamos rehacer las cosas y ver cómo funciona desde Git Bash. Voy a cambiar a sucursal de características. Puede observar simultáneamente lo que está sucediendo en esta gráfica. Rebase de Git. ¿ Dónde quiero rebasar para hacer un commit? Esa rama maestra está apuntando a alguien que diga Maestro. Y como se puede esperar, vamos a ver los conflictos. Sigamos adelante y los disuelvamos. En mi conjetura, una vez más, no aceptaría ambos los cambios, guardaría el archivo, y volvería a Git Bash, fui a escenificar ese archivo, git add product dot archivo TXT. Y luego necesitamos ejecutar este comando. Git rebase, guión, guión continúan realizando la rebase. Y eso lo voy a hacer. También tienes la opción de saltarte. Si ejecutas este comando, git simplemente omitirá el commit que está causando los conflictos. Es como si no hubieras hecho la rama de funciones comentadas que está causando los conflictos. Si ejecuta este comando, tal vez después de realizar con éxito la rebase, es posible que desee volver a aplicar todos esos cambios manualmente. No obstante, como hemos resuelto el complejo, no tienes que usar esta opción, pero siéntete libre de experimentar con ella. Una vez ejecuto este comando. Nuevamente, nos va a mostrar el mensaje. Podemos mantenerlo como está. O si deseas cambiarlo, puedes seguir adelante y cambiarlo. Vamos a cerrar. Y como pueden ver aquí, hemos rebasado nuestra rama de funciones con la rama maestra. Vamos ahora a seguir adelante y realizar la parte de fusión, que vamos a cambiar de nuevo a master git merge feature one. Y como puedes ver, ambas ramas están igualadas. Si un comando bone from git log ahora, vas a ver todos los commits introducidos en ambas ramas de manera lineal, que es lo que necesitamos. Y por cierto, operación de rebase bien realizada. Y por alguna razón has decidido abortarlo, entonces puedes usar esta opción, git rebase, guión, guión que compré. Nos vemos a continuación. 48. Rebase interactiva de 0504 Git: Sostenga eso, hablemos de rebase interactiva. Y para ello tengo 1 segundo trajo de vuelta el proyecto a lo que era antes. Antes de realizar la operación de rebase. Permítanme cambiar a contar con una rama y realizar la rebase. Quiero hacer clic derecho en la última commit off Master, haga clic en rebase rama actual en este comentario. Pero esta vez voy a elegir esta opción que dice rubia rebase interactiva en nueva terminal. Esto es equivalente a ejecutar el comando git rebase con dash, dash interact to option. Vamos a hacer clic en sí rebase. Y en esta ocasión abriremos el editor de texto. Aquí vas a ver lista de titulares de commits que forman parte de la característica una rama. Lo que la rebase interactiva nos permitiría hacer es que en realidad podemos realizar una gran cantidad de personalización en función de nuestras necesidades. Si ves tenemos un montón de comandos aquí, que podemos usar para decirle a git qué queremos hacer con los commits o característica de una rama. Por defecto, este comando se usa pick, lo que significa que queremos usar ese comité. Lo que eso significa esencialmente es que queremos que estos cometas de característica una rama sean candidatos para la operación de rebase. Pero puedes cambiar este comando a otra cosa en función de tu requerimiento. Por ejemplo, tal vez me gustaría usar este comando reward, que significa usar commit, pero agregó el mensaje de commit. Esencialmente, si quieres cambiar el mensaje a otra cosa, entonces puedes usar este comando. Vamos, quiero cambiar el mensaje de esta comisión en particular. Yhagámoslo. Me gustaría usar este comando drop. Dejar caer este compromiso en particular. Sé que este comentario va a crear conflictos porque editamos product dot txt file en este commit. Entonces voy a dejar caer esto. De igual forma, tienes un montón de otros comandos que puedes usar. Simplemente puedes pasar por la descripción y ver si se ajustan a tus necesidades. Guarde el archivo y ciérrelo. Entonces vamos a ver otro prompt pidiéndonos encadenar el mensaje de ese commit. Si recuerdas cuál es este commit en particular, habíamos utilizado el comando de recompensa. De ahí obtengo esto que nos lleva a encadenar el mensaje a otra cosa. Puedes cambiar esto a lo que quieras. Por supuesto, no digas bla, bla, escribe algo significativo. Quiero guardar el archivo y cerrar esto. Por lo que esta vez si te das cuenta sólo tenemos cinco commits. Porque soltamos uno de los commits en la rama de la característica donde hicimos cambios en el archivo TXT de punto del producto. Y también para la otra característica comentarista, una rama cambiaría el mensaje a bla, bla. Así que adelante y tratar de experimentar con rebase interactiva. Nosvemos a continuación. 49. 0505 Rebase para cometer específicos o con otra rama de características: En este video, vamos a echar un vistazo a cómo podemos rebasar para que un particular nos comprometa. No tenemos que necesariamente rebasar a la punta de una rama. También podemos hacer base a un compromiso en particular. Actualmente o característica una rama está basada en la primera commit de la rama maestra, pero puedo rebasarla la segunda commit off master branch. En Visual Studio Code, necesito cambiar a esa rama, que quiero rebasar. Elijo característica una sucursal. Una vez que haga eso, voy a hacer clic derecho en el commit donde me gustaría reconstruir la característica una rama dos. Y entonces puedo elegir esta opción que dice rebasar rama actual en este commit. Si tuvieras que hacer lo mismo desde el Git Bash aquí para rápido-twitch para contar con una rama. Y luego vas a decir git rebase. Y luego el hashCode del commit al que te gustaría rebasar. En este caso, va a ser el segundo commit de rama maestra. Voy a copiar los primeros caracteres de este commit, así. Vuelve a Git Bash, pega aquí. Y esto ahora debería rebasar característica una rama a este comentario. Bueno, este diagrama puede no parecer tan obvio. Pero si te das cuenta, tenemos la característica una rama, que se basa en la segunda commit off master branch. Estos dos commits que pertenecían a la rama maestra no forman parte de la característica una rama. Como era de esperar, la gráfica se vería más obvia si hacemos otro comentario en rama maestra. Entonces hagámoslo muy rápido. Voy a volver a cambiar a rama maestra. Simplemente agregaré una línea de código, archivo de producto, guardé el archivo. Volvamos aquí y cometamos estos cambios en rama maestra con el mensaje. Ahora si vuelves a la gráfica, tenemos rama maestra en azul y rama característica en rojo. Pero si notas las ramas de características ahora basadas en el segundo comentario sobre la rama maestra, porque la hemos rebasado a eso. Y no necesariamente siempre tenemos que rebasar a la rama maestra. También podemos lo mejor una rama particular a otra rama que no es una rama maestra. Déjame mostrarte lo que quiero decir. En primer lugar, creemos una nueva sucursal. Pero esta vez, en lugar de crear una sucursal en la punta de la rama maestra, voy a hacer eso en este commit en particular. Y sí, también podemos crear nuevas ramas que estén basadas en un commit en particular. Simplemente puedo hacer clic derecho en el commit desde donde me gustaría crear rama. Y luego haz clic en Crear Sucursal, ingresa el nombre de la sucursal, y estamos bien. Pero veamos cómo podemos hacer lo mismo desde Git Bash. Permítanme cambiar a master, por ejemplo, git branch, y luego el nombre de la rama que le gustaría crear. Llamémoslo característica dos. Y luego vas a especificar que surja en base a lo que te gustaría crear esta rama. Voy a copiar los primeros caracteres de este objeto commit. Vuelve a Git Bash, pega aquí. En realidad, si ejecutas este comando, realmente no tienes que cambiar a marcas maestras. Puedes ejecutarlo desde cualquier otra sucursal. Por lo que ahora tenemos una rama creada que se basa a partir de este combate en particular. Y se puede ver esa sucursal aquí. Hagamos un commit en esta rama. Para eso, permítanme cambiar a característica dos rama. Ir a tal vez un archivo de producto. El producto cambia de función a lo que sea. Guarde el archivo. Y vamos a comprometer estos cambios en la característica a la rama. Si notas, la primera línea representa la entidad a la rama, y se basa en la tercera commit de rama maestra. Entonces eso es FY21 be hash, que hemos entrado previamente. Y luego esta línea roja representa la rama maestra, verde representa la característica una rama. Si quieres que esta gráfica se vea más obvia, hagamos un commit en rama maestra. Una vez más. Comprometamos estos cambios con el mensaje. Si vuelves a la gráfica, verías que tenemos la rama maestra, rama característica de la rama de la característica una que se basa en segundo commit y la característica dos rama que se basa fuera de la tercera comentario. Ahora vamos a seguir adelante y leer mejor característica una rama a la punta de la característica a rama. Primero cambiemos a contar con una rama. Y luego voy a hacer clic derecho en este commit. Rebasar el actual ramo en este comité. Tenemos conflicto. Vamos a resolverlos rápidamente. Aceptar tanto los cambios guardados el archivo, se queda el archivo. Y luego comprometido. Esto debería abrir un editor. Sólo ciérralo. Y esto terminaría la operación de rebase. Una vez más, la gráfica puede no verse así que obviamente sí hace un comentario más. En rama maestra. Voy a volver a cambiar a rama maestra, ir al producto punto TXT y solo agregar una línea más de código. Voy a usar el mismo texto que el mensaje de commit. Y vamos a comprometernos en este momento, si se nota, la primera línea está representando a la rama maestra. Pero el punto aquí es que pudimos rebasar característica una rama en la punta de la característica a rama. Por lo que estos dos commits pertenecían al lanzador una rama que simplemente se rebasará para contar con dos ramas. Ahora si lo deseas, solo puedes seguir adelante y fusionar ambas dos ramas y eliminar una de ellas o hacer lo que sea. Si quieres hacer lo mismo desde Git Bash que simplemente volverías a tener una rama, git rebase, función dos. Y esto debería rebasar tu función en rama en la punta de la entidad a rama. Ya que ya hicimos eso, no tengo que ejecutar este comando. Pero espero que hayas conseguido el punto. Entonces adelante y experimenta con esto, juega con todo lo que acabo de discutir. Si no practicas, todo parecería países y subsecuentes, empezarías a frustrarte. Nos vemos a continuación. 50. 0506 Cuándo usar rebase y cuándo usar Fusión usecases: Así que rebase o fusione. Hablemos de ello. Imagina que este es el estado actual de tu proyecto. Ha creado una rama de función o la primera commit en rama maestra. Y luego tienes un montón de commits realizados en rama maestra después de la creación de la rama de características. Ahora digamos que por alguna razón te das cuenta de que eres demasiado pronto para crear esa sucursal. Tal vez necesitabas algunos de los cambios introducidos en rama maestra que vinieron después de que creaste la rama de funciones. ¿ Adivina qué? Usted puede simplemente rebasar la rama de la característica a un commit específico que vino después, modo que usted tendrá todos esos cambios en la rama principal, que estaría disponible en la rama de la característica. Este es un caso de uso en el que es posible que desee usar rebase sobre una fusión. Otro caso de uso fuera de rebase. Digamos que has creado par de ramas como las que estás viendo aquí. Ahora, digamos que te has dado cuenta de que estas dos ramas no se supone que estén en dos ramas diferentes. Podrían estar abordando el mismo tema o podrían pertenecer a la misma característica. Entonces tal vez te gustaría tenerlos como parte de una sola sucursal. ¿Adivina qué? Puedes simplemente rebasar una de las ramas con la otra, así, y ya estás listo para ir. Sin embargo, existen ciertos escenarios donde rebus no es la mejor opción. Rebase estás alterando y reescribiendo la buena historia. Cada vez que rebasas, estás reescribiendo los objetos Comment apuntando a un padre diferente. Ese no es el caso con mucho. Vas a conservar el historial de commit y se baja de fusionar. Y esa es una razón por la que debes evitar usar rebase. Si hay múltiples desarrolladores trabajando en una sola sucursal. Por ejemplo, imagina que tenemos un B2 más opaca y más opaca, y luego también tenemos el repositorio centralizado. Y esta es la estructura actual del proyecto. En todos estos lugares, tenemos la rama maestra con un par de comentarios y la rama de características con un solo commit. Ahora, digamos que el dólar por uno se ha rebasado en un commit diferente. No se reflejará en todo el otro sistema. Por ejemplo, todos los demás desarrolladores, e incluso en el repositorio centralizado. Ahora bien, en pocas palabras, esto va a crear muchas inconsistencias y podría como destruirá el propósito mismo de por qué tenemos rebase, que es tener una historia de commit limpia. Como regla general, solo recuerda, si eres el único que está trabajando en una rama en particular, una rama de características, Digamos que podemos usar rebase antes de empujar ese código en el repositorio centralizado. Si hay múltiples desarrolladores involucrados y todos están contribuyendo a la misma rama. Entonces fusiona opción para ti En ese caso. Nos vemos a continuación. 51. 0601 Qué es hacer en las usecases Ejemplo de cómo hacer en el Stashing: Hablemos de esconder. Permítanos actualmente estoy trabajando en cambios relacionados con la característica uno. Y por lo que actualmente estoy en la característica una rama. Ahora, mientras todavía estoy trabajando en esto, mi jefe viene a mi escritorio y me pidió que continuara trabajando en función dos y la entregue primero antes de trabajar en la característica uno, tal vez ese cliente esté ansioso esperandola característica también. Ahora, con la esperanza de un avalúo, podría decirle que sí a mi jefe y no me gustaría empezar a trabajar en el largometraje también. Pero, ¿y si tengo algunos cambios no comprometidos en la característica uno? Permítanme realmente seguir adelante y hacer algunos cambios en uno de estos archivos. Como si estuviera introduciendo algunos cambios relacionados con la característica uno. Simplemente voy a agregar una línea de texto, así, guardar el archivo y cerrarlo. Déjame volver a Git Bash. Por lo que tenemos algunos cambios introducidos para la característica uno. Y luego ahora quería trabajar en función para dejarme cambiar a característica a rama. Por lo que actualmente estoy en función a sucursal. Ahora bien, si abro este archivo admin dot TXT, ¿ estarías viendo los cambios que acabo de introducir? Echemos un vistazo. Todavía ves estos cambios. Eso porque entre ramas lleva contigo todos esos cambios no comprometidos. Estos son los cambios que están relacionados con la característica uno. Y lo puedo ver incluso después de cambiar a la función dos. Ahora, ¿por qué es esto un problema? Bueno, cuando estás trabajando en función de cambios relacionados, esto podría crear realmente mucha confusión, especialmente cuando estás tratando de poner en escena todos esos archivos relacionados con la característica dos. Es posible que te encuentres con cambios relacionados con la característica uno y podrías terminar confundiéndote. Entonces, ¿cuál es la solución aquí? Una solución es obviamente cometer cambios relacionados con la característica uno antes de cambiar a la característica de dos ramas. Pero esa no es una solución porque tampoco hemos terminado con la característica uno cambia. Bueno, ¿qué tal si tenemos la característica que nos permite almacenar temporalmente todos nuestros cambios no comprometidos en algún lugar del repositorio? Y entonces podríamos recuperarlos cuando queramos. Eso es exactamente lo que se esconde en Git. Actualmente estoy en futuro una sucursal. Así que antes de cambiar a función dos y empezar a trabajar en ella, me gustaría esconder todos nuestros cambios no comprometidos. El mando para eso es bueno. Alijo. Ahora, este comando sólo guardará los archivos rastreados por defecto. Para hacer un archivo rastreado por Git. Como ya sabrías, necesitamos escenificarlo al menos una vez. Entonces, si tenemos un archivo completamente nuevo que nunca fue escenificado antes, entonces no podemos esconderlo. Si también quieres esconder todos esos archivos sin seguimiento, entonces Inuit incluye una opción. Incluir guión sin seguimiento. Necesidad de ejecutar este comando con esta opción para que tanto los cambios en escena como yo estoy escenificado, incluso los nuevos archivos que nunca son tracto antes, serían guardados. Alternativamente, la taquigrafía de esta opción es simplemente usar guión nuevo. Actualmente no tenemos ningún archivo que esté sin seguimiento de todos modos. Por lo que vemos un mensaje que dice Guardado directorio de trabajo y fecha de índice. Wip es sinónimo de progreso de trabajo en una rama característica. Y está apuntando a la última confirmación de la característica una rama, lo que significa que este comando ha guardado cambios que vinieron después de la última confirmación, esa rama. Ahora si abres el archivo admin dot TXT, ya no verías todos esos cambios porque esos simplemente estaban guardados. Ahora somos libres de cambiar a contar con dos sucursales. Y aquí trabajo en función a cambios relacionados o hacer montón de commits. Y una vez que haya terminado con ello, puedo volver de nuevo a presentar uno. Y puedo recuperar todos esos cambios guardados con el comando git stash, pop. Ejecutemos este comando. El buen comando pop. Después de recuperar nuevo todos esos cambios no comprometidos, eliminará esos cambios del almacén temporal. Pero detrás de las escenas, esencialmente ha creado un objeto commit, y este es el hashCode fuera de él. Y este objeto commit no formará parte de ninguna rama. History, es solo un objeto commit temporal creado junto con él snapshot solo con el propósito de esconder. Y como se puede ver por esta línea, este objeto commit ha sido caído. Si abres admin dot TXT ahora, puedes volver a ver todos esos cambios que antes estaban guardados. Hay otro montón de casos de uso donde se guarda podría ser útil. Los exportaremos en nuestras próximas conferencias. Nosvemos a continuación. 52. 0602 Aplicar el contenedor en varias ramas: Puede llegar un momento o un caso de uso en el que es posible que deba aplicar los mismos cambios en múltiples ramas. En cuyo caso git stash pop no sirve al propósito. Cuándo usar git stash, solicita lo mismo. Déjame mostrarte lo que quiero decir. Actualmente estoy en una rama futura y tenemos ciertos cambios no comprometidos. Permítanme volver a Git Bash y guardar todos esos cambios no comprometidos. Entonces tomamos un respaldo de la misma y ya no veríamos estos cambios. Ahora hagamos git, stash, aplíquense. Y vamos a ver qué va a hacer. Una vez más, el bien ha traído de vuelta todos esos cambios no comprometidos de la tienda temporal. Pero esta vez no eliminó todos esos cambios de la tienda temporal como lo hizo en gas off git stash pop. Lo que significa que también podemos aplicar esos cambios en otra rama. Pero antes de eso, permítanme cometer todos estos cambios. Digamos que he terminado con todos los cambios relacionados con la característica uno. Etapa esos archivos primero, y luego cometer los cambios. Permítanme ahora cambiar a característica dos rama git stash. Ahora puedo ejecutar el comando apply para aplicar todos esos cambios almacenados. Una vez más, actualmente no tenemos todos esos cambios en el futuro a sucursal. Pero una vez después de ejecutar este comando, ustedes van a ver esos cambios aquí. 53. 0603 Cómo recuperar un stash listing específico stashes Manejo de conflictos: Veamos cómo podemos echar un vistazo a la lista alijos y ser capaces de recuperar un alijo específico? Sí, es posible. Déjame mostrarte lo que quiero decir. Para explicarlo mejor, he vuelto a traer el proyecto a lo que era al inicio de este capítulo. Entonces básicamente no tenemos alijos en absoluto. Estoy en característica una rama. Déjame seguir adelante y editar uno de los archivos. Permítanme simplemente agregar una línea de texto, así, guardar el archivo, cerrarlo, volver a Git Bash y vamos a guardar esos cambios. Vuelve atrás y abre el archivo. Ya no verían todos esos cambios porque esos simplemente estaban guardados. Déjame agregar una línea más de texto, así, guardó el archivo, ciérralo. Déjame guardar también estos cambios. Ahora, hemos hecho de guardar un par de veces, y esto debe haber sido mantenido en algún lugar del repositorio. ¿ Cómo le echamos un vistazo? El comando para eso es git stash list. Esto enumeraría en toda la lista de alijos. Podemos recuperar un alijo específico usando su ID. Pero si se nota, el mensaje que está aquí no son muy descriptivos. Este es solo el último commit en la característica una rama y la misma que se usa para todos los alijos. Ahora, con el tiempo, a medida que sus alijos se incrementan, podría ser difícil identificar ¿ tiene el alijo qué cambios? Afortunadamente, git nos permite dar un mensaje descriptivo mientras estamos guardando. Entonces déjame editar otro archivo. Tal vez inventado o TXT así. Y voy a hacer lo mismo para archivo de producto también. Guárdalo y ciérralo. Por lo que acabo de hacer ediciones y par de archivos. Déjame guardar esos cambios, pero esta vez voy a dar un mensaje descriptivo. Guardar es la opción que necesitamos usar y vas a proporcionar algún mensaje, algo así. Nuestros cambios están guardados. Para echar un vistazo a la lista de alijos. Ahora, vas a ver un mensaje descriptivo. Ahora déjame intentar recuperar este alijo en particular. Una vez más, podemos o pop se aplican los cambios, los cambios. Déjame aplicar los cambios. Quería precisar la idea del alijo como celular. Se pueden ver los cambios que se recuperaron y se aplican. Del mismo modo, también podemos recuperar este alijo en particular. Y vamos a ver esos cambios en el archivo admin dot TXT. Pero veamos qué pasaría si recuperara este alijo en particular donde hemos editado exactamente el mismo archivo. Esta operación, realmente debería fallar. Y claro, tenemos una flecha que dice que tus cambios locales a los siguientes archivos serían sobrescritos por fusión. Por favor, comete tus cambios se los guardan antes de fusionarte. Así que básicamente este Stash va a reaccionar a los cambios que podrían entrar en conflicto con nuestros cambios no comprometidos existentes. Entonces, ¿para qué es la solución? Aquí ya se proporciona la solución. Podemos cometer todos estos cambios o guardarlos una vez más y luego recuperar este alijo en particular. O alternativamente, podemos simplemente usar el comando git restore dot para simplemente borrar todos los cambios no comprometidos. Y de esa manera deberíamos poder recuperar un alijo específico sin ningún problema. Pero entonces también hemos perdido todos los cambios. En realidad vamos a hablar de cómo podemos manejar los conflictos mientras guardamos. Cuando hablamos de git pull en capítulos posteriores. Nosvemos a continuación. 54. 0604 Cómo ocultar los cambios selectivos y recuperarlos: No es necesario que tengamos que guardar todos los cambios. También podemos ser seleccionados para pedir regar todos los cambios que queremos guardar y cambios que no queremos guardar. Y una vez más, por el bien de este ejemplo, he vuelto a traer el proyecto a lo que era al inicio de este capítulo. Por lo que no tenemos ningún alijo por el momento. Déjame editar par de archivos. Así. Guardé el archivo. Pero esta vez, vamos a guardar cambios parciales. Esta vez voy a usar la opción guión P significa parcial. Y veamos qué nos permite hacer. Nos ha proporcionado montón de opciones. Si no sabes de qué se trata estas opciones, solo puedes escribir el signo de interrogación y podrás ver una descripción del mismo. Entonces básicamente este comando te avisaría todos los cambios que hemos hecho uno por uno. Y podemos decir qué hacer con esos cambios basados en esta lista de opciones. Por lo que actualmente está apuntando a este cambio en particular perteneciente al archivo TXT de punto de inventario. Si escribimos y, se va a guardar el guapo. Se puede pensar en hunk como un cambio que se está presentando aquí. Entonces esta es una nueva línea de textos que acabaría de agregar. Si escribes N, Eso significa que no quieres incluirlo como parte de alijo. Significa que no quieres guardar estos cambios. Q como en quipped, no guardes este manojo ni ninguno de los restantes. Pero cuáles son todos los pedazos que podrías haber dicho que sí a lo que aún se guardaba al dejar de fumar. Esencialmente, vamos a salir de esta operación mientras también guardamos todos los cambios a los que dijimos que sí a aquí significaría guardar este manojo y todos los pedazos posteriores en el archivo. En el mismo expediente. D significaría que no están guardados este guapo ni ninguno de los más tardíos en el archivo, es opuesto a la opción a. él significaría editar manualmente el trocito actual. Esto es algo que nunca usaríamos. Personalmente nunca lo he usado. No pienso en un caso de uso para usar esto. Básicamente, si queremos editar algo, preferiríamos hacerlo caminando por un árbol y luego guardar los cambios. Entonces digamos que me gustaría guardar estos cambios. Entonces voy a decir y aquí. Entonces nos va a avisar con el segundo trocito, que pertenece al archivo TXT de punto de producto. Y estos son los cambios. Digamos que no quiero guardar a alguien que diga n a esto. Hagamos git restore dot para simplemente limpiar nuestro directorio de trabajo. Llamémoslo con este comando. Estamos borrando todos esos cambios no comprometidos. Déjame tratar de volver a aplicar ese alijo. Este comando solo aplicaría el último alijo que tenemos en la lista. Pero antes de ejecutar ese comando, Asegurémonos de que nuestros cambios se pierdan. Como puedes ver, nuestros cambios no están ahí. Pero una vez después de ejecutar este comando, vamos a ver los cambios aplicados en el archivo TXT de punto de inventario. Porque este guapo estaba guardado. Donde hace en el producto dot archivo TXT, no vemos ningún cambio. Nos vemos a continuación. 55. 0605 Explorar escondites en VS Code Eliminando un escondite: Ahora echemos un vistazo a cómo podemos realizar el stashing Visual Studio Code. Y una vez más, para ello, devolví el proyecto a lo que era al inicio de este capítulo. Y actualmente no tenemos alijos de ningún tipo. Sigamos adelante y hagamos ediciones en par de estos archivos. Puede agregar una línea de texto como así un archivo admin dot TXT. Y déjame hacer lo mismo en inventario punto archivo TXT , guardado el archivo. Vamos a Control de Fuentes. Da clic en estos tres puntos y verás la opción de realizar alijo. Entonces aquí encuentras una rutina que hemos aprendido hasta ahora en este capítulo. Podemos realizar Stash. Stash, que también incluye archivos sin seguimiento. Podemos aplicar alijo más reciente. Esto es tan bueno como estamos ejecutando el comando git stash apply. O podemos elegir esta opción que dice aplicar alijo. Y luego llegamos a elegir el de los alijos guardados. Sigamos adelante y realicemos el stashing. Nos está pidiendo que ingresemos un mensaje, dejemos Centro o algo así, pulsa Enter. Por lo que esto debe haber guardado cómo cambia. 1 segundo, Vamos al alijo. Podemos dar clic en Aplicar alijo de letras, o podemos elegir esta opción que dice un alijo más. Y luego llegamos a elegir el alijo que nos gustaría aplicar. Actualmente, solo tenemos un alijo y decimos que se está exhibiendo. Si tuviéramos lista de alijos, esos también se mostrarían. Déjame dar clic en esto. Y como se puede ver, los cambios por ahora aplicados en ambos estos archivos. A ver qué otras opciones tenemos. También tenemos la opción de hacer pop el último alijo, pop un alijo específico. O incluso podemos dejar caer este guión o soltar todos los alijos. Esencialmente caer significaría borrar un alijo. Esto es similar a ejecutar el comando git stash drop. Y luego vas a especificar este ID de guión. O simplemente puedes decir git stash, claro. Y esto eliminaría todos los alijos. Podemos hacerlo desde aquí o también podemos ejecutar el comando. Déjame ejecutar el comando. Ahora. Si hago git stash list, no vas a ver nada porque acabamos de borrar todo. Pero así es como se usa el stashing en Visual Studio Code. Nosvemos a continuación. 56. 0701 Git Ignore y es significado (curso de choque): Hablemos del gitignore y su significación. Puede haber cierto conjunto de archivos que no quieres comprometer o no quieres que estén disponibles para que otros los descarguen y usen. Algunos de los ejemplos de este tipo de archivos son los siguientes. Podríamos tener archivos de registro que se generan durante el tiempo de ejecución. Y obviamente no queremos comprometerlos y ponerlos a disposición en repositorio centralizado para que disposición en repositorio centralizado otros los descarguen. Del mismo modo, podríamos haber compilado código como archivos de clase punto o punto p-y, archivos C, etc. O podría tener carpetas de dependencia local como módulos Node en caso de proyectos de nodos fuera. Pero podemos ignorar estos archivos simplemente no escenificándolos y no comprometiéndolos. Pero podría haber casos en los que las personas tienden a cometer accidentalmente algunos de estos archivos, creando así un lío que no se pretende. Por lo que el archivo gitignore viene muy bien allí. El archivo Gilignore te permitirá especificar ciertos patrones. Y todos los archivos y carpetas que coincidan con esos patrones serían ignorados para la puesta en escena de acomodación. Si intentas quedarte como los archivos que coinciden con estos patrones especificados en dot ignore file, verás un error. Echemos un vistazo a un par de ejemplos de tales patrones. Cuando dices star dot log, por ejemplo, star se considera un carácter comodín. Eso significa que puedes tener cualquier archivo en tu repositorio o en tu proyecto con cualquier nombre. Siempre y cuando tenga extensión dot log, esos archivos serían ignorados. Por lo que aquí están algunos de los ejemplos de archivos que serían ignorados cuando se tiene este patrón especificado en el archivo ignore duda. Hemos agregado dot log en el directorio raíz y luego info dot log bajo la carpeta logs. Ambos archivos serían ignorados. Echemos un vistazo a un ejemplo más de un patrón. Tenemos pulmones slash. Cuando se especifica una barra, eso significaría un directorio. Este patrón ignoraría esencialmente todos los contenidos, incluidos los subdirectorios de todas las carpetas con los registros de nombres. Y aquí algunos de los ejemplos de archivos que serían ignorados con ese patrón. Pausa el video, tómate un segundo y trata de entender esto. Todos estos archivos pertenecen al directorio Logs. Y así todos estos archivos serían ignorados. No podemos escenificarlos, y así ni siquiera podemos acercarnos a ellos. Digamos que tienes esta estructura de proyecto. Típicamente tendemos a tener un archivo de ignorar un punto y eso iría dentro del directorio raíz del proyecto. Sin embargo, no impide que tengas archivos dot ignore también en los subdirectorios. El archivo dot ignore y sus patrones se aplica en la carpeta donde reside, incluyendo sus subcarpetas. Por lo que todos los patrones en el archivo de punto ignoran que reside en la carpeta sub uno solo son aplicables en la carpeta sub una. Y todos sus subdirectorios, incluyendo todos los archivos. Pero no es aplicable en su carpeta padre, que en este caso es mi carpeta de aplicaciones. Podría haber instancias en las que podrías tener conflictos de patrones. Por ejemplo, podríamos estar teniendo un patrón que podría estar en conflicto en estos dos archivos de ignorar puntos. En cuyo caso los patrones de carpeta sub one tendrán mayor precedencia sobre los patrones en mi carpeta de aplicaciones. continuación vamos a echar un vistazo a un ejemplo de esto. Y con ello tendrás mejor claridad. Si tiene algún patrón que no sea aplicable para todo el equipo, pero que solo sea aplicable en su inscripción local. Se puede mencionar la parte masiva del archivo de exclusión. Y el hecho de que este archivo pertenezca a carpeta dot git significa que esto no se puede empeorar o no se pueden cometer estos cambios. Y para todos los patrones que son aplicables para todo el equipo, eso es un archivo de ignorar punto entraría en imagen y está versionado, lo que significa que una vez que haces una actualización en dot ignore file, los comprometerías y, en realidad, empujarías todos esos cambios al repositorio centralizado para que todos los demás descargaran el archivo Dart ignore. Y todos los patrones de archivo en ese archivo serían ignorados para todos. Por lo que nadie sería capaz de comprometer todos esos archivos que no están destinados a ser compartidos en todo el equipo. También puede especificar patrones globales que son aplicables en todos los proyectos son repositorios en su inscripción local. Eso lo puedes hacer ejecutando este comando que estás viendo aquí. Esto esencialmente agregaría una configuración adicional en el archivo de configuración de Git que reside en el directorio del usuario. Nos vemos a continuación. 57. 0702 Git Ignore en acción: Digamos que git ignora una acción. Lo que tenemos aquí es nuestra buena antigua de mi aplicación con montón de archivos y tal vez con montón de commits también. Olvídate de todos los commits que hicimos y simplemente no te importan los archivos que contiene. Vamos a mantenernos enfocados en gitignore. Ahora imagina que he descargado este proyecto del repositorio centralizado e incluso lanzar la aplicación. Cuando hago eso, podría terminar viendo que en los archivos de registro se generan automáticamente por la aplicación. Ahora como no tenemos la aplicación en ejecución, vamos a simular el comportamiento creando manualmente los archivos de registro. Permítanme crear tal vez cualquiera de los dos archivos de registro de puntos. Aquí se ha considerado que este archivo es en realidad la forma de crearlo por la aplicación. También puede crear una carpeta con el nombre info donde podríamos tener en los registros. Así que permítanme crear un archivo con el nombre en para el registro de puntos. Así. Ahora si lanzo Git Bash, en realidad puedo escenificar estos archivos. Git agrega registro de puntos. Como pueden ver, estoy en condiciones de escenificar este expediente, que no es algo que yo quiera hacer. Así que déjenme subir rápidamente al escenario este archivo. Ahora, ¿cómo me prevengo de poner en escena accidentalmente estos archivos de registro? Bueno, una solución es ir dentro de la carpeta dot git info. Y luego tenemos este archivo de exclusión donde puedes especificar los patrones que quieres que ignore. Por lo que podríamos especificar un patrón star dot log, y de esa manera no podemos escenificarlos ni comprometerlos. Pero esta vez no queremos usar este archivo. ¿ Se puede adivinar por qué? Porqueestos archivos de registro no es algo que sea local a mi inscripción. Es aplicable para todos los miembros del equipo en el equipo. Cualquiera en mi equipo que descargue este proyecto y ejecute la aplicación, allí podrá ver estos archivos de registro. Tampoco quiero que ellos puedan comprometer estos archivos y repositorio centralizado. Bueno, ahí es donde entra en escena gitignore. Entonces déjame crear archivo dot gitignore, dot git. Ignorar. Asegúrate de obtener el nombre correcto. Abramos ese archivo y agreguemos este registro de puntos estrella patrón. Por lo que esto debería ignorar todos los archivos de registro en nuestro proyecto. Ahora si vuelvo a Git Bash y trato de poner en escena este archivo, en realidad va a ver un error que dice que las siguientes partes son ignoradas por uno de tus archivos dot ignore. Si todavía quiero agregar este archivo de todos modos, entonces puedo usar esta opción guión F a cuatro etapas este archivo, que estaba destinado a ser ignorado. Pero no quieres hacer esto a menos que sepas lo que estás haciendo. Ni siquiera podemos escenificar para el registro de puntos que está dentro de la carpeta info. Obtenemos el mismo error. Y si tienes algún archivo que quieras ignorar y quieres todos esos patrones sean aplicables en todos los repositorios de tu máquina local. A continuación, desea especificar el archivo de exclusión global con el comando git config global. Y luego vas a decir core excluyen archivo. Y aquí proporcionarías la ruta, el archivo de punto ignore. Una vez que ejecutes este comando, se actualizaría el archivo de config global de Git. Eso está dentro del directorio de tu usuario. En realidad te llevo ahí. Por lo que actualmente solo tiene las credenciales globales que quiero usar para todos los repositorios en mi inscripción local. Pero una vez después de ejecutar este comando, vas a ver esta propiedad en particular consiguiendo poblada en este archivo. Cualquiera que sea que ignoren el archivo al que esté apuntando, sus patrones serían aplicables para todos los repositorios en su máquina local. En términos generales, desea especificar los patrones que son relevantes para los archivos del sistema operativo como dot, DS, store, et, y no los archivos relacionados con el proyecto. Ya que no tenemos nada, solo quiero no ejecutarlo. Una vez después de crear o actualizar el archivo de ignorar Git de punto, desea confirmar esos cambios e incluso empujar sus cambios al repositorio centralizado para que todos esos patrones sean aplicables para todas las personas de tu equipo. Vamos a hablar de cómo puedes empujar tus commits locales al repositorio remoto en capítulos posteriores. Pero por ahora puedo seguir adelante y venir en el archivo gitignore. Git add, git, ignore status, git commit, guiones, lo que sea. Y somos capaces de cometer este cambio. Nos vemos a continuación. 58. 0703 orden de precedencia que se priman en la depuración de patrones: Hablemos de precedentes. Digamos que tenemos un archivo gitignore punto más en uno de los subdirectorios. Permítanme realmente copiar este archivo en el directorio info así. Pero en lugar de este patrón, quiero tener este patrón. O este patrón significa es que queremos ignorar todos los archivos que no tiene extensión de registro de puntos. Ahora si te das cuenta tenemos un conflicto en los patrones. En el directorio raíz. Tenemos un patrón que dice que queremos ignorar todos los archivos log de puntos. Pero mientras que aquí con este patrón, estamos diciendo que queremos ignorar todos los archivos. Ese no es un archivo log de puntos. Qué patrón debe obtener sigue. Ahí es donde entrarán en escena los precedentes. En este caso, se preferiría este patrón sobre el del directorio padre. La forma en que funciona es cuando tienes un archivo como info dot log in, comprobará si hay algún archivo dot gitignore en el mismo directorio donde reside ese archivo. Si los hay, entonces intentará encontrar patrones, una coincidencia con ese archivo. Si no hay patrones que coincidan con ese archivo, entonces buscará patrones en el directorio padre. Si todavía no encuentra allí, entonces intentará encontrar los patrones dentro del archivo de exclusión. Si no encuentra patrones por ahí también que coincidan con el archivo en particular. Después irá adentro y comprobará el archivo global ignore. Si lo hubiéramos configurado. Si no encuentra en ningún lugar, entonces nos permitirá escenificar ese expediente. Así caminaría el precedente. Ahora si voy a Git Bash, A ver si podemos escenificar el info dot log. Podemos, como puedes ver, efectivamente somos capaces de escenificar info dot log porque el patrón en esa carpeta, ventas que queremos incluir este archivo y no queremos ignorarlo. Sin embargo, en la mayoría de los casos normalmente en casi todos los proyectos, solo tendrías un archivo de punto gitignore y eso va dentro del directorio raíz. Pero estoy compartiendo esto sólo para su información. También debo mencionar que no estamos restringidos a un par de patrones. Tenemos montón de patrones los cuales podemos usar dependiendo de cuáles son todos los archivos que quieras ignorar. En la mayoría de los casos, normalmente sería esto. O podrías terminar especificando una carpeta como esa. Todos los patrones se pueden consultar a la documentación oficial. No hay muchos. Puede simplemente tener una mirada rápida y obtener una sensación de peso como patrones que son compatibles. No tiene sentido para mí guiarte a través de todos y cada uno de los patrones y ocupar todo tu tiempo. Solo consulta la documentación y tiene todas las cosas que necesitas. A veces podrías tener tantos archivos ignorados. Eso hace que sea difícil entender por qué se está ignorando un archivo en particular. En cuyo caso tenemos un comando a mano. Tú dijiste Get, chequea. opción Ignorar con guión v significa verboso. Y luego vas a especificar el nombre del archivo. Por ejemplo, Error dot loc. Y esto se va a imprimir por qué se está ignorando este archivo. Como puedes ver, tenemos archivo dot ignore en el directorio raíz. Y este patrón está coincidente con este archivo. Y por eso se está ignorando. Esto podría ser útil, especialmente si tienes varios archivos de ignorar o no estás seguro de por qué se está ignorando un archivo en particular. 59. 0704 ignora archivos que ya se habían comprometido: ¿ Y si ya hubiéramos comprometido los cambios se supone que se ignorarían? Déjame mostrarte lo que quiero decir. Para ello. Una vez más, he traído de vuelta el proyecto a lo que era al inicio de este capítulo. Volvemos a tener estos tres expedientes y partiremos de ahí. Déjame seguir adelante y crear un archivo de registro. Llamémoslo log de puntos de error. Permítanme realmente seguir adelante y cometer este archivo de registro. Como si estuviera cometiendo este archivo accidentalmente, junto con un montón de otros cambios. Git agrega error dot log, git, commit Typhon, algún mensaje, y hemos comprometido el archivo log. Ahora imagina que nuestro proyecto es muy nuevo, Nuestro equipo es muy nuevo. Nadie está familiarizado con el archivo dot ignore. Y así digamos que tenemos un montón de archivos en el repositorio, están en el repositorio centralizado comprometido por un montón de gente se supone que se ignora. Ahora es en este punto en el tiempo me he dado cuenta de que necesitaba tener el archivo dot gitignore en mi directorio raíz. Entonces voy a incluirlo dot Git, ignora. Voy a especificar un montón de patrones, que quería ignorar. En mi caso, simplemente voy a decir star dot along. Así. Permítanme cambiar el nombre de este archivo correctamente. Se supone que es bueno. Ignorar así. Ahora ya es demasiado tarde porque ya hemos comprometido todos los archivos que no se supone que se conviertan en ello. Permítanme en realidad venir a este archivo también. Git add, git, commit Typhon am introduciendo ignore file. Ahora he presentado este archivo, que es genial. Y esto ahora ignorará todos los archivos que se supone deben ser ignorados. Pero, ¿qué tal todos los archivos que ya estaban comprometidos? ¿ Cómo nos deshacemos de ellos? Bueno, una solución simple es simplemente identificar todos esos archivos, eliminarlos, y luego hacer un commit. Todos esos archivos serán eliminados. Y a partir de ahora tenemos el archivo dot gitignore, cualquier forma de evitar que eso suceda. Pero prácticamente hablando, si tienes muchos archivos, se vuelve realmente poco práctico identificar todos los archivos de los que querías deshacerte. ¿ Tenemos una mejor solución? La respuesta es sí. Tenemos un trabajo astuto alrededor para resolver este problema de manera más efectiva. Déjame mostrarte lo que quiero decir. Voy a volver a Git Bash. Déjame despejar la pantalla. Déjame hacer git status para asegurarme de que todo esté limpio. Ahora déjame ejecutar el comando. Git RM, guión r significa recursivo. Y luego voy a usar la opción cacheada, seguida de un punto. ¿ Qué estoy tratando de hacer aquí? En realidad estoy tratando de eliminar todos los archivos en caché. Ahora, archivos en caché de agua, podrías preguntarme, bueno, los archivos en caché son esencialmente los archivos que están siendo rastreados por Git. Git almacena todos los archivos que quiere rastrear en un caché. Y con este comando, los estamos limpiando. Esto da la impresión de conseguir que en realidad hemos eliminado todos los archivos sin tener que eliminar realmente del directorio de trabajo. Ejecutemos este comando y veamos qué pasa. Y como puedes ver, ha eliminado todos estos archivos de la caché. Así que esto incluye literalmente todos los archivos en nuestro directorio de trabajo. Como pueden ver, aquí tenemos cinco expedientes. Y aquí tenemos cinco expedientes. A continuación, lo que vamos a hacer es que en realidad vamos a escenificar todos los archivos detectando lo que va a pasar. Pero antes de eso, déjame ejecutar el comando git status una vez más. Y esta vez si notas bajo la sección de cambios para ser comprometido, se ha enumerado todos esos cinco archivos. Eso es porque nos hacen pensar que en realidad hemos eliminado todos esos archivos. A pesar de que no los hemos eliminado del directorio de trabajo. Simplemente borramos la caché e hicimos buena creencia de que realidad hemos eliminado esos archivos al mismo tiempo. En la sección Archivos sin seguimiento se han enumerado todos los archivos que actualmente no están siendo rastreados. Ahora, sí toma nota. Esta lista no incluye el registro de puntos de error porque ahora forma parte del patrón dentro del archivo dot gitignore. Git no quiere rastrearlo. Ahora sigamos adelante y agreguemos todos estos archivos sin seguimiento y hagámoslos rastreados por Git. Git agrega este término. Voy a usar carácter de punto que incluso los archivos que comiencen con punto se agregarían y sean rastreados por Git. Ahora si hago git status, verás que error dot log es el único archivo en el que necesitamos entrar. Esto es como si hubiéramos eliminado este archivo y haciendo un comentario. Esencialmente con esto, somos capaces eliminar todos los archivos que no se supone que deben ser confirmados son los archivos que se supone que deben ser ignorados. Ahora ya que tenemos esta pila puesta en escena para ser eliminada, hay una última cosa que tenemos que hacer es comprometer los cambios. Limpieza ignorado cinco, Es como celular. Y get se ha eliminado en un registro de puntos. Simplemente significaría que la nueva instantánea ya no tiene este archivo. Pero claro que todavía lo tenemos en el directorio de trabajo. Así que esto es sólo un trabajo furtivo alrededor para deshacerse de todos los archivos que habíamos comentado previamente que se supone que deben ser ignorados. Ahora si aún no estás claro, tómate tu tiempo y experimenta con estos comandos y los entenderás. Nos vemos a continuación. 60. 0705 Generar los archivos ignores para tu proyecto: Si estás introduciendo el archivo dot gitignore en tu proyecto, realmente no tienes que hacer una lluvia de ideas qué patrones quieres mantener en ese archivo. Simplemente puedes usar una de las herramientas existentes con un generador de git ignore de búsqueda rápida de Google. Me topé con este enlace. Se detuvo al.com. Podrías estar viendo algún otro sitio web, pero hacen el mismo trabajo de generar patrones para ti dependiendo del tipo de proyecto que estés construyendo. Por ejemplo, digamos que estoy construyendo una aplicación para Android. Por lo que simplemente estoy tecleando Android y dar clic en Crear. Y me ha proporcionado lista de patrones que puedo agregar como parte de mis proyectos archivo dot gitignore. Ya estamos familiarizados con la mayoría de estos patrones. Todas las líneas con hash significarían comentarios. Aquí estamos tratando de ignorar el directorio del DOD Gradle. Aquí estamos tratando de ignorar el directorio build. Por lo que todo el contenido de la misma, todos los archivos así como los subdirectorios serían ignorados para la puesta en escena. Aquí estamos tratando de ignorar el archivo local de propiedades de puntos. Star dot log significaría que queremos ignorar todos los archivos de registro. Y ya vimos un ejemplo de lo mismo. Del mismo modo, tenemos un montón de otros patrones. Vamos a tratar de escribir en Nodo. Y vamos a ver qué va a generar. Una vez más, tenemos montón de patrones que es posible que desee agregar un nuevo nodo JS proyecto tiene una asignación. Simplemente copie uno de estos archivos e intente experimentar con estos patrones y vea cuáles son todos los archivos que se están ignorando y motor todos los archivos que no se ignoran. Nos vemos a continuación. 61. 0801 por qué GitHub GitHub vs Bit Bucket vs GitLab: De acuerdo, ahora es el momento de hablar de GitHub. Como que ya tocamos esto al inicio del curso. Pero tratemos de reiterar y tratar de entender la necesidad de tener un servicio de alojamiento de código centralizado como GitHub. Si eres el único que está trabajando en el proyecto, entonces no necesitas algo como GitHub. Simplemente puedes salirte con la tuya que se instala localmente para administrar las versiones de tu proyecto. Sin embargo, a medida que su proyecto crece en tamaño, es posible que desee contratar a personas adicionales que puedan contribuir a su proyecto. Aunque solo una o dos personas, entonces puedes administrar fácilmente sin tener que usar un servicio como GitHub. Decenas y cientos de empleados que podrían querer contribuir a tu proyecto, entonces seguramente necesitas una mejor manera de administrar tu código y su historial de versiones. Y ahí es donde GitHub entraría en escena. Y GitHub actúa como un repositorio de código centralizado donde todos contribuirían con su código. Esencialmente, hacen un montón de commits en su Git local y luego suben o empujan todos esos cambios al repositorio centralizado. Y entonces todos los demás podrían descargar todos los cambios introducidos por otros miembros del equipo. Digamos que todo el mundo esencialmente tendría una copia de todo el proyecto en la computadora local. Así como también tenemos una copia del proyecto en el repositorio centralizado como GitHub junto con su historial de versiones. Y eso es lo que obtengo se llama sistema de control de versiones distribuidas. Sin embargo, get no se trata solo de poder alojar tu código o mantener el historial de versiones. Ofrece muchas otras características que son bastante útiles para una organización. Por ejemplo, poder administrar a los miembros del equipo en cuanto a quién puede hacer qué. Están siendo capaces de revisar los cambios introducidos por uno de los miembros del equipo antes de fusionarlos en la corriente principal del desarrollo. Puedes hacer prácticamente todo lo que puedes hacer en tu buen software local, como comprometer el código, crear ramas, etcétera. También te ofrecerá comentar sobre el trabajo de alguien. También podemos discutir las cosas por encima de la comunidad, etc. Ahora GitHub no es la única opción para nosotros. Tenemos otros jugadores también en el mercado que vieron exactamente el mismo propósito. Cuál desea utilizar depende completamente de sus requisitos. Si tu organización está utilizando proyectos de ecosistemas de Atlassian como Jira, bamboo, etc., entonces Bitbucket podría tener sentido para ti porque tiene una mejor integración con esas herramientas. Y entre todos estos tres, git lab es de código abierto. Los otros dos tienen niveles tanto gratuitos como pagados. Y obtener laboratorio y Bitbucket tiene un mejor soporte para la integración continua, que es un concepto de DevOps hasta discutido en mi curso de DevOps. Pero GitHub es el más antiguo entre estos tres. Hay millones de proyectos que dependen de GitHub y hay millones y millones de desarrolladores en todo el mundo que están usando GitHub activamente. Github tiene una comunidad increíble y también es la mejor opción para proyectos de código abierto. La interfaz de usuario también es bastante minimalista, pero viene con un costo, sin embargo. No tiene el soporte integrado para integración continua como con GitLab y Bitbucket. Pero está bien, puedes usar algunas de las herramientas de terceros para eso. Pero no importa cuál de estas herramientas aprenderás. En última instancia, tienen el mismo objetivo de administrar tu proyecto. Podrían diferir en términos de interfaz de usuario y terminologías que se están utilizando. Pero por lo demás, todos tienen el mismo propósito. 62. 0802 cuenta de GitHub: De acuerdo, veamos cómo podemos crear una cuenta de GitHub e incluso crear un par de repositorios. Para ello, en realidad he creado una cuenta falsa de Gmail, que está bajo Corp 96 en gmail.com. Como si esta empresa se estableciera en 1996 o WhatsApp. Ahora cilindro como freelancer, va a crear una cuenta de GitHub para su propia organización para que todos los demás y su equipo puedan ahora comenzar a contribuir al proyecto en GitHub. Vamos a dar clic en registrarte. En realidad, las instrucciones son bastante directas. En realidad no tengo que guiarte a través de esto, pero sólo estoy haciendo esto como una formalidad. Por lo que nos está pidiendo que ingresemos la dirección de correo electrónico. Voy a hacer justamente esa contraseña. Ya lo tengo a mano. Entonces sólo lo voy a pegar. Nombre de usuario va a ser alguno de ahí Corp 96. Y levántate dice que esto no está disponible. Entonces necesitamos cambiar esto a otra cosa, tal vez 1996, ahora ya está disponible. Sigamos. Nos está preguntando si nos gustaría recibir las actualizaciones y anuncios vía e-mail, yo diría que no por ahora. Si lo desea, puede optar por eso. Siguiente. Nos está pidiendo resolver un rompecabezas para asegurarnos de que no somos un bot. Yo sólo tengo que elegir esta galaxia espiral. En mi caso. Yo voy a hacer precisamente eso. Ahí he hecho un excelente trabajo, así que puedo seguir adelante y crear la cuenta. Recibimos este correo con el código, cual solo tengo que copiar y pegar aquí. Y terminamos de crear una cuenta de GitHub. Bastante. Yo sólo quería saltarme este paso. Si lo deseas, puedes elegir cuántos miembros del equipo tienes y si eres estudiante o profesor. Pero simplemente voy a saltarlo por ahora. Y ya terminamos. Ahora a primera vista esta página de bienvenida que ves una vez después de iniciar sesión por primera vez, levántate ya nos está dando sugerencias sobre lo que podemos hacer a continuación. Podemos crear repositorio o importar repositorio existente. Podemos introducir un archivo léeme en nuestro proyecto. Incluso podemos explorar las opciones para aportar algunos de los proyectos existentes, que hablaremos en una etapa posterior del curso. Y hay un montón de otras cosas que puedes simplemente echar un vistazo y tener una idea de lo que se trata. No tienes que profundizar demasiado porque vamos a explorar todo en próximas conferencias. 63. 0803 Creación y comprensión de repositorios públicos y privados en GitHub: De acuerdo, veamos cómo podemos crear repositorios de GitHub. Podemos agregar ese importante repositorio existente. Crearé uno nuevo. Y yo voy a hacer precisamente eso. Aquí. Vas a ver el nombre del dueño. En este caso, sólo tenemos un dueño. Y eso es lo que se elige por defecto. Aquí tienes que proporcionar el nombre del repositorio, el nombre del repositorio que te gustaría hacer. Ahora, tenemos que decidirte si quieres hacer público o privado el proyecto. Si tu objetivo es iniciar un proyecto de código abierto, entonces podría tener sentido que elijas la opción pública aquí. O si eres una organización donde tu software o la aplicación propietarios y tienes un cliente para el que estás trabajando, entonces podría tener más sentido usar un repositorio. Si se trata de un repositorio público, cualquiera de todo el mundo podría ver el contenido de tu proyecto, descargar tu proyecto, clonarlo, etcétera. Mientras que si el repositorio es privado, puedes elegir quién puede hacer lo que puedes aportar al proyecto, quién puede ver el proyecto, etc. voy a demostrar la creación de ambos. El repositorio está asumiendo que estoy creando algún tipo de proyecto de código abierto. Déjame llamar a mi app como mi app pública o lo que sea. Si lo desea. También puedes separar estos nombres con un guión. No se puede tener un carácter de espacio en blanco. Si incluyes el carácter de espacio en blanco, entonces get asumiría automáticamente un carácter de guión, como está sugiriendo. Por cierto, podría usar la palabra Git y GitHub indistintamente dependiendo del contexto. Entonces este es el nombre de la app que he dado. También puedo escribir una descripción rápida sobre el proyecto, mi app pública, lo que sea. Y luego levántate. Nos está mostrando opciones para incluir algunos de estos archivos, como el archivo Read Me, que tendría algunos detalles sobre el proyecto. El archivo dot ignore, esencialmente cualquiera que sea el patrón de archivo que incluya en este archivo, sería ignorado para ser cometido. Entonces también podemos elegir el archivo de licencia. Existen ciertas licencias predefinidas que podemos usar si así lo deseamos. Por ejemplo, si estás creando un proyecto de código abierto, que gpu o una licencia pública general podrían tener sentido para ti. Por lo pronto, no voy a elegir ninguno de estos porque podemos agregarlos más adelante. Pero si eliges uno de estos, entonces get creará automáticamente un commit en nuestro nombre comprometiendo estos archivos. Es tu elección. Puedes elegirlo o no elegirlo. Ambos son más o menos iguales. vamos a sumar de todos modos en próximas conferencias. Entonces esto simplemente va a crear un repositorio público. Demos clic en Crear Repositorio. Y GitHub está proporcionando algunos próximos pasos por los que no tienes que molestarte porque los vamos a explorar de todos modos en próximas conferencias. Pero si vuelves aquí, puedes ver que nuestro repositorio está listado aquí. Si copia el enlace, el enlace se vería algo así. Tienes GitHub.com y luego la slash de nombre de usuario, el nombre del repositorio. Y así es como todos podrían acceder a tu repositorio público. Ahora, cualquiera en todo el mundo puede golpear este enlace para poder ver nuestro proyecto de Watson porque es público. Vamos a crear ahora también un repositorio privado. Dices clic en nuevo nombre del repositorio va a ser decir, app bancaria, lo que sea. Mi aplicación bancaria, voy a elegir la opción privada, que sólo las personas a las que doy acceso puedan ver el proyecto y contribuir al mismo. En realidad estoy hablando de colaboradores, que exploraremos muy pronto. Esta vez. Permítanme elegir tal vez uno de estos archivos. A lo mejor me gustaría agregar un archivo de licencia. Por ejemplo. Esta probablemente no pueda ser una licencia pública general. Pero puedes usar cualquier cosa. No tienes que ser realmente serio al respecto a menos que seas una verdadera organización que esté preocupada por las licencias. Simplemente estoy eligiendo algo al azar y crear repositorio. Esta vez, github ha hecho un commit por nosotros. Y en ese comprometido se ha comprometido el expediente de licencia. Puedes dar clic en ese archivo para echar un vistazo a su contenido. Puedes cambiar esto si lo deseas y hacer otro commit. Pero vamos a explorar todo eso en próximas conferencias. Volvamos a la página principal. Y ahora se pueden ver estos dos repositorios. Ahora, como este es un repositorio privado, nadie más puede acceder a éste. Desafortunadamente, los repositorios privados y GitHub no tienen muchas características que tienen los repositorios públicos. Si desea esas características y repositorios privados. Y más, insinuación en realidad considere tomar algunos de los niveles pagados que ofrece GitHub. A menos que seas una organización, realmente no tiene sentido que pagues por ellas. Y por esa misma razón, en su mayor parte, vamos a estar usando el repositorio público en este curso. Nos vemos a continuación. 64. 0804 Cómo hacer cometas en GitHub y entender el archivo ReadMe: Veamos cómo podemos hacer nuestro primer commit y levantarnos. Y eso lo vamos a hacer en el repositorio público. A lo que vamos a llegar es al archivo léeme para nuestro proyecto. Ahora, ¿cuál es el archivo léeme? Lo que quieras dejar saber, los contribuidores de tu proyecto entrarían dentro del archivo read me para entenderlo mejor, echemos un vistazo a algunos de los proyectos existentes y GitHub y qué tan despoblado los archivos Léame. Simplemente voy a elegir uno de los proyectos aleatorios. Por lo que hago clic en este enlace que dice encontrar reportes que necesitan tu ayuda. Simplemente voy a elegir uno de los proyectos aleatorios disponibles aquí. A lo mejor esta de aquí están la lista de tuplas a plantear. Ambos son públicos. Déjame elegir este. Todos los proyectos y GitHub lo más probable es que tengan el archivo read me. Y suele ir dentro del directorio raíz del proyecto. Entonces aquí está. A ver qué hay dentro. Básicamente puedes escribir cosas como tu información de contacto. Algunos de los enlaces que quieres compartir con los billetes de dólar. O puede instruirles en cuanto a cómo pueden plantear temas y a quién contactar para incase si hay algún problema con la aplicación. También puedes hablar de la aplicación y sus características, como están haciendo aquí. A continuación te presentamos la lista de características soportadas por esta aplicación. Están mostrando instrucciones sobre cómo pueden descargar este proyecto. Y montón de otra información que estamos compartiendo su hoja de ruta para que los desarrolladores tengan la vista de pájaro de todo el proyecto. Aquí parecen haber enumerado toda la lista de colaboradores, o tal vez los principales contribuyentes que contribuyeron a este proyecto. Así sucesivamente y así sucesivamente. Vamos a seguir adelante y crear un archivo léeme en nuestro repositorio público. Voy a elegir el repositorio público que se crearon. Y actualmente no tenemos ningún commit. Podemos crear un nuevo archivo o subir un archivo existente, o bien podemos elegir una de estas opciones. Y gate se prepoblará con algún contenido. Ya vimos que en caso de archivo de licencia, ya tenemos algunas plantillas predefinidas. También tenemos ciertas plantillas predefinidas están prepobladas para el archivo dot ignore también. Pero no vamos a usar eso porque aún no hemos hablado de ello. Déjame elegir Léeme archivo. Por lo que es Read Me dot md file. Se enseña extensión MD. Aquí. Puedes escribir lo que quieras escribir. Y una vez que termines, puedes desplazarte hacia abajo y dar clic en este botón que dice commit new file. Aquí puedes ver que algún mensaje predeterminado ya está poblado por GitHub. Dice Crear, Léeme punto archivo RMD. Si deseas cambiarlo, puedes seguir adelante y cambiarlo. También puedes agregar la descripción sobre ese commit. Pero estoy contento con el mensaje predeterminado. Entonces simplemente voy a dejarlo como está y dar clic en Comprometerse. No se requiere ningún paso de puesta en escena. Esto internamente haría ese trabajo por nosotros. Una vez que comprometas el archivo, vas a ver ese archivo aquí. Hagamos un commit más introduciendo uno otro archivo. Permítanme volver atrás y dar clic en esta opción que dice Agregar archivo, crear nuevo archivo. A lo mejor me gustaría agregar en archivo TXT de cuatro puntos, algún archivo de información de contenido. Permítanme ampliar esto. Voy a desplazarme hacia abajo. Y 1 segundo. Estoy contento con el texto prepoblado, pero puedo cambiarlo a otra cosa si lo deseo. Voy a dejar esta opción tal como está. Ya que no hemos hablado de pull request. No puedo explicarte ahora mismo de qué se trata esta opción. Vamos a hablar de ello en próximas conferencias. Ven con el nuevo archivo. Ahora tenemos un par de comentarios. Si haces clic en estos commits, puedes ver la lista de commits que hemos realizado. Aquí tienes el HashCode de cada uno de esos comentarios para que puedas copiarlos haciendo clic en este icono. También puedes ir a un estado de un proyecto en un commit particular. Al dar clic en este. Por ejemplo, si hago clic en esto, el cometa vendrá en el archivo Léame. En este punto no tenemos el archivo info, por lo que no lo vemos. Déjame volver. Aquí. Se llega a elegir la sucursal. Actualmente solo tenemos una sucursal y esa es la rama principal por defecto. De lo contrario estarías viendo lista de sucursales y podríamos cambiar a una de las sucursales. Entonces así es como haces comentarios y GitHub. Creamos el repositorio y también hemos añadido algunos de los archivos básicos lo que lo hace listo para que otros contribuyan a nuestro proyecto. Nos vemos a continuación. 65. 0805 Creación de sucursales y cometer cambios Gestionar sucursales en GitHub: De acuerdo, veamos cómo podemos crear una nueva sucursal e incluso hacer comentarios en ella dentro de GitHub. Para eso, déjame ir a uno de los repositorios. Voy a estar usando el repositorio público para esto. Aquí se llega a ver una lista de sucursales. Actualmente solo tenemos una sucursal, la rama principal, que también es la rama por defecto. Aquí puedes ver este enlace que dice ver todas las sucursales. Puedes hacer clic aquí o también puedes hacer clic en este enlace que dice una sucursal. Dice una sucursal porque actualmente tenemos una sucursal. Demos clic en este enlace. Aquí se ve la opción de crear una nueva sucursal. Simplemente haz clic en este botón, escribe el nombre que te gustaría hacerle a esa sucursal. Algoasí. También puede elegir la sucursal fuente desde donde desea crear esta sucursal. En este caso, solo tenemos una sucursal y ha incumplido con la rama principal. Voy a mantenerlo como está y dar clic en Crear Rama. Esto ha creado la sucursal para nosotros. También puedes ver listado específico de sucursales. Por ejemplo, si hago clic en activar, esto va a enumerar en toda la lista de Acto dos ramas. O dicho de otro modo, estas son las ramas donde hay al menos un commit realizado en los últimos tres meses. Aunque no vas a ver la rama predeterminada. Se puede ver la sucursal que se acaba de crear. Esta rama de cola es lo opuesto a dos ramas. Si hay alguna sucursal en la que no hayas realizado ningún commit en los últimos tres meses, vas a estar viendo una lista de ellas aquí. Si eres el propietario del repositorio, tal vez te gustaría ponerte en contacto con colaboradores son desarrolladores que están trabajando en estas sucursales y comprobar con ellos si todavía quieren mantener estas sucursales o no. Tendrás una mejor idea al respecto medida que avanzamos en este curso. Y las ramas en esta sección se enumerarían manera que la sucursal con el commit más antiguo se enumeraría primero. Mientras que aquí en la sección activa, todas esas ramas se enumerarían de manera que las ramas con el commit reciente se enumerarían primero. Si haces clic en todas las ramas, este pie solo muestra la rama predeterminada, seguida de todas las demás ramas ordenadas por las ramas con la confirmación más reciente primero. También puedes eliminar una sucursal y puedes restaurarla. Si eliminas una rama, actualiza la página, entonces es demasiado tarde para restaurarla. Por lo que somos capaces de crear una nueva sucursal. Volvamos al repositorio. Aquí llegamos a elegir la sucursal a la que queríamos cambiar. Cambie a rama de características. Esto es como si hubiéramos corrido este comando que o comando checkout mencionando el nombre de la rama. Y si te das cuenta, ahora tenemos dos ramas mostrando aquí. Podemos agregar un nuevo archivo en esta rama o editar uno de los archivos existentes. Vamos a tratar de agregarlo. Léemedot archivo MD. Hago clic en este icono, que me permitirá editar algún mensaje. Quiero desplazarme hacia abajo. Estoy contento con el mensaje por defecto si lo deseas, puedes seguir adelante y cambiarlo. Voy a dejar esta opción como está. Y da clic en Confirmar cambios. Esto ha comprometido cómo los cambios en la nueva rama. Actualmente estamos en la sucursal principal. Y si haces clic en Read Me dot md file y revisas su contenido, notarías que no tiene los cambios introducidos en la nueva rama de funciones. Pero si cambias a la rama de funciones, como puedes esperar, vas a ver los cambios que acabamos de introducir y la rama de funciones. Nos vemos a continuación. 66. 0901 clonar una repo pública y explorar otras opciones: Antes habíamos creado una cuenta GitHub con el nombre Centre Corp 1996. Y también hemos creado par de repositorios. Uno es público, el otro es repositorio privado. O repositorio público debe estar disponible para cualquier persona en el mundo para ver, descargar, volado, etcétera. Ahora digamos que encontré a un tipo con el nombre Luke y quería que contribuyera a mi repositorio público. Ahora imagina que estoy dentro de la computadora de Luke. Lo que primero debes hacer es básicamente tener cuenta de GitHub. Entonces para este propósito, en realidad he creado una nueva cuenta de Gmail con el nombre look Centre Corp en el gmail.com rojo y su correspondiente cuenta de GitHub también. Entonces esta es la cuenta de Luke y ahora se está preparando para contribuir al repositorio público del cilindro cop 1996. Esta es la URL de ese repositorio. Y soy capaz de ver el proyecto y su contenido porque este es repositorio público. Si este es un repositorio privado, entonces no podré ver esto. De hecho, cualquier persona con este enlace debería poder ver el proyecto y su contenido porque es repositorio público. Ahora lo primero que debe hacer ese loop para empezar a contribuir a este proyecto es tener copia local de este repositorio en su computadora local. De lo que estoy hablando es git clone. Y como su nombre indica, esencialmente clonaría el repositorio del centro o el proyecto en su inscripción local. Por lo que da clic en este botón que dice código. Y tenemos múltiples formas de clonar el proyecto. Podemos hacerlo a través, levántate CLI. Get up CLI es una herramienta que ofrece GitHub. Se trata de una herramienta de código abierto y esencialmente te permitiría interactuar con GitHub desde la línea de comandos de tus computadoras. Pero esta herramienta originalmente está destinada a ahorrar algo de tiempo, pero esta no es una herramienta obligatoria como tal. La otra opción es usar SSH, que es un procedimiento largo ya que para ello, hay que crear claves públicas y privadas y luego almacenar la clave pública en el repositorio, etcétera. Hablar de SSH debe ser un tema de otro curso. Si estás usando SSH, entonces puedes ir con esta opción. Si no, entonces tenemos una mejor opción. De hecho, esta es opción recomendada incluso por GitHub, que es usar el protocolo HTTPS. Esta es la mejor opción entre todos estos por dos buenas razones. Número uno, típicamente los firewalls no tienden a detenerse como tráfico HTTPS. Entonces ahí tenemos una ventaja. En segundo lugar, también ayudará al ayudante de credenciales fuera su sistema operativo para poder caché o almacenar las contraseñas, lo cual no es el caso con las otras dos opciones. Esto es lo más sencillo de todo, y podemos ir ciegamente con esto y no tenemos que preocuparnos por SSH o levantarnos CLI. También tenemos la opción de descargar el proyecto. Pues bien, si descargas el proyecto no se va a descargar los datos históricos o el historial de versiones solo se va a descargar los archivos en el proyecto. También podemos abrir esto con GitHub Desktop. Si tienes instalado el GitHub Desktop, puedes abrirlo y luego puedes elegir la carpeta donde quieres clonar este proyecto. Ya que no estamos utilizando esta herramienta en este momento, podemos ignorar esto. Entonces lo que vamos a hacer es simplemente copiar este enlace HTTPS. Este es el enlace exacto, como estás viendo aquí, que es el enlace al repositorio, Eso es github.com slash username de este repositorio, el propietario del repositorio, slash el nombre del repositorioen sí, y luego punto get extensión. Esto es esencialmente ¿qué es esto? Literalmente solo te copian. Una vez que tengamos este enlace copiado dentro de nuestra computadora local, estoy dentro del directorio def. Déjame volver a copiarlo. No te imaginas que esta sea la computadora de Luke. Voy a usar el comando git clone. Y luego vas a pegar esa URL. Entonces aquí dice clonación en esta carpeta. Esencialmente ha creado carpeta con este nombre, que es el nombre exacto del depositario. Y el contenido del mismo constituiría exactamente el contenido que hemos visto en el repositorio de GitHub. Y si te das cuenta que en realidad ha comprimido todos los objetos. Básicamente para facilitar la transferencia de todos los archivos a través de Internet a su computadora local. Y luego, finalmente, ha extraído todos los objetos. Se han recibido un total de nueve objetos. Echemos un vistazo al contenido dentro de ese directorio. Entonces aquí está mi gorra pública. Déjame agrandarlo un poco. Como puedes ver, nos han puesto dxdy así como el archivo Read Me dot TXT. Dentro de la carpeta dot git. Vas a ver lo que solemos ver. Es posible que hayas observado un par de cosas que te podrían parecer extrañas en este momento. Vamos a hablar de ellos en próximas conferencias. Por ejemplo, tenemos los llamados controles remotos, que no estaban disponibles cuando creamos localmente el repositorio. Hablaremos de ellos en próximas conferencias. Esto es como has creado un depositario local, excepto que esta vez, en realidad hemos clonado un repositorio existente de GitHub. Si fueras a descargar el proyecto, no vas a ver la carpeta dot git. Sólo verías estos dos archivos de proyecto. Ahora bien, esta es la razón por la que se le llama sistema de control de versiones distribuidas. Tienes una copia de todo el repositorio junto con su historial de versiones en tu máquina local. Y también tienes una copia del mismo en el repositorio centralizado, que es get up. Y todos en la organización o en su empresa estarían teniendo una copia de todo el repositorio. Si uno fuera a bajar, entonces tienes otros sistemas desde donde puedes recuperarlos. Ese es el sistema de control de versiones distribuido para usted. Volvamos a Git Bash. Ahora si ejecuto el comando git branch, necesitamos ir primero dentro de ese directorio. Mi CAP público, sucursal git. Sólo vas a ver la rama principal, aunque hemos creado rama de funciones en el repositorio centralizado GitHub, aquí solo estamos viendo la rama principal. ¿ Por qué es eso? Pues bien, encontrarás respuesta a ello en próximas conferencias. 67. 0902 clonar un repositorio privado y agregar colaboradores de proyectos en GitHub: De acuerdo, veamos cómo podemos clonar un repositorio privado. Actualmente he iniciado sesión como remitente, ¿quién es el propietario de estos repositorios? Uno es el repositorio público y el otro es el repositorio privado. Ya hemos visto cómo podemos clonar un repositorio público. Cualquiera en el mundo puede verlo, clonarlo en el sistema. Pero cuando se trata de repositorio privado, en realidad no todos pueden acceder a él o poder clonarlo a menos que el remitente los dirija como colaborador de su proyecto. Para demostrar esto, en realidad he iniciado sesión como ambos cilindros así como Luke, quien estaría contribuyendo al repositorio privado de cilindro. Con el fin de distinguir entre estas dos cuentas. El del equipo negro pertenece a sunder y el del equipo blanco pertenece a Luke. Ahora necesitas hacer una suposición que estas dos personas realmente han iniciado sesión desde sus propias computadoras. Y claro que no del mismo sistema, como lo estamos haciendo aquí. Permítanme copiar el enlace del repositorio privado e intenté acceder a él desde la cuenta de Luke. Y nos sale un error que dice 404. Esta no es la página web que estás buscando. Eso se debe a que under no ha dado permiso para buscar acceder a este proyecto. Entonces, lo que el remitente tiene que hacer es que tengas que entrar en ese repositorio, ir a la configuración y luego agregar Luke como colaborador. Déjame ingresar la contraseña muy rápido. Verás esta opción que dice Agregar personas. Voy a buscar. Se ve debajo de la carpa. Ya que Luke tiene un contenido, github, podrá verlo. Déjame elegirlos y dar clic en Añadir looks en la Corp a este repositorio. Una vez que hagamos eso, loop en realidad recibirá un correo electrónico para aceptar el sol hace invitación a ser el colaborador del repositorio privado del remitente. Entonces déjame dar clic en este enlace. Haga clic en Mutación Aceptada. Ahora si vas al tablero de Luke, puedes ver que el repositorio privado se está poblando. Déjame dar clic en él. Ahora puedo seguir adelante y trazar este proyecto. Pero no es muy sencillo como con repositorio público, tenemos que autenticarlo realmente. Deja que te lo demuestre. Entonces esto se ve computadora. Supongamos que estoy dentro de la unidad F. Y ejecutemos el comando git clone y peguemos la URL y veamos qué va a pasar. Bueno, bueno abre este prompt en particular. Y hay múltiples formas en las que podemos autenticarnos. Pero me gustaría ir con esta opción que dice inicio de sesión con código. Si eliges iniciar sesión con tu navegador, solo te llevarían a una página web donde te pediría que iniciaras sesión en tu cuenta de GitHub. Y de esa manera serás autenticado y el proceso de clonación continuará. Pero tratemos de elegir de esta manera. Cuando hago clic en Iniciar sesión con código, vas a ver un código que necesitamos usar para autenticar. Déjame abrir primero una ventana del navegador. Voy a ir a github.com slash login slash device. Nos llevará a esta página. Permítanme copiar este código, control C y control V. Y haga clic en Continuar. Haga clic en Autorizar. ¿ Nos pide que ingresemos la contraseña de la cuenta de Luke. Hagámoslo muy rápido. Eso es todo. Nuestro proceso de clonación ha continuado. Y ya podemos empezar a acceder a la app bancaria. Agrupa las listas con la opción de guiones, pero también muestran las carpetas ocultas. A partir de este punto, todo quedaría tal como está como con el repositorio público. Pero así es como clonas un repositorio privado. Nosvemos a continuación. 68. 0903 Comprender las ramas de seguimiento y rama por defecto: Hablemos de rastrear sucursales. Imagina que este es el estado actual de nuestro proyecto en GitHub. Y ahora digamos que he corrido el comando git clone para clonar el proyecto en mi computadora local. Ahora bien, esto es lo que va a pasar en mi computadora local sin ningún orden en particular. Inicialmente todos los objetos serían descargados y luego get creará las llamadas ramas de rastreo. Ahora, ¿qué es la sucursal de rastreo? Rastreo de sucursales, una sucursal local que representa una sucursal remota. Y siempre señalaría exactamente el mismo commit. Las ramas remotas apuntan hacia allí sólo representando a las ramas remotas. Sólo para recordar, una rama es simplemente un puntero a un commit específico. Ahora, estas sucursales de rastreo no se actualizarán automáticamente. Se actualizarán cada vez que ejecutemos ciertos comandos como git-fetch y git pull, que vamos a hablar en próximas conferencias. Y luego por defecto con la operación clon, git checkout a la rama por defecto, que es la rama principal. Y así se crearía automáticamente una sucursal local Min. En realidad podemos configurar la rama predeterminada en nuestro GitHub, explotará eso en próximas conferencias. Si recuerdas en nuestra conferencia anterior, cuando ejecutamos el comando git branch, se ha enumerado solo la rama principal, pero no la rama de características. Bueno, esta es la razón de eso. Si quieres poder ver la rama de funciones también, tenemos que revisar a esa sucursal para que una sucursal de entidades local sea creada por buena y pueda verla. Ahora digamos que he hecho un commit local en la rama principal como celular, la rama de rastreo se quedaría como está, porque eso es a lo que incluso la rama principal remota está apuntando. Pero la sucursal principal local se actualizaría para apuntar a la última commit en nuestra máquina local. Comprenderás la importancia de rastrear ramas cuando exploramos comandos como git-fetch, git, pull, git push, etcétera. Otra cosa que podrías haber notado es que todas estas ramas de rastreo se nombran como origen slash main u origins feature. Bueno, ¿qué es el origen aquí? Es esencialmente el primero creado por get que representa el repositorio remoto. Básicamente cada vez que ejecutamos comandos, winter proporciona la URL del repositorio remoto. Es realmente difícil recordar la URL. Y por eso tenemos creado este LES. Para que en lugar de usar la URL, podríamos simplemente usar este nombre. En su lugar. Podemos cambiar este nombre si lo deseamos, o podemos mantenerlo como está. que vamos a hablar más de ello Seguroque vamos a hablar más de ello en próximas conferencias. Nos vemos a continuación. 69. 0904 Explorar ramas de seguimiento Configuración de rama por defecto: De acuerdo, primero echemos un vistazo a la lista de sucursales de rastreo. Y el comando para eso es git. Sucursal. Guión r significa Remoto. Aquí puedes ver tanto la rama principal como la nueva sucursal de características. Y estas son las sucursales de rastreo que representarán en las sucursales remotas. En GitHub. Se puede decir que estas son ramas de rastreo porque empiezan con la slash de origen y luego el nombre de la rama. También puedes localizar esto en el repositorio de Git. Déjenme ir al proyecto. Y dentro de la carpeta dot git, deberías poder localizar este archivo con el nombre lleno de guiones derivas. Abre eso. Y se puede ver que tenemos estas dos ramas. Y el punto en comentarios específicos. Echemos un vistazo a lo que apuntan. Para eso, déjame ir a levantarme. Actualmente estoy dentro de la sucursal principal. Y aquí puedes ver el hashCode de la última commit. Es E 0, triple seis es siete. Y estamos en la rama principal. Y si se nota, la rama principal de rastreo está apuntando exactamente al mismo cometa. Vamos a comprobar con la nueva rama de características también. Debe apuntar a este commit que inicia con 855 D, D2. Volvamos y cambiemos a rama de características o nueva rama de características. Y claro, apunta a este commit con el hashCode 855, doble D a C. Incluso si tuvieras que hacer un commit local, esto seguiría siendo como está. Esto solo se actualizaría cuando en realidad ejecutamos ciertos comandos como git, fetch, git pull, etcétera. exploraremos en las próximas conferencias. sucursal de Git haría una lista abajo de las sucursales locales. Y cualquiera que sea la rama predeterminada y GitHub se revisaría no automáticamente cada vez que clonamos el proyecto, la rama predeterminada pasa a ser la rama principal. El jefe aquí siempre apunta a la rama por defecto, que es la rama principal. Vamos a levantarnos y echar un vistazo a donde podemos configurar la rama predeterminada. Si vas a la configuración. Debajo de sucursales. Aquí verás que las ramas por defecto, la rama principal. Si lo desea, puede cambiar a otra sucursal. Por ejemplo, puedo elegir la rama de características y hacer clic en actualizar. Pero no es una práctica recomendada. Voy a saltarlo. Pero puedes hacerlo si lo deseas. Dentro del repositorio de Git. Si vas dentro de refs remote origin y echas un vistazo a lo que hay dentro del archivo de encabezado, debería apuntar a la rama predeterminada, así. Y eso es lo que estamos viendo aquí. Ahora, para crear una sucursal local para la nueva sucursal de características, fue a revisar a esa sucursal. Hagamos git checkout. Nueva característica. Ahora si haces git branch, se va a enumerar abajo todas las sucursales locales. Y ahora también incluye la nueva rama de funciones. Ya podemos empezar a trabajar en esta rama de funciones. Obtendrás una mejor claridad sobre lo que acabamos hablar a medida que avanzamos en este capítulo. Nos vemos a continuación. 70. 0905 Comprender la adición remota de origen, la edición, la eliminación de controles remotos: Hablemos de origen. Origin es algo así como un alias en su sistema para un repositorio remoto en particular. Déjame explicarte lo que quiero decir. Hay ciertos comandos y llegar donde se le requeriría especificar el URI del repositorio remoto. Al igual que en caso de git push. Vamos a hablar más sobre comando git push en próximas conferencias. Pero esencialmente lo que este comando nos permite hacer es que nos permitirá empujar nuestros commits locales al repositorio remoto. Bueno, tales comandos requieren que ingresemos donde queremos empujar nuestros commits especificando el URI del repositorio remoto. Ahora bien, ¿qué tal si le damos algún nombre a esta ERA para que cada vez que tengamos que ejecutar dicho comando, en lugar de especificar toda la ERA, solo necesitaríamos escribir ese nombre en su lugar. Eso nos va a dar mucha comodidad. Y eso es esencialmente lo que es el origen. Origin es algo así como un nombre abreviado para el estudio de repo remoto del que originalmente se clonó el proyecto. Para que en lugar de entrar en el URI, podríamos simplemente decir origen, así. Y es Asda. ingresado al URI del repositorio remoto. Podemos renombrar este nombre por otra cosa. También podemos agregar controles remotos adicionales. Cuando digo remoto es simplemente un nombre que representa un repositorio remoto en particular, cómo podemos incluso eliminar estos controles remotos. Déjame demostrarte lo que quiero decir. Si vas dentro de la carpeta dot git, dentro de tu proyecto y abres el archivo config. Se nota que tenemos un remoto con el nombre origen, y apunta a un repositorio remoto en el campo URL. Esto es exactamente lo que es el modo. Entonces cada vez que tenemos que ejecutar el comando, ¿dónde se requeriría ingresar al CR? Simplemente podemos ingresar el nombre origen en su lugar. También podemos renombrar esto, pero claro, no deberíamos hacerlo directamente en este archivo. En su lugar va a ejecutar el comando. Hagamos eso. Dentro del Git Bash. Primero creemos un nuevo mando a distancia. Y sí, podemos tener múltiples mandos a distancia y hay escenarios donde podríamos requerir varios mandos a distancia. Vamos a hablar de ello en próximas conferencias. Pero por ahora veamos cómo podemos crear un control remoto, renombrarlo, e incluso eliminar un remoto. El comando para eso es git remote. Agrega el nombre del control remoto, el nombre que te gustaría, a ese repositorio remoto. Llamémoslo temp, reporte, como sea. Y luego vas a especificar el URI del repositorio remoto. Esta es solo una URL ficticia que no existe. Y si presiono Enter, y si volvemos al archivo de configuración, verás que hay un nuevo remoto creado con el nombre poste temporal, cuya URL es la URL que acabamos de especificar en el comando. Déjame intentar cambiar el nombre de este remoto. Git remoto, cámbiales el nombre ripple. El nombre del mando a distancia le gustaría renombrar. Y después vas a especificar el nombre que quisiéramos darle. Nueva temp, repo, digamos. Y esto va a cambiar el nombre a ese nuevo nombre. Por último, veamos cómo podemos quitar un control remoto. Git. Remoto es la opción. Entonces vas a especificar el control remoto que te gustaría eliminar. Y eso es todo. Esto ha eliminado el control remoto. Cuando habíamos corrido el comando clone para clonar un repositorio remoto en particular, git esencialmente ha creado un remoto para nosotros. El nombre de ese remoto es origen, cuya URL es la URL que hemos utilizado para clonar el proyecto. Entenderás más sobre los mandos a distancia a medida que avanzamos en este curso. Nosvemos a continuación. 71. 1001 comprende Git Fetch y es usecases: Hablemos de git-fetch. Imagina que este es el estado actual de nuestro proyecto tanto en depósito remoto como local. Ahora pausa el video, tómate un minuto y trata de entender este diagrama. Todos ustedes renuevan esto. Bueno, solo tenemos un par de comentarios en la rama principal tanto en repositorio local como remoto. Y luego tenemos una sola confirmación en la rama de entidades tanto en el repositorio local como en el remoto, excepto en el depositario local, también tenemos ramas de seguimiento adicionales que representan las ramas en el repositorio. Y actualmente están apuntando a los mismos cometas exactos los que apuntan las ramas del repositorio remoto correspondientes . Hablemos de git-fetch. Imagina que hay un par de comentarios adicionales realizados en rama de funciones en repositorio remoto. Ahora qué pasa si quisiera descargar los objetos que corresponden a estos cometas al mismo tiempo. No quiero ver todos esos cambios en mi directorio de trabajo. Ahora bien, podrías estar teniendo una pregunta apareciendo en tu mente de ¿por qué queremos descargar estos objetos? Pero no quiero que esos cambios se muestren en un directorio de trabajo. Bueno, hay múltiples casos de uso en los que podría ser útil. Por ejemplo, digamos que me gustaría comparar mi repositorio local con el repositorio remoto para comprobar cuántos comentarios es el repositorio remoto está por delante de mi repositorio local en una rama en particular, o viceversa. Me gustaría comprobar para ver cuántos comentarios está mi repositorio local por delante del repositorio remoto en una rama en particular? O qué pasa si quisiera obtener el estado exacto del repositorio remoto como está en mi inscripción local, para empezar a trabajar en ello. Al mismo tiempo. No quiero que tenga ningún tipo de implicaciones en el trabajo que ya he hecho localmente. O podría ser el caso de que solo quisiera echar un vistazo a si hay alguna rama o tags adicionales, referencias que están presentes en el repositorio remoto pero no están presentes en el depositario local. Bueno, git-fetch es la respuesta para eso. Cuando ejecutes el comando git fetch localmente, este va a descargar todos esos objetos adicionales que no están ya presentes en tu repositorio local. Y también actualiza estas ramas de rastreo para apuntar a estos nuevos commits o los nuevos objetos que acaban de descargarse con git-fetch. Ahora en este ejemplo, sólo estamos asumiendo que tenemos comentarios adicionales y rama de características. Y así solo se actualiza la rama de seguimiento de la rama de características para apuntar a la misma confirmación exacta a la que apuntan las ramas remotas. No obstante, si hay comentarios adicionales realizados en otras sucursales, sus correspondientes sucursales de rastreo en también se actualizarían sus correspondientes sucursales de rastreo en su máquina local. Ahora el hecho de que las sucursales locales, como la principal y la rama de características sigan apuntando a los viejos commits. Caminarás en esa habitación, no tendrás todos esos cambios recién introducidos. Ahora todo esto podría sonar muy confuso para ti, pero en próximas conferencias, tendrás una claridad completa de por qué necesitamos git-fetch y entenderás su significado. No puedo caber todo bajo solo video. Nos vemos a continuación. 72. 1002 Git Fetch en acción Part1 (variaciones de comandos Comando el estado con comandos): De acuerdo, veamos cómo funciona git fetch. Actualmente he iniciado sesión como propietario del repositorio. Y solo para su información, actualmente tanto local como el repositorio remoto son exactamente iguales. No se hicieron comentarios adicionales en ninguno de los lugares. Permítanme ahora ir al repositorio público y hacer un nuevo commit. En realidad podríamos hacerlo en la rama principal, o hagámoslo en la rama de funciones. Simplemente voy a agregar un nuevo archivo. Me gustaría nombrarlo como tal vez Apple dot dx, dy. No importa si te gustaría incluir una carpeta y simplemente hacer el nombre de la carpeta. Tal vez. Al igual que enviar una nueva barra de proveedor. Esto crearía una carpeta con el nombre Mi Carpeta dentro de la cual tendrá este archivo con el nombre apple dot TXT. Sólo me gustaría comentar el expediente. Haga clic en Commit. Acabamos de crear un comentario. Permítanme ahora seguir adelante y crear una sucursal también. Primero déjame cambiar a rama principal. Porque eso es de ahí. Me gustaría crear una nueva sucursal. Este tipo en el nombre de la sucursal que me gustaría hacer , tal vez cuentan con dos. Y luego aquí obtenemos una opción para crear una característica de sucursal para, vamos a dar clic en ella. Y esto debería crear característica para ramificar. Permítanme volver a la nueva rama de funciones y hacer clic en la lista de comentarios. Aquí está el commit que acabamos de hacer, cuyo hash comienza con E8, AF, lo que sea. Ahora vamos a la inscripción local. Ahora, hay que imaginar que esta es una de las computadoras del empleado, quizá del señor Luke, lo que sea. Ahora antes de hacer git fetch, Déjame ejecutar el comando git log. Y fíjate que actualmente estoy en la nueva rama de largometrajes. Aquí. Como puede ver, que la nueva rama de características, que es la rama local, está apuntando a este commit en particular. E incluso la rama de rastreo está apuntando a este commit. Ahora una vez después de hacer git fetch, debería descargar todos esos objetos adicionales presentes en el repositorio remoto y también actualizar esta rama de seguimiento para apuntar a ese objeto commit. A ver si eso sucede. Pero antes de eso, déjenme bajar un comando más para comprobar los detalles del remoto origen. Git, remoto, mostrar origen. Esto mostrará la información sobre el origen remoto. Déjame guiarte a través de lo que aquí se muestra. Tenemos el fetchone, que está siendo recogido del archivo config, empuja algo que aún no hemos hablado. Pero cuando usamos el comando push, esta es una URL que debe usarse para empujar nuestros cambios locales. Ramas de cabeza que apuntan a la rama principal, que tiene una rama por defecto, como ya hemos comentado antes. Aquí la lista fuera de sucursales. Estas son las ramas que están disponibles en el repositorio remoto. Si notas, para la nueva sucursal que se crearon en el GitHub, Twitter a sucursal. Dice que el siguiente fetch se almacenará en origen de barra remota. Lo que esto significa es que cuando hacemos fetch, git creará una rama de seguimiento para la característica a rama que está presente en el repositorio remoto de GitHub. No obstante, la rama principal y la nueva rama característica, lo que ya se rastreó. Aquí está la lista de sucursales locales configuradas para git pull. Vamos a hablar de bueno Pull bastante pronto. Estas son las ramas para git push. No tenemos esta sucursal aquí porque aún no hemos cobrado deuda y no hemos comprobado a esa sucursal. Ahora echemos un vistazo a lo que pasaría si hago git fetch. Bueno, idealmente tengo que especificar el nombre del remoto desde donde me gustaría sacar los objetos. Pero si no especifico nada, se pondría por defecto al remoto de origen, que ya tenemos. Si desea buscar objetos correspondientes a una rama específica en un control remoto en particular. Entonces la sintaxis para eso es que vas a especificar el origen remoto en este caso. Y luego sólo se especifica el nombre de la rama, por ejemplo, nueva característica o lo que sea. Si deseas descargar objetos para todo el control remoto y todas las ramas, entonces solo tienes que usar la opción. Todos. Actualmente sólo tenemos un pueblo de origen remoto. Así que puedo simplemente ejecutar este comando como está sin tener que especificar nada. Por lo que todos esos objetos adicionales se estaban descargando y se desempaquetan localmente. Y si te das cuenta, tenemos esta nueva sucursal, que es característica a sucursal para cual en seguimiento se crea sucursal. Y entonces esta es línea importante. La nueva rama de características. Antes señalaba este compromiso en particular. Pero ahora la nueva rama de seguimiento de características, o la sucursal de rastreo local, está apuntando a este nuevo commit. Este es el commit exacto que hemos hecho en el repositorio remoto hace un momento. Entonces aquí está. Es E8 a F E a E. Y esto es exactamente lo mismo. Ahora permítanme volver a ejecutar el comando remote show origin y ver qué tiene que mostrar en comparación con lo que ha mostrado anteriormente. Bueno ahora si observas la característica a rama está siendo rastreada, pero esta rama aún no está disponible en esta lista. Eso es porque aún no hemos revisado a esa sucursal. Si consigo Switch característica dos, o también se podría decir Git checkout feature también. Nos cambiaríamos a esa sucursal. Y ahora si ejecutas este comando, también verías esa rama en esa lista. Permítanme volver a la nueva rama de características. Cada vez que cambio a esa rama, ves este mensaje que dice que tus ramas detrás de origen nueva característica, que es la rama de seguimiento por un commit, lo que significa que repositorio remoto es una commit por delante de nuestra sucursal depositaria local. También está diciendo que en realidad podemos realizar una fusión de avance rápido, que vamos a hablar en próximas conferencias. Y también nos está sugiriendo que podemos usar git pull para actualizar tu sucursal local. Una vez que actualicemos la sucursal local con buena encuesta o con la operación de fusión, vas a ver que todos estos nuevos cambios están disponibles dentro del directorio de trabajo. Países, ya que las sucursales locales siguen apuntando a todos se comprometen, su directorio de trabajo actualmente no se ve impactado en absoluto. Si hago git log ahora, solo ves que nuestra nueva rama de características local está apuntando a este viejo commit. Antes, si se acuerda, también hemos visto la rama de rastreo apuntando a este commit. Pero después de buscar ramas de rastreo ahora apuntando a ese nuevo objeto commit que se descargó con git-fetch. Dejaré, nos vemos a continuación. 73. 1003 Git Fetch en acción Part2 (explorando refs FETCH HEAD): Vale, mencioné que git-fetch descargaría los objetos e incluso actualizaría las ramas de rastreo. Digamos si efectivamente estoy en lo correcto para eso, déjame ir a GitHub y copiar el hashCode del último commit haciendo clic en este ícono. Y actualmente estoy en la nueva rama de funciones y GitHub. Déjame ir a Git Bash y déjame intentar imprimir bastante este objeto, obtén guardado el guión del archivo P. Y luego voy a pegar HashCode que acabo de copiar. Así que somos capaces de ver el contenido del objeto commit, lo que significa que git-fetch efectivamente ha descargado este objeto. Si navegas por este árbol padre de este objeto cometa, deberías poder localizar los objetos blob y su contenido correspondiente también. Ahora veamos si se actualizan las ramas de craqueo. Mencioné que las ramas de rastreo en realidad se conservan en el archivo de telones de fondo. Vamos a abrirlo. Aquí. Si te das cuenta, la nueva rama de características sigue apuntando a la confirmación anterior. Ahora me equivoco al decir que se actualizaría el rastreo de sucursales? La respuesta es no. Veamosqué hay en este directorio en particular. Origen remoto y nuevas características refs, origen remoto. Y déjame abrir el archivo con el nombre nueva característica. Y aquí se ve el hashCode del último commit. Ahora bien, ¿por qué este código hash está disponible aquí pero no está disponible en el archivo refs normalmente tenderá a almacenar referencias en la estructura de directorios. No necesariamente siempre se almacena en archivo empacado. Use este archivo empacado por el bien de la eficiencia. Pero no garantiza cómo ni siquiera puede predecir dónde almacenará las referencias. Podría estar en el archivo empaquetado, o también podría estar en forma de una estructura de datos. Si almacena las diferencias en un archivo empaquetado, no tiene que crear la estructura de directorios solo para almacenar la referencia. Todo es interno levantarse. Y este es uno de los ejemplos de por qué no debemos preocuparnos demasiado por lo bueno que hace las cosas por nosotros. Sólo tenemos que ejecutar los comandos y confiar y subirnos a ello. Es posible que también hayas notado este archivo, fetch head, que se crea cuando haces la operación fetch. Veamos el contenido de la misma. Ahora esta es otra vez por la que no deberías estar demasiado preocupado. Pero si se nota tenemos tres líneas, cada una correspondiente a rama individual, excepto la rama desde donde habíamos dibujado el comando git-fetch. Todas las ramas por marcadas como no para mucho. Pero de nuevo, no intentemos aprender todo porque podrías terminar confundiéndote y podrías terminar por no ser capaz de entender los conceptos reales que son necesarios. Pero este archivo suele ser utilizado por Gibbs. Cuando ejecutamos ciertos comandos como git pull por ejemplo, que vamos a hablar en próximas conferencias. Por ejemplo. Si haces git log, no puedes ver la rama de rastreo o dos que vienen en las ramas de rastreo apuntando. Pero si dices git log y luego busca cabeza de subrayado por ejemplo. Entonces también enumerará el objeto cometa donde las ramas de rastreo apuntando así. Así que de manera similar, tenemos ciertos comandos que internamente usarían el archivo fetch head. Nos vemos a continuación. 74. 1004 Cómo cambiar a Remote Repo State: Ahora con git-fetch, ya que hemos descargado todos esos objetos, en realidad podemos revisar el commit en particular y vamos a despegar que se quedó. De esa manera. Podemos tener el mismo estado del repositorio remoto sin tener que impactar nuestro trabajo existente. Déjame mostrarte lo que quiero decir. Déjame volver a GitHub y déjame cambiar a nueva rama de características y obtener el código hash de la última commit. En realidad los primeros caracteres bastarían. Dentro de Git Bash. Voy a decir git checkout. Ahí está el HashCode. Por lo que esto debería traer nuestro proyecto para desprender ese estado. Y esencialmente, nuestro proyecto no es exactamente el mismo estado que con el repositorio remoto. Si te das cuenta, tenemos este archivo, apple dot archivo TXT, que es lo que necesitamos. Si lees este mensaje, puedes ver que dice que estás en desprendimiento en estado. Puedes mirar a tu alrededor, hacer cambios experimentales y comprometerlos. Y puedes descartar todos esos comentarios una vez que vuelvas a otra sucursal. Para que pueda seguir adelante y hacer algunos comentarios. ¿ Experimenta la aplicación o lo que sea vesícula con mis cambios? Y una vez que haya terminado, sólo puedo volver a cambiar a una sucursal para que se pierdan todos esos comentarios. En caso de que si quiero conservar esos comentarios, entonces puedo usar este comando consigue que guión Z. y luego voy a especificar un nombre de la nueva rama. Por lo que este comando crearía esta rama y tener todos esos comentarios en su cabeza no está apuntando a este commit en particular, no a una rama en particular. Y por eso es jefe de estado desapegado. Permítanme volver a la nueva rama de características. Nueva característica. Y salimos del estado jefe desapegado. Por supuesto que ya no CD apple dot archivo TXT. Ahora tal vez puedas tomar esto como una tarea. Ve a desenlazar estado de conjunto, haz algunos comentarios antes de volver a cambiar a una sucursal. Asegúrate de que esos cambios sean, los comentarios se conservan en otra rama. Te deseo buena suerte con eso. Nos vemos a continuación. 75. 1005 fusión de los cambios con FETCH HEAD: Supongamos que me gustaría tener todos los cambios de repositorio remoto en mi directorio de trabajo. mejor porque me gustaría trabajar en ellos, o tal vez es que me gustaría tener todas las actualizaciones remotas y luego me gustaría seguir trabajando en mis propias cosas. Ahora una pregunta para ti. Qué puedo hacer ahora mismo para que tenga todos esos cambios en mi directorio de trabajo. Con git-fetch. Ya hemos descargado todos los objetos. No tenemos que volver a hacer eso. ¿Qué más podemos hacer? Bueno, podemos realizar fusión. Tenemos la rama de seguimiento para nueva característica que apunta a la commit remota. Y también tenemos la nueva rama de características local, que apunta a la vieja commit. Si fusionamos estas dos ramas, idealmente deberíamos estar teniendo todos los cambios en nuestro directorio de trabajo, ¿no es así? Primero, ejecutemos el comando git status. Dice que sus ramas detrás de origen nueva característica por un commit y puede ser avance rápido que tan bueno nos ha dado una sugerencia de que en realidad podemos realizar una fusión de avance rápido. que también significa que también existe la posibilidad de que necesitemos realizar una fusión de tres vías. Y bien podríamos tener conflictos, que tenemos que lidiar. Ya hemos visto cómo lidiamos con los conflictos cuando estás tratando de fusionar par de ramas. Lo mismo aplica aquí también. Ahora puedes intentar hacer una conjetura en cuanto a qué comando me escriba aquí para tener todos esos nuevos cambios en nuestro directorio de trabajo. Bueno, es un comando git merge estándar. Tenemos que empujar primero a una rama que queremos fusionarnos, en este caso, queremos fusionar los cambios de otra rama a la sucursal de nueva característica local. Y ahí es donde estoy. escribir el comando git merge. Y voy a especificar la rama de seguimiento, que es origen slash nueva característica. Esencialmente, solo estamos realizando una fusión de avance rápido en este caso , en la que nuestra nueva rama de características, que es una rama local, ahora señalaría exactamente el mismo commit que el seguimiento remoto de sucursales apuntando a. Pero digamos que también tienes un commit hecho en tu repositorio local. Bueno, entonces en ese caso hay que realizar una fusión de tres vías. Y eso podría crear un commit de fusión adicional a menos que rebase y luego realice una fusión de avance rápido. Vamos a darle a Enter. Aquí un resumen de lo que acaba de pasar. Nuestra nueva rama local de características no está apuntando a este nuevo commit. El mismo commit al que apuntaba la rama de rastreo. Lo que acaba de pasar es una fusión de avance rápido. Y este es un archivo nuevo que vamos a ver en nuestro directorio de trabajo. Aquíestá. También quiero mencionar rápidamente que la alternativa a mandar para esto es git merge, fetch underscore head. Esto hará el mismo trabajo. Y este es uno de los comandos donde bueno podría usar el archivo fetch add. Habíamos hablado antes. Ejecuta ese comando. Diceya al día porque ya habíamos fusionado los cambios. Espero que tenga sentido. Nosvemos a continuación. 76. 1006 usando el código de Visusal Studio para buscar y combinar: De acuerdo, veamos cómo podemos realizar fetch y básicamente escrito lo que hemos aprendido hasta ahora en este capítulo en Visual Studio Code. En primer lugar, asegúrate de tener abierto el proyecto. Si no ves tu proyecto aquí, ve al menú Archivo y haz clic en Abrir carpeta. Elige tu proyecto. Y deberías estar bien para ir. Vamos a cambiar a la sección de control de fuente para realizar git-fetch. Haga clic en este icono. Y luego se ve un montón de opciones. Ve a la sección pull, push, y luego ves la opción para buscar los cambios. Una vez que haces clic en él por primera vez, posible que te aparezca un mensaje preguntándote si quieres que Visual Studio Code lo haga automáticamente cada vez, en realidad puedes decir que sí, porque git-fetch se considera operación segura. Y como no va a tener una implicación en tu directorio de trabajo, puedes realizarlo de manera segura sin tener que preocuparte por nada. Y una vez que haces eso, ves un status aquí. En mi caso, veo uno y luego flecha abajo 0, y luego ropa. No estoy seguro si es capaz de ver esto. Pero una flecha hacia abajo significaría que tenemos commits adicionales en repositorio remoto, que se pueden fusionar en un depositario local. 0 o pyro significa que no tenemos ningún compromiso adicional o depositario local que necesitamos para subir nuestro push al repositorio remoto. Vamos a hablar de cómo podemos impulsar nuestros cambios al repositorio remoto en las próximas conferencias. Una vez que tengas eso, digamos que has decidido realizar mucho. Vamos a usar este plugin de terceros para eso. Y aquí puedes ver que la nueva rama de características de origen está apuntando a este commit y nuestra nueva rama de características local está apuntando a este commit en particular. Ahora adivina qué? Necesito fusionar estas dos ramas para tener todos los cambios remotos en mi directorio de trabajo. Entonces en Visual Studio Code, necesito hacer clic derecho en la rama que quiero fusionar. Y luego se ve esta opción. Fusionar en rama actual, nuestras sucursales actuales, nueva rama característica como se puede ver aquí. Entonces vamos a dar clic en él. Por cierto, para explicar las cosas que han devuelto el proyecto a cómo estaba antes de fusionarse. Entonces haga clic derecho sobre él. Rama de corriente magenta. Ya hemos hablado de este prompt. Es exactamente el mismo prompt. Nada diferente. Pero no queremos crear un nuevo comentario sin embargo. Y ahora si vas al árbol de trabajo, ves este archivo, que es lo que estamos esperando. 77. 1007 Actualización de referencias locales con Git Fetch: Digamos que me gustaría eliminar una sucursal en el repositorio remoto. Ahora, ¿cuáles serían sus implicaciones? Echemos un vistazo. En primer lugar, antes de eliminar la rama, necesitaba asegurarse de que todos esos cambios se fusionan en otra rama. También es necesario discutir con todas las personas que están activamente involucradas en contribuir a esa rama en particular. Antes de eliminarlo. Sigamos adelante y eliminemos una de las ramas. Y voy a eliminar la característica a ramificar haciendo clic en este icono. También puedes eliminar una sucursal remota de tu máquina local, explotará eso en próximas conferencias. Digamos que esta es una de las computadoras de los desarrolladores tal vez mira aquí si ejecuto el comando git remote show origin, te darías cuenta que Git ha mostrado esta característica para ramificarse como rancio. Y también nos ha indicado utilizar este comando git remote propenso a eliminar esta rama, promover sistema local. Alternativamente, también puede ejecutar el comando git fetch escoba. Con este comando, git se conectará al repositorio remoto. En este caso, se pondría por defecto al remoto de origen. Y luego eliminará todas las diferencias en su inscripción local que ya no están en uso en el repositorio remoto. Ahora, tome nota de que este comando sólo eliminará las ramas de rastreo, pero no sus sucursales locales. Tu sucursal local seguiría intacta. Entonces vamos a ejecutar este comando. Por lo que esto ha eliminado la rama de rastreo. Si quieres hacer lo mismo desde Visual Studio Code, basta con dar clic en este icono. Ir a sección de tracción y empuje. Y luego encontrarás esta opción que dice Fetch poda. Eso haría el mismo trabajo que con este comando. Ahora ya que tienes una pizza local para ramificar sigue intacta. Y también podrías estar teniendo tu propio conjunto de cambios o commits en función a rama. Bueno, puedes empujar todos esos commits al repositorio remoto. Y así se recrearía esta rama. O también puedes hacer que esos comentarios formen parte de alguna otra rama. Vamos a hablar de git push en próximas conferencias. Pero intentemos ejecutar de nuevo este comando. Y ya no vería característica para ramificar bajo sección de sucursales remotas. Permítanme volver a GitHub y restauré esta sucursal. Una vez más. Ejecuta el comando Ahora. Entonces dice que cuando hagamos la siguiente búsqueda, crearía una nueva rama de seguimiento para que la característica se ramifique. Hagámoslo muy rápido. Y se puede ver que la característica a ramificar ahora se está rastreando donde esencialmente en el mismo estado que con el inicio de este video. Nos vemos a continuación. 78. 1101 entender el Git Pull: Hablemos de git pull. Ahora dilo conmigo. Git pull es igual a git-fetch más git merge o rebased dependiendo de la opción que elijamos. Eso es esencialmente lo que es bueno Pull. Quizás este sea el video más corto de todo el curso. Sin embargo, puede que no sea tan sencillo. Vamos a hablar de buen tirón más detalle en próximas conferencias. Nos vemos a continuación. 79. 1102 Git Pull en acción y observar lo que hace: De acuerdo, Digamos git pull en acción. Actualmente soy una nueva rama de funciones. Déjame probarlo primero en el comando git pull. Y dice ya al día. Eso significa que no hay comentarios adicionales y repositorio remoto que no estén ya presentes en nuestro repositorio local. Así que primero es volver al repositorio remoto y hacer una nueva commit en la rama de características o la nueva rama de características. En realidad voy a editar uno de los archivos. No importa si agregas un nuevo archivo o editas un archivo existente. El punto es hacer un commit. Entonces déjame seguir adelante y dar clic en este ícono para editar este archivo. No estoy seguro si es capaz de ver esto. Déjame acercar un poco. Así que permítanme añadir una línea de texto, algo de ese tipo. En realidad no importa lo que agregues. Haga clic en Comprometerse cambios. Si desea obtener el mensaje, puede cambiarlo y hacer clic en Comprometerse. Por lo que ahora tenemos commit adicional y repositorio remoto, pero eso no está disponible en nuestra máquina local. Ahora antes de ejecutar el comando git pull una vez más, déjame hacer git log y ver qué tiene que mostrar. Como puede ver, la nueva característica así como la nueva característica de origen, que es la rama de seguimiento, están apuntando exactamente a la misma commit. Déjame borrar la pantalla y ejecutar el comando git pull. Como puedes ver inicialmente ha realizado la operación git fetch y ha desempaquetado los nuevos objetos. Entonces estos son los objetos que se descargaron del repositorio remoto. Hay un total de tres objetos, que también incluye objetos commit, tres objetos, objetos blob, etcétera. Y luego se adelantó y realizó fusión de avance rápido en este caso. Debido a que la fusión de avance rápido funciona en este caso, no tenemos ningún commit en una sucursal local. Y así git ha realizado una fusión de avance rápido para nosotros. Ahora si hago git log, puedes ver que la nueva rama de características local, así como la rama de seguimiento, están apuntando a este nuevo commit, que es exactamente el commit que se hizo solo un momento hace. Es f phi doble d, lo que sea. Y es el mismo HashCode que ves aquí. Anteriormente con git-fetch, nuestra sucursal local no se actualizó. Pero con git pull, no sólo hemos buscado todos los objetos y referencias, sino que también hemos actualizado la rama de puntos actualmente comprobada. Algo que debo mencionar es que todo el buen comando pull descargaría los objetos y referencias pertenecientes a múltiples ramas o incluso a mandos remotos. Se va a rendir mucho en la sucursal actualmente comprobada. Entonces cuando hicimos git pull, esto es equivalente a git pull origin porque este es solo el modo que está configurado actualmente y es el predeterminado. Pero si lo deseas, también puedes especificar el control remoto desde donde te gustaría buscar objetos. Y luego realizar la fusión en la rama de puntos actualmente comprobada, que en este caso es nueva rama de características. Nos vemos a continuación. 80. 1103 entender el Git Pull con fusión de 3way: Ahora veamos qué pasaría si tenemos commits realizados tanto en depósito remoto como local. Esto es para simular un escenario donde podrías tener commits realizados en tu repositorio local, así como pocos comentarios realizados en el repositorio remoto podrían ser de otros desarrolladores también. Entonces, para simular este comportamiento, primero intentemos hacer un commit en nuestro repositorio local. Si ejecuto git pull, ves que nuestro repositorio ya está actualizado. Déjenme rápido, hice uno de los archivos aquí. Editemos este archivo, por ejemplo. Guardado el archivo, se queda el archivo. En realidad puedes hacer todo esto desde Visual Studio Code, pero es solo mi preferencia personal hacerlo desde Git Bash. Me siento más como programador cuando lo hago desde Git Bash versus usando Visual Studio Code. Por lo que git añadir apple dot TXT. Buen mensaje de commit. E hicimos nuestro compromiso. Pasemos a nuestro repositorio remoto y hagamos algunas ediciones y archivo input.txt. A lo mejor me gustaría agregar una línea más de texto así. Y cometer esos cambios. Ahora puedes esperar el comportamiento cuando intentamos hacer git pull? Ahora, imagina que realizamos git-fetch y luego realizamos git merge. Qué es lo que esperas que suceda es exactamente lo que pasaría si ejecutas el comando git pull. En realidad, no tenemos que especificar el modo. Como puedes ver, nos ha incitado a elegir el mensaje. ¿ Puedes adivinar de qué se trata todo esto? Bueno, este es el mensaje get nos pide que vayamos por el nuevo objeto merge commit que va a crear. Esto ha realizado esencialmente la fusión de tres vías. Y get ahora va a crear el commit de fusión también. Digamos que estoy contento con este mensaje. Simplemente voy a cerrar eso. Y mando seguiría ejecutándose. Esta vez. Si hago git log, puedes ver que la rama local está apuntando al nuevo commit de fusión. Pero la rama de seguimiento, como se esperaba, sigue apuntando al commit al que apunta su rama remota correspondiente. Este es el commit que acabamos de descargar del repositorio remoto. Ahora, ¿qué pasa si no quiero tener este commit de fusión adicional creado por git, rebase es la respuesta. Y de eso vamos a hablar en nuestro próximo video. Nosvemos a continuación. 81. 1104 GIt tirar con rebase y sus implicaciones: De acuerdo, veamos cómo podemos usar rebase con git pull. Si ejecuto el comando git pull, se puede ver que ya está actualizado. No hay objetos adicionales para descargar del repositorio remoto. Pero déjame intentar hacer un commit en el repositorio remoto. Y 1 segundo, simplemente voy a editar este archivo y hacer un commit. Así. Permítanme hacer un compromiso en nuestro depositario local también. Voy a editar este archivo usando el editor VI. Puedes usar Bloc de notas o Visual Studio Code. Dependede ti. Llegar a la etapa de este archivo, git commit. Ahora vamos a tratar de hacer git pull rebase opción y ver qué va a pasar. Desde a través de la realización de la fusión, obtener palabra. Ahora intenta realizar rebase. Lo que hace este comando es que descargará todos los objetos y se comprometerá. Esencialmente nuestra sucursal local estaría en el mismo estado que con esta sucursal en el repositorio remoto. Y luego get volverá a aplicar todos los commits de límite local uno por uno. Después de ella. Yo te enseño a lo que me refiero. Por lo que esto ha descargado los objetos y también realizado rebase. Pero si ejecutas el comando git log ahora, notarías que todos estos comentarios hasta este punto son esencialmente los mismos que el comercio que tenemos en el repositorio remoto. Y encima, get ha reaplicado los comentarios hechos localmente. Esto es lo mismo que has clonado el proyecto desde un repositorio remoto. Y luego hiciste tus commits locales uno por uno. Esto se puede ver mejor en Visual Studio Code con el complemento Git. Entonces aquí estamos. Como se puede ver, cómo estos comentarios en la parte inferior pertenecen al repositorio remoto. Se lo puedes decir mirando la sección de autos. Por lo que todos estos comentarios fueron hechos por Centre Corp. y encima de eso, ha rebasado nuestros commits locales encima de los commits remotos. Y por eso vinieron tras ellos. Pero si te das cuenta, no tenemos ese commit de fusión que teníamos antes. Pero ese es el propósito de rebase, que es esencialmente no tener esos commits de fusión. Rebase esencialmente reescribe tus commits e incluso HashCode no sería lo mismo. Por ejemplo, si echas un vistazo a la última commit que has hecho depositario local, el hashCode actual es phi para ser lo que sea. Si tuvieras que echar un vistazo a este commit exacto antes de rebase, el hashCode habría sido diferente. Ahora bien, esta es la razón por la que todo rebasado hace que nuestra historia de commit se vea más lineal. No se debe rebasar si ya tienes todos tus cambios publicados en el repositorio remoto. Vamos a hablar sobre git push y cómo podemos empujar tus commits locales al repositorio remoto en las próximas conferencias. Y entonces tendrás mejor claridad en cuanto a lo que estoy hablando. Nosvemos a continuación. 82. 1105 Cómo lidiar con conflictos con la rebase de Git Pull: Veamos qué pasaría si hubiera algún conflicto mientras lo realizaba. Para eso, permítanme una vez más editar este archivo. Simplemente voy a agregar una línea más de código, así. Y cometer los cambios. Hemos hecho ediciones un archivo info dot TXT. Déjame leer el mismo archivo incluso en mi repositorio local o en mi computadora local. Permítanme agregar una línea de texto como para guardar el archivo, escenificar el archivo, y hacer un commit. Nueva edición, archivo info, lo que sea. Ahora déjame intentar hacer git pull y deberíamos tener un conflicto. Quiero usar la opción de rebase porque no quería ver el commit de fusión. Pero depende de ti. Ycomo pueden ver, nuestro repositorio entró en estado de rebase. Si no brindamos esta opción, entonces esto hubiera sido la fusión del estado a. la forma en que tenemos para resolver los conflictos de una u otra manera. Ya hemos visto cómo podemos resolver conflictos en consigue off, fusionar así como rebasar en nuestros capítulos anteriores. Lo mismo aplica aquí también. Por lo que puede decidir resolver los conflictos o puede usar este comando para omitir el commit que está causando conflicto. Yo voy a hacer precisamente eso. Pero si quieres editar y resolver los conflictos, ya sabes cómo hacerlo. Rebase tuvo éxito. Y cuando hago git log y no viendo el commit que acabamos de hacer en nuestro depositario local. Eso se debe a que habíamos proporcionado las opciones skip para omitir el commit que está causando extremos de conflicto. No estamos viendo que eso suba. Pero si notas las ramas de rastreo apuntando a la última commit en repositorio remoto, así, espero que tenga sentido. Nos vemos a continuación. 83. 1106 usando Stashing y reinicio duro: Hablemos de la importancia de guardar. Digamos que tenemos un nuevo comité y repositorio remoto. Por eso. Permítanme editar el archivo TXT de punto de entrada y agregar una línea de texto. Así. Comete los cambios. Y digamos que en mi inscripción local, voy a editar el mismo archivo y agregar una línea de texto así, guardar el archivo y cerrarlo. Ahora si voy a Git Bash y si fuera a ejecutar el comando git pull, fíjate que no he escenificado ni cometido esos cambios. No quiero comprometerlos porque sigo trabajando en ello. Al mismo tiempo, me gustaría sacar todos los cambios del repositorio remoto para tener actualizado mi directorio de trabajo. Cuando ejecute este comando, verás que Fetch ha ocurrido con éxito, pero la fusión no sucedió. Dice que tus cambios locales a los siguientes archivos serían anulados por fusión. En para R dxdy, por favor comete tus cambios son guardarlos antes de fusionarte, y por lo tanto ha abortado la operación mod. Esencialmente consigue esto confuso en cuanto a qué hacer con esos cambios no comprometidos. Una solución a esto es, y esto es algo que no se recomienda. El comando que estoy a punto de ejecutar en realidad puede eliminar todo el trabajo que has hecho hasta ahora en tu máquina local. Y eso también incluye los cambios que acabamos introducir para archivo de arte. Obviamente, este no es un enfoque recomendado. Pero déjame mostrarte el comando git reset. Ya hemos usado este comando en el pasado. Y luego vas a proporcionar la opción duro. Y tú especificarías el control remoto. A ver qué va a hacer esto. Si tecleo git log, vas a ver todos los comentarios que hemos hecho localmente o ahora se han ido para siempre. Y eso es lo que este comando es muy peligroso. Pero sirvió para el propósito de poder sacar los cambios del repositorio remoto. Si vas aquí, ves que sólo tenemos estos dos expedientes. Hagamos git pull para sacar todos los cambios del repositorio remoto. Y ahora nuestro directorio de trabajo está actualizado. Básicamente nuestro depositario local así como el repositorio remoto, o exactamente en el mismo estado. Pero este no es el enfoque recomendado obviamente. Entonces intentemos recrear una vez más el mismo escenario. Y déjame guiarte a través de cómo tenemos que lidiar con ello. No quiero cometer estos cambios. Pero al mismo tiempo me gustaría obtener las actualizaciones del repositorio remoto. Permítanme volver a GitHub y editar este archivo una vez más. Lo que sea. Vamos a tratar de hacer git pull ahora. Y obviamente, nuevo, vas a ver mucho abortarse. Así. Entonces, ¿cuál es la solución en estos momentos? La solución es git stash command. Básicamente, este comando almacenará temporalmente nuestros cambios locales en algún lugar y podremos recuperarlos cuando queramos. Por ahora, ya que nuestros cambios locales están causando problemas. Para sacar los cambios del repositorio remoto, déjame seguir adelante y guardarlos. Como se puede ver, guardado caminando por un árbol y fecha de índice, trabajando el progreso en nueva característica. Está apuntando al archivo input.txt. Si abres ahora en archivo TXT de punto completo, no vas a ver los cambios que acabo de introducir. Ahora podemos seguir adelante y hacer git rebase. Regresar al directorio de trabajo. Deberías estar viendo todos los cambios remotos. Ahora podemos traer de vuelta todos los cambios en los que estaba trabajando anteriormente con el comando git stash, pop. Ahora obviamente tendremos el complejo puede volver atrás y abrir el archivo input.txt. Verás que estos son los cambios que vienen de aguas arriba. Upstream como en el repositorio remoto. Podemos decidir en cuanto a qué cambios queremos seguir editando este archivo, como celda, cerrar el archivo, se queda el archivo. Estado de Git. Ahora si decido cometer mis cambios, puedo hacerlo. Pero capaz de sacar los cambios del repositorio remoto sin tener que comprometer nuestros cambios existentes. 84. 1201 Cómo configurar todo para contribuir a agregar credenciales de colaboradores Cómo establecer y hacer c: De acuerdo, veamos cómo podemos empujar nuestros cambios locales o los commits locales al repositorio remoto para que todos los demás en el equipo puedan realmente descargar esos cambios y usarlos todos, comenzar a caminar encima de ellos. Ahora para explicar mejor las cosas, limpiemos las cosas y hagamos todo desde cero como si alguien se acaba de unir al equipo y dispuesto a contribuir a nuestro repositorio. Lo primero es lo primero, déjame iniciar sesión como propietario del repositorio. He iniciado sesión como Sunda. Esta es la cuenta de Saunders GitHub. Y aquí está el dueño de este repositorio público. Voy a ajustes y luego voy a agregar al señor Luke como colaborador. Espero alguna contribución del señor Luke a este repositorio. Como pueden ver, acabamos de agregar al señor Luke como colaborador. También he eliminado todas las ramas que habíamos creado antes, excepto que dejé la rama principal tal como está. Por lo que actualmente tenemos una sucursal. Acaban de eliminarse todas las ramas. Sólo para que entendamos todo limpio y claro. Ahora vamos a la cuenta de Luke. Se nota que esta es la cuenta de Luke porque esta tiene el tema blanco. Aquí el correo electrónico que está bajo ha recibido para aceptar la invitación para ser colaborador en ese proyecto. Yo voy a hacer precisamente eso. Lo siguiente que debe hacer ese loop es copiar el enlace HTTPS y clonar el proyecto. Para ello de hecho creó un nuevo directorio con el nombre get. Y aquí es donde vamos a experimentar con las cosas. Déjame lanzar Git Bash aquí. Y clonemos el proyecto git clone. Y luego voy a pegar la URL. Esto va a clonar el repositorio. Una cosa más que debemos asegurarnos es sobre las credenciales. Tecleemos la opción de comando git config list para que podamos ver todas las configuraciones. Y como pueden ver, el nombre de usuario es mi nombre y el correo electrónico es algo diferente, no el de Luke. Ahora bien, esto no es algo obligatorio que necesites actualizar estas credenciales. Pero cuáles son las credenciales que usted da aquí es lo que se reflejaría también en objetos concretos. Por lo que cuando haces commits locales, estas credenciales se registrarían y las mismas credenciales se verían incluso en el repositorio remoto. Una vez después de empujar todos esos commits al repositorio remoto, tiene más sentido tener aquí las credenciales de Luke porque él es quien está contribuyendo al repositorio. Entonces sigamos adelante y cambiemos estas credenciales. User.name. Voy a dar el mismo nombre de usuario que tiene con la cuenta GitHub de Luke. Eso también es cambiar el correo electrónico al correo de Luke. Así. Ahora si revisas las credenciales, puedes ver que los que están actualizados. Ahora supongamos que a Lucas se le dio la tarea de trabajar en el largometraje uno. ¿ Adivina qué va a hacer? Bueno, crearía otra rama y aportaría todos los cambios relacionados con la característica uno. Hagámoslo muy rápido. Eso lo voy a hacer desde el código de Visual Studio. Si lo desea. puedes hacerlo desde Git Bash. Voy a abrir la carpeta con VS Code. Y tal vez sólo agregaré un archivo adicional. Pero antes de eso, necesitamos crear una sucursal. Como puedes ver actualmente estamos en sucursal principal. Déjame hacer clic en él y déjame escribir en la característica uno. Todavía no tenemos esta sucursal. No tenemos esta sucursal ni siquiera en el repositorio remoto. Permítanme seguir adelante y elegir esta opción para crear esta sucursal para nosotros. Visual Studio Code ha creado esta rama, y también ha cambiado a esa rama. Ahora déjame seguir adelante y agregar un archivo. Llamémoslo producto punto TXT. Línea uno, característica uno, algo de ese tipo. Voy a usar el mismo texto que el mensaje de commit. Introduzcamos el mensaje y comprometamos estos cambios en la característica local una rama. Hagamos tal vez también una línea de comentario más para que me guste así cuándo copiarla y tenerla como mensaje para este cometa. Echemos un vistazo a la gráfica. Como se puede ver, tenemos la rama principal aquí y la rama característica, que es un par de comentarios por delante de la rama principal. Supongamos que Luke ha hecho lo que tenga que hacer por el largometraje uno. Ha probado todos esos cambios localmente. Y ahora está dispuesto a contribuir o empujar todos estos commits al repositorio remoto. Cómo va a hacer eso es algo que hablaremos a continuación. 85. 1202 Creación de una rama remota y empujar los cambios con Git Bash y VSCode empujar a todas las ramas: Actualmente tenemos una rama característica que fue creada localmente, e incluso hemos hecho un montón de comentarios en ella. Ahora veamos cómo podemos empujar todos estos commits al repositorio remoto. Pero antes de hacer nada, esto es muy importante. Debes asegurarte de extraer todos los cambios del repositorio y rebasar, cualquiera que todos los cambios del repositorio y rebasar, sea la marca en la que quieras fusionar tu característica una rama. Querría tirar de todos los cambios de esa rama y reconstruir su característica una rama a esa rama. Entonces eso tendrá una historia de commit lineal. Y si te encuentras con algún tipo de conflictos, amablemente resolverlos para que no tengas conflictos cuando realmente empujes todos tus cambios o subas realmente empujes todos tus cambios o todos tus cambios al repositorio remoto. Ya hemos visto cómo se puede hacer esto en nuestro capítulo anterior. En nuestro caso, sin embargo, la rama principal y la característica en rama no han divulgado. No tiene sentido para mí rebasar realmente. Ahora veamos cómo podemos empujar nuestros cambios al repositorio remoto. Veamos primero cómo podemos hacer eso desde Git Bash. Déjame despejar la pantalla. Entonces vamos primero a entrar en ese directorio. Y actualmente estoy en función una sucursal, como pueden ver aquí. Pero en realidad no importa para el comando que estamos a punto de ejecutar. Voy a decir git push y obtener esto diciendo que la característica de rama actual uno no tiene rama ascendente. En otras palabras, está diciendo que no tenemos una rama característica en el repositorio remoto para empujar la rama actual y establecer el remoto como upstream. Utilice este comando en particular. Entonces déjame copiarlo y pegarlo aquí. Entonces este comando esencialmente crearía una rama en el repositorio remoto, empujando todos los commits que tenemos en esta rama. El origen es el control remoto que estamos usando. Si desea utilizar algún otro control remoto, puede especificar el nombre aquí. Y esta opción en realidad nos permitirá crear la sucursal en el repositorio remoto. Este comando también creará la rama principal de la pista y todo el depositario local para característica una rama que representa la entidad una rama en el repositorio remoto. Intentemos ejecutar este comando. Git esencialmente ha comprimido todos los objetos y los ha subido al repositorio remoto. Y este es el URI que ha utilizado para empujar todos nuestros commits. Además de eso, también ha creado una sucursal de rastreo para nosotros. Y también nos está sugiriendo crear la llamada pull request. Al ir a esta URL. Vamos a hablar de las solicitudes de pull en próximas conferencias. Pero por ahora vayamos al repositorio de GitHub y veamos si las cosas se reflejaron por allá. Déjame refrescar esta página. Y ahora se ven dos ramas. E incluso podemos cambiar a contar con una rama así. Y se ve aquí para los cometas, dos de ellos pertenecen a rama principal. Y luego hay un par de comentarios en característica una rama. Hagamos rápidamente un comentario más y veamos cómo podemos empujar nuestros cambios usando el código de Visual Studio. Así que permítanme simplemente agregar una línea más de código o texto. Así. Voy a usar el mismo texto que el mensaje de commit. Permítanme guardar este archivo y comprometer nuestros cambios. Entonces acabamos de hacer un commit más. Esta vez voy a usar Visual Studio Code para empujar nuestros cambios. Ves esta opción, empuja. Ya que tenemos un solo remoto, que es el nombre origen. Por defecto, esto ha empujado a ese único remoto que está disponible. Si tuvieras configurado varios controles remotos, entonces obtendrías una opción para elegir ese control remoto donde quieres empujar todos estos cambios en 1 segundo. Volvamos a levantarnos. Y si refresco la página, también vas a ver ese nuevo commit. Puede haber instancias en las que desee empujar cambios pertenecientes a múltiples ramas. En cuyo caso, puede usar la opción para empujar todos los cambios pertenecientes a múltiples ramas. Sin embargo, no es recomendable. Siempre es una buena idea manejar una sucursal a la vez. También debo mencionar que la primera vez que intentaste empujar cambios, en realidad podrías obtener un mensaje para iniciar sesión en tu cuenta de GitHub. En mi caso, no me dieron ese café porque ya he iniciado sesión previamente. Déjame mostrarte lo que quiero decir. Permítanme abrir Credential Manager en Windows buscando en el menú de inicio. Y si voy a credenciales de Windows, verás una para GitHub. Y esto ha guardado las credenciales de la cuenta de Luke. Eso es porque ya había iniciado sesión y Windows es capaz de almacenar todas esas credenciales para que no tenga que ingresar estas credenciales. Cada vez que intentaba interactuar con el repositorio remoto. En caso de que veas un 403 mientras ejecutas el comando, entonces intenta eliminar estas credenciales y luego intenta ejecutar el comando una vez más. Entonces lo que se le pedirá que inicie sesión una vez más, inicie sesión y debe ser bueno para ir. Déjame en realidad quitarlo. Y déjame intentar empujar los cambios. Y como pueden ver, obtuve este prompt para la autenticación. Déjame ir a la cuenta GitHub de Luke, github.com, dispositivo de barra de inicio de sesión. Déjame entrar aquí este código. Control C y control V, continuar. Y artritis. Entremos al dispositivo de comida del autobús que se autenticaron. Y por supuesto, como no tenemos nada que empujar, mira este mensaje diciendo que todo está actualizado. Pero si vuelves aquí, vas a ver esta entrada una vez más. Nos vemos a continuación. 86. 1203 entender la solicitud de tirón para elevar una solicitud de tirón: De acuerdo, hasta ahora hemos creado la característica local una rama y luego hicimos un montón de commits en ella. E incluso hemos empujado todos esos cambios al repositorio remoto. Y aquí están todos esos cambios en el repositorio remoto desde la cuenta de GitHub. Por supuesto, como este es un repositorio público, cualquiera podría ver todos estos cambios. Ahora, loop no puede simplemente tratar emerger todos estos cambios en la rama principal. Hay ciertas prácticas a seguir. Y esas prácticas están en su lugar para asegurarse de que lo que entra en la corriente principal de la evolución, que es la rama principal, es el código limpio. Entonces, lo que tenemos que hacer a continuación antes fusionar esta característica una cambia en la rama principal, es en realidad levantar una solicitud de extracción. Ahora, ¿qué es una pull request? Se puede pensar en pull request como una solicitud de revisión. Esencialmente, le estás pidiendo a alguien, en otras palabras, a alguien tu equipo, a otros colaboradores o al propietario del repositorio que revise todos tus cambios antes de que puedan fusionarse en el corriente principal de la evolución, la rama principal. Y tal vez te estés preguntando por qué esto se llama pull request. Esa palabra podría tener sentido a medida que avanzamos en este curso. Pero por ahora puedes pensar en ello como estás haciendo una solicitud para tirar de toda tu característica uno cambia a la rama principal. Entonces vamos a ver cómo podemos plantear una pull request. Actualmente estoy dentro de la cuenta GitHub de Luke. Quiero ir a esta sección, pull requests. Actualmente no contamos con ningún quiz de producto. Vamos a crear uno haciendo clic en este botón. Nueva solicitud de extracción. Aquí vamos a poblar todos los cambios que hemos hecho en característica una rama. Cómo vamos a hacer eso es comparando nuestra característica una rama con una de las otras ramas. En este caso, vamos a comparar feature one branch con la rama principal. Entonces la diferencia entre los dos son los cambios que hemos introducido en función en rama. Aquí estoy eligiendo sucursal principal como una de las sucursales. Y la otra rama sería característica una rama. Entonces vas a decir lista de cambios introducidos y cuentan con una rama porque estos son los cambios que no estaban presentes en la rama principal. Y si tuvieras varios archivos involucrados en todos estos cambios, entonces estarías viendo todos esos cambios aquí también. Pero como todo nuestro genio se metió dentro de un solo archivo, Eso es lo que estás viendo aquí. Y dice mostrando un archivo cambiado. Pero en fin, aquí están toda la lista de commits, todos los archivos que en realidad fueron modificados con todos estos comentarios. Vamos a seguir adelante y crear pull request. Podemos escribir un resumen rápido de lo que se trata esta solicitud de extracción. Presentamos la característica uno, algo de ese tipo. Si lo deseas, también puedes dejar un comentario. Y vamos a dar clic en crear solicitud de extracción. Ahora en realidad estamos recibiendo esta opción que dice merge pull requests. Y si hago clic en una de estas opciones, esto en realidad va a resultar en la fusión todos los cambios de característica uno en la rama principal. No obstante, esta no es una buena práctica. Idealmente, queremos que alguien revise o cambie antes de fusionarlos en la corriente principal de la evolución. En este punto en el tiempo, Luke es capaz de fusionar realmente todos estos cambios. Hay una manera de restringir esto y vamos a hablar de ello a continuación. 87. 1204 Comprender las ramas protegidas Aplicar la regla de protección de sucursales Comentarios de los códigos de mandamiento: Veamos cómo podemos restringir a Luke de fusionar el código a menos que haya al menos una revisión hecha por otra persona. Para eso, déjame ir a alguna cuenta de GitHub al anochecer. Voy a ir a la sección de ajustes de este repositorio. Tengo sección de dos sucursales. Y aquí en realidad voy a agregar las llamadas reglas de protección de sucursales. Cuando agrego al menos una regla de predicción de rama para una rama en particular, esa rama se llama como una rama protegida. Todas las sucursales donde no tenemos ninguna regla de predicción de sucursales o ramas no protegidas. Sólo estar al tanto de esas terminologías. Serán útiles en un rato. Así que permítanme dar clic en este botón que dice Agregar reglas de producción de sucursal. Aquí podemos especificar el patrón de rama. En este caso, simplemente voy a decir principal. Por lo que a todas las ramas que coincidan con este patrón se les aplicarían todas estas reglas de producción. Por supuesto, sólo las reglas que habilitamos aquí se aplicarían en las ramas que coinciden con ese patrón. Ahora, vamos a hablar de algunas de estas reglas en próximas conferencias. Pero por ahora, me gustaría poner una restricción de que atlas one review se haga antes de fusionar los cambios en la rama principal. Por lo que voy a habilitar esta opción que dice requiere una pull request antes de fusionarse. Y la descripción de la misma dice, cuando habilitamos esta opción, Hall commits debe hacerse a una rama no protegida. Entonces en este caso estamos apuntando a la rama principal. Voy a aplicar esta regla de protección de sucursal en rama principal. Por lo que al habilitar esto, nadie sería capaz de comprometerse directamente en la rama principal. Lo que tienen que hacer es que primero cometan todos los cambios en rama no protegida. Por ejemplo, cuenta con una rama que no está protegida, y luego levanta una solicitud de extracción para fusionar todos esos cambios en la rama principal. Eso es lo que esta opción está diciendo. Si esto suena confuso, te pediría que simplemente regresaras y veas este video una vez más hasta que lo entiendas. Y luego tenemos esta opción que dice aprobaciones requeridas. Y aquí llegamos a elegir número de aprobaciones. Necesitamos nuestro número de aprobaciones de revisión de código que necesitamos antes de poder fusionar esos cambios bajo la rama principal. Dejémoslo al predeterminado. Y vamos a dar clic en Crear. Una vez más, vamos a hablar cómo gobierna la otra predicción de rama en próximas conferencias. Permítanme ingresar rápidamente la contraseña. Y tenemos una regla de predicción de rama creada para la rama principal. Ahora volvamos a la cuenta GitHub de Luke. Si recargo la página esta vez, luke ya no sería capaz de fusionar esos cambios. Y mira ahora está viendo revisión requerida. Ahora por defecto, cualquier colaborador en el equipo o el propietario del repositorio puede realmente ver los cambios. Si querías cambiar ese comportamiento, entonces necesitamos realmente tomar una de esas membresías empresariales de GitHub para que obtengamos todo ese control de grano fino. Por el momento. No tenemos control sobre eso. 88. 1205 Revisar y aprobar los cambios Trabajar en comentarios de revisión y publicar nuevos cambios: Entonces vayamos a algunos ahí segundo, a revisar los cambios hechos por el señor Luke. Esto también puede ser cuenta de algún otro colaborador en este repositorio. Ellos también lo pueden revisar. Y lo que tienen que hacer para revisar todos los cambios realizados por Luke es que van a entrar en la sección Pull Request. Haga clic en él. Y después habrá podido ver esta opción, agrega tu reseña. Y aquí en realidad pueden revisar todos los cambios. Si no están contentos con alguno de estos, entonces en realidad pueden dejar un comentario diciendo, por favor actualice otra línea, algo de ese tipo. Y en lugar de elegir la opción que pro, voy a establecer cambios de solicitud, lo que significa que no estoy muy contento con el código introducido. Quiero buscar traer estas actualizaciones en base a mi comentario. Entonces quiero revisar de nuevo. Por lo que vamos a dar clic en Enviar revisión. En la cuenta de Luke. Él va a decir que esto cambia o solicita. Podrá ver la reseña. Así. Aquí el comentario hecho por cilindro. Por favor, actualice otra línea. Entonces, lo que Luke va a hacer es en realidad va a traer todos los cambios basados en el comentario del revisor. Algo de este tipo. Comprometamos este cambio. Podemos empujar todos esos cambios. O alternativamente, podemos hacer clic en este botón que dice cambios de sincronización. Entonces esto va a empujar nuestros cambios. Y si hay algún cambio que tirar hacia arriba, hágase también. Volvamos a GitHub. Y estos cambios debieron haber sido presente y futuro una rama. Y como pueden ver, somos capaces de ver ese nuevo commit. Ahora no tenemos que plantear otra solicitud de encuesta. La solicitud de pool existente se rellenaría automáticamente. Volvamos a la cuenta de remitentes muy rápido. Y Nelson lord es capaz de ver una actualización diciendo que se ha hecho un nuevo commit. Normalmente se ven bien para enviar un recordatorio por correo electrónico o algo así. O podría haber algún tipo de herramienta que enviaría automáticamente un recordatorio por correo electrónico a todos los revisores. Entonces remitente vería todos los cambios y revisaría todos los cambios y asumiría que está muy contento con los cambios, los va a proteger y diciendo algo de ese tipo y va a aprobar los cambios como celular. Volvamos a la cuenta de Luke. Ahora mira en bar de la Marcha. Vamos a hablar de ello Arriba a continuación. 89. 1206 Explorar las opciones de fusión Understading Squashing commits Eliminación de rama remota de lo: Ahora que la revisión está hecha y los cambios son aprobados por uno de los revisores, Luke es bueno para seguir adelante y fusionar todos estos cambios de característica uno en la rama principal. Si tomas licencia de Organización de GitHub, obtendrías un control más fino. Los dos últimos en realidad pueden fusionar las solicitudes de extracción en este momento con la versión gratuita de los colaboradores de su proyecto sería capaz de fusionar las solicitudes de extracción, incluyendo el individuo que levanta el tirón solicitudes. Entonces todo el en este caso, Luke en realidad está tratando de fusionar su propia pull request. Proyectos en tiempo real. Este sería uno de los lideres del equipo o alguna persona que esté autorizada para realizar este trabajo. Echemos un vistazo a todas las opciones que tenemos aquí. Podemos crear un commit de fusión. Y como su nombre indica, esto esencialmente va a crear un nuevo commit de fusión en la rama principal. Y apunta a un par de commits de padres. Uno de los padres sería el último commit fuera de la rama principal, el otro KM padre, sería el último commit fuera de la rama de la característica. Ya hemos discutido sobre las confirmaciones de fusión. No tengo que reiterar una vez más. Y por no hablar enter commit se conservaría la historia, lo que significa que bien podrías estar teniendo todas las historias de los cometas de espaguetis. Si no quieres tener el historial de commit de spaghetti y no quieres crear commit de fusión adicional. Entonces puedes ir con la tercera opción que dice rebajas y fusionar. Por lo que todos los cuatro commits de esta rama, que es una rama de características, se rebasarán y luego lo agregarán a la rama base que el historial de commit en la rama principal se vea más lineal. También tenemos una tercera opción que es squash y merge. Y como dice la descripción del mismo, los cuatro commits de esta rama se combinarán en un commit en la rama base. Esto es tan bueno como estás haciendo una nueva confirmación en rama principal con todos los cambios combinados de la característica una rama. Esta podría ser la solución ideal si tienes montón de commits. Y tiene sentido combinarlos juntos. En nuestro caso, apenas hicimos cambios en cada uno de nuestros commits, tiene apenas cambio de una sola línea de texto. Entonces tal vez esta opción es lo ideal para hacer por nosotros. Esencialmente, si tienes múltiples commits donde hiciste cambios menores, y si crees que esos se pueden combinar como un solo commit, podemos ir con esta opción. No estoy seguro de si eres capaz de recobrar, pero cuando hablamos de rebase interactiva, tuvimos la opción de squash algunos de los commits. Básicamente, cuando estés realizando una rebase interactiva, puedes enumerar hacia abajo todas las confirmaciones que quieras squash o combinarlas juntas. Entonces digamos que tienes diez commits en tu rama de funciones. Puedes machacar cuatro de ellos o tres de ellos o lo que sea que tenga sentido para ti usando rebase interactiva. Si no te acordaras, te recomendaría volver a ver la interacción con la mejor conferencia sobre las mismas. Por ahora, vayamos con esta opción, rebasar y fusionarnos. En la mayoría de los casos sería merge commit o Rebus y merge dependiendo de tus requerimientos. También debo mencionar que como ya habíamos rebasado de la rama de características a la última commit off main branch antes de que realmente levantáramos la solicitud de extracción, habíamos resuelto todos los conflictos potenciales antes de realmente levantar las solicitudes de pull. Y por eso a estas alturas, no estás viendo ningún conflicto. Pero podría haber esos raros casos en los que alguien más de tu equipo podría haber introducido cambios en tu sucursal principal mientras la solicitud de extracción aún está activa, lo que en realidad podría crear conflicto. Cómo lidiar con esos conflictos es algo de lo que hablaremos más adelante. Por ahora, sigamos adelante y Rebus y fusionémonos. Y como tarea, también puedes probar estas dos opciones. Bastante sencillo. Demos clic en rebajas y fusionemos. Vamos a confirmar. Así que la solicitud de extracción se fusionó y cerró con éxito. Y estamos bien para seguir adelante y eliminar esta rama en particular. Podemos eliminarlo de GitHub, o también podemos hacer lo mismo desde nuestra máquina local. Déjame mostrarte lo que quiero decir. Déjame abrir Git Bash aquí. Actualmente estoy dentro del proyecto. Permítanme ahora seguir adelante y eliminar la sucursal remota. Y el comando para eso es git, push origin, nombre del remoto. Y luego vas a usar dos puntos seguidos del nombre de la sucursal que deseas eliminar en el servidor remoto. Característica uno, en nuestro caso, voy a golpear Enter. Y esto debería eliminar la característica en rama en el repositorio remoto. Volvamos. Y como pueden ver, ahora sólo tenemos la rama principal. Y aquí la lista de commits en ella, que ahora también incluye todos los comentarios que se hicieron en la característica uno. Si hago git branch, todavía vas a ver la sucursal local. Déjame que me corrija el nombre. Todavía tenemos la sucursal local. Vamos a seguir adelante y borrarlo también. Rama Git, guión D, característica uno. De acuerdo, para cambiar a una rama diferente. Y volvamos a ejecutar el comando. Y se borró la sucursal. Dado que se eliminó la función remota en las ramas, incluso su rama de seguimiento correspondiente ya no está disponible. Nos vemos a continuación. 90. 1207 Lo que Git Pull realmente hace: Cada vez que intentes empujar tus cambios locales al repositorio remoto, git intentará fusionar nuestros cambios locales con la misma rama en el repositorio remoto. Pero lo hará solo si resulta en fusión de avance rápido o de lo contrario no logrará impulsar nuestros cambios y luego forma de trabajar alrededor de él para conseguirlo hecho. Sé que esto suena confuso y por eso he dedicado este video a hablar justamente de eso. Y para explicar mejor las cosas. En realidad voy a hacer todo desde cero. Déjame ir a cuenta de remitentes y crear un depositario completamente nuevo. Vamos a darle algún nombre al azar. En realidad no importa. De todos modos lo vamos a conservar temporalmente. Y vamos a añadir también uno de estos archivos sólo para que tengamos un commit en la rama principal una vez después de crear este repositorio. Permítanme añadir también característica de una rama se crean. Y luego hagamos un commit y contemos con una rama también, tal vez editando el archivo read me. Línea uno, característica uno. Llamémoslo línea a. En realidad no importa. Hagamosel commit. Pasemos a Ajustes y agreguemos al Sr. Luke como uno de los colaboradores. De acuerdo, ahora vamos a la cuenta de Luke. Por lo que Luke acaba de recibir una invitación para contribuir a ese proyecto. Se va a ver esa invitación y aceptar la invitación. Y luego va a clonar el proyecto en su máquina local para empezar a contribuir. En una de las carpetas. Voy a abrir Git Bash. Y hagamos git clone este proyecto. Vamos dentro de esa carpeta. Y si hago git branch, todo lo que ves que tenemos una sucursal Rachman remota de Maine así como una característica, pero no tenemos la sucursal local off feature one. Entonces, para conseguirlo, cambiemos a contar con una sucursal o checkout para contar con una sucursal. Por lo que en este momento se tendrá creada esa sucursal local. Y actualmente estamos en función de una rama. Hagamos el resto de las cosas del código de Visual Studio. Entonces abramos este proyecto con VS Code. Y digamos que me gustaría hacer un comentario en la nueva característica una rama. Por lo que actualmente estamos en la característica de una rama. Permítanme tal vez esta vez agregar un archivo, vamos a llamarlo un punto dx, dy. Voy a Source Control, doy un mensaje al commit y comprometo nuestros cambios. Ahora imagina que alguien más en el equipo que también está trabajando en la misma rama, empujó pocos cambios al repositorio remoto en la misma rama para simular ese comportamiento. Volvamos a la cuenta de remitentes y realicemos un commit en feature one branch como si alguien hubiera empujado los cambios a esta rama. Permítanme este término agregar otro archivo, tal vez dos puntos TXT. Y cometamos nuestros cambios. Ahora básicamente ambos son característica local en rama y su correspondiente rama remota o no divergentes. Veamos qué pasaría si intentara empujar nuestros cambios locales al repositorio remoto. Git push, podemos especificar el remoto y la característica de una rama. Pero si solo usas este comando, va a ser el comportamiento por defecto de todos modos. Entonces empujemos nuestros cambios y veamos qué va a pasar. Como puedes ver, tenemos un error que dice falló al empujar algunos refs a ese repositorio y actualizaciones para rechazadas porque los contenidos remotos funcionan que no tienes localmente. Entonces, como he dicho antes, cuando empujemos nuestro kit de cambios locales en realidad intentaremos fusionar o cambios locales con la misma rama en el repositorio remoto. En este caso, esto no está resultando en una fusión de avance rápido y eso es lo que consigue no empujó nuestros cambios. Entonces lo que podemos hacer aquí ahora es que podemos usar el comando git pull. Y por defecto también intentará realizar fusión de estas ambas sucursales en nuestra inscripción local. Entonces déjame probar git pull para tirar de los cambios. También podríamos hacer lo mismo desde el código de Visual Studio. Si lo desea. Por ejemplo, puedo decir git pull desde ahí o desde aquí. Tratemos de ver la gráfica ahora. Y como puedes ver, git ha intentado realizar merge feature one branch con nuestro profesor local one branch. Entonces este es esencialmente el commit de fusión. Ahora si intentas realizar una operación de empuje, debería tener éxito. Y entonces deberíamos poder ver este commit de fusión en el repositorio remoto también. Pero si quieres deshacerte de este commit de fusión, ya sabes qué hacer. Rebase es la respuesta. Así que intentemos rebasar nuestra rama actual, que es la característica de una rama en la parte superior del cambio reciente del repositorio remoto. Esencialmente estoy tratando de rebasar una característica local una rama con la rama de seguimiento remoto, que esencialmente representa la característica remota una rama. Entonces este es el commit al que apuntan las ramas de rastreo. Voy a hacer clic derecho sobre él. Y luego voy a elegir esta opción rebase, rama actual en esta comisión. Y rebasemos como parte del renacimiento, como ya hemos comentado antes en una de nuestras conferencias anteriores. También se deshará de todos los commits de fusión. Porque esencialmente estamos reescribiendo toda la historia del commit. Y este tipo de resuelve el problema de no tener muchos commits. Entonces ahora tenemos historia de commit lineal. Estamos bien para ir a empujar nuestros cambios. Esta vez. Esto va a resultar en una fusión de avance rápido tanto de la característica local en rama como de la característica remota una rama. Y entonces no deberíamos tener ningún tipo de problema ni de ningún tipo. Pero en términos generales, se debe tener cuidado con la operación de rebase. Y hay ciertas mejores prácticas a seguir, que es lo que vamos a discutir en próximas conferencias. No hay problema como tal en tener mucho commit. También puedes empujar tu comentario de fusión si lo deseas. Y, de hecho, es una de las opciones populares porque rebase podría en realidad estropear las cosas. Lo cual es de nuevo, algo de lo que hablaremos en próximas conferencias. Pero por ahora, estamos bien para ir a empujar nuestros cambios. Y es acertado ir al repositorio remoto. Ahora, cambie a una rama. Deberían estar viendo todos esos comentarios, incluyendo el compromiso local que habíamos hecho antes. Nos vemos a continuación. 91. 1208 Resolver conflictos en GitHub de la manera correcta que Fuerza empuja los cambios y sus consecuencias: Veamos cómo podemos lidiar con los conflictos cuando estamos tratando de fusionar característica uno en la corriente de la evolución, la rama principal. Actualmente estoy en función una rama y como pueden ver, tenemos todos esos cuatro commits de nuestras conferencias anteriores. Lo que voy a hacer ahora es que voy a plantear un pull request para todos los cambios que hemos introducido in vitro, una rama levantó pull request. Ahora en realidad soy bueno para ir a realizar cualquiera de estas operaciones. También puedo realizar reparaciones y mucho porque no se hicieron nuevos comentarios en sucursal principal y no hay forma de que pueda causar conflictos. Pero, ¿y si después de levantar la solicitud de extracción, alguien introduce nuevos cambios en la rama principal, lo que podría estar causando conflictos sin cambios de característica uno? Para simular ese comportamiento. Permítanme volver a la rama principal y editar este archivo. Si recuerdas, en uno de los comentarios in vitro y rama, sí actualizamos el archivo ReadMe. Entonces si actualizo este archivo una vez más en rama principal, esto debería darnos un conflicto. Así que déjame hacer clic en este archivo y agregar algún texto así, y comprometer los cambios. Ahora volvamos a la solicitud de extracción y veamos si ahora podemos realizar Freebase. Y ahora se ve un aviso que dice que la sucursal tiene complejo y esos se deben resolver. Aquí podemos resolver conflictos, pero no es un enfoque recomendado. En pocas palabras, esto va a complicar un poco las cosas. Básicamente, si miras la historia del chametz, te va a confundir. Hay una mejor manera de manejar esto. Y eso es lo que les voy a mostrar ahora en nuestra máquina local como él que esto se ve computadora. En primer lugar, vamos a traer todos los cambios en la rama principal. Entonces déjame cambiar a rama principal y sacó nuevo commit. Ahora vamos a tratar de rebasar nuestra característica una rama en la parte superior de este nuevo commit. Este es un procedimiento estándar que habíamos seguido en una de nuestras conferencias anteriores. qué estás basando a alguien para que vuelva a tener uno? Haga clic con el botón derecho en este compromiso y elija esta opción que dice rebasar la rama actual en este comité. Esto nos debe dar conflictos. Y como se esperaba, sí tenemos conflictos. Eso significa desestimarlo. Entonces resolvamos esos conflictos. A lo mejor esta vez quisiera aceptar ambos los cambios. Guarde el archivo, y déjenme declararlo y dar clic en Comprometerse. Esto va a crear esencialmente un nuevo commit con todos los conflictos de resultado. Introduzcamos algún mensaje. Me gustaría mantenerlo como está. Una vez que lo cierras. Esto debería rebasar cuál rama encima de ese nuevo commit. Así. Así que ahora todos los commits off que en rama o visto en la parte superior de este commit. Ahora intentemos empujar todos estos cambios al repositorio remoto y veamos qué va a pasar. Déjame despejar la pantalla. También podríamos hacer lo mismo desde Visual Studio Code. Déjame teclear el comando git push y ver qué va a pasar. 1 segundo nos llegó este dicho hetero, fallar al empujar algunas referencias al repositorio remoto. Eso se debe a que con rebase, enter commit history se reescribió y no coincide con el historial de commit que tenemos en el repositorio remoto. Ahora consigue bueno que nuestra característica local una rama y su característica correspondiente una rama en el repositorio remoto, o ambos divergieron. Y entonces no nos está permitiendo empujar nuestros cambios. Entonces, ¿cómo empujamos nuestros cambios ahora al repositorio remoto? Bueno, podemos usar la fuerza de opción. Entonces esta vez con git push y cuándo proporcionar la opción force. Ahora, ¿qué va a hacer esto? El indicador de fuerza hará que la sucursal de los repositorios remotos coincida con su sucursal local. Y eliminará todos los cambios de aguas arriba que podrían haber venido desde la última bala. que también significa que si hay múltiples personas trabajando en la misma rama y si alguien hubiera aportado sus cambios a la misma rama, se perdería todo el trabajo, que es a veces no deseable. Por lo que hay instancias en las que no deberías estar usando la opción de fuerza. Vamos a hablar de todo eso y las mejores prácticas en próximas conferencias. Pero por ahora, esto nos va a hacer el trabajo. Y si vuelves al repositorio remoto, notas que ahora podemos realizar rebase y fusionar o incluso otras dos opciones. Echemos un vistazo a la historia del commit muy rápido. Para ir a contar con una sucursal. Echa un vistazo a la lista de commits. Por lo que tenemos todos estos comentarios realizados en función de una rama apilada en la parte superior de los comentarios de la rama principal. Ahora podemos seguir adelante y realizar rebajas y fusionar. También podemos disolver el complejo y GitHub, pero va a hacer cosas raras como Robeson, la rama principal encima de cual una rama para hacer las cosas. Y eso podría crear mucha confusión. Pero esta suele ser la práctica común que se sigue para resolver el conflicto. Ahora no tiene sentido tener la rama alrededor. Paraque pueda borrarlo. Espero que tenga sentido. Nos vemos a continuación. 92. 1209 Divide y estrategia de Conqr: Veamos cómo podemos manejar las consecuencias negativas del uso de la opción de fuerza. Cuando se utiliza el comando push. Mencioné que cuando uses la opción force, el historial de commit en el servidor remoto se sobrescribirá forzosamente con tu propio historial local. Ahora hay un par de consecuencias con eso. Número uno, podríamos estar teniendo múltiples desarrolladores trabajando en la misma rama y podríamos arriesgarnos a perder todos los commits realizados por ellos que vinieron después de tu última encuesta. Y en segundo lugar, lo más importante, cuando haces Rebus y luego fuerza, empuja tus cambios, realidad podría crear un desastre porque todos los demás en el equipo podrían haber descargado el proyecto y podría haber ido a esa sucursal. Esencialmente, cuando rebasas y pausas push tus cambios no solo fueron leyendo el historial de commit, sino también sus códigos hash. Y todos los miembros del equipo que podrían haber descargado el proyecto y Chet dot a esa sucursal podrían tener un conjunto diferente de historia común en comparación con lo que hay en el repositorio remoto. Eso va a crear mucho lío. Entonces para evitar esto, tenemos una estrategia llamada divide y vencerás. Déjame explicarte lo que quiero decir. Digamos que esta es la rama principal y esta es la rama de características en el repositorio remoto. Ahora supongamos que un par de desarrolladores están dispuestos a contribuir a esta rama. En lugar de que ambos están contribuyendo a esta rama. Ahora vamos a tener un par de sub-sucursales y cada una sería propiedad de desarrollador individual. Tanto este dólar per aportaría su propio conjunto de cambios en sus propias sub-sucursales. Y como están caminando en su propia sucursal, los cambios que se hagan en una rama no tendrán ningún impacto en la otra. Por ejemplo, uno de los desarrolladores puede querer rebasar y forzar la comisión todos esos cambios a su propia rama. Y no tendrá ningún tipo de impacto en la otra sucursal propiedad del desarrollador. Y una vez que uno de los desarrolladores haya terminado con lo que sea que tengan que hacer, pueden fusionar todos los cambios en la rama de la característica uno. Y entonces el otro par dólar rebasaría su sucursal en la parte superior de la característica una rama y luego eventualmente fusionaría sus cambios también. Y si hay algún cambio que cualquiera del dólar plus pudo haberse perdido, pueden crear otra sucursal y traer todos esos cambios. Y luego por supuesto, fusionar esos cambios en característica una rama. A esto se le llama estrategia de divide y vencerás. Y esto podría prevenir los efectos secundarios que podrían venir cuando fuerces empujar tus cambios. Sin embargo, puede haber casos en este enfoque no sea factible. En cuyo caso tenemos un suplente a, y de eso vamos a hablar a continuación. Pero tal vez puedas tomar esto como una tarea. Trate de crear un par de sub-ramas a partir de la característica una rama, y tratar de seguir divide y conquistar enfoque. 93. 1210 Resolver conflictos fusionando el principal en para incluir rama: De acuerdo, veamos cómo podemos lidiar con los conflictos fusionando las ramas sin tener que usar la opción de fuerza, o siguiendo el enfoque de divide y vencerás. Para eso, intentemos primero crear otro conflicto. Como ya hemos eliminado feature one branch, vamos a crear una nueva rama para introducir nuevos conflictos. Llamémoslo nueva característica. Lo que sea. Voy a crear esta sucursal. Y déjame editar uno de estos archivos. Digamos que me gustaría editar un archivo TXT de un punto. Y simplemente voy a agregar el nombre de la sucursal como celular. Comete los cambios. Permítanme cambiar de nuevo a la rama principal. Y tratemos de editar el mismo archivo una vez más, para que tengamos conflicto. Digamos simplemente principal y comprometamos los cambios. Ahora vayamos a pull requests e intentemos plantear una nueva pull request. Así que estamos comparando la rama principal con la nueva rama de características. Y aquí están los cambios. Déjame seguir adelante y crear la pull request. Como pueden ver, estamos recibiendo un mensaje que dice que esta sucursal tiene complejo que hay que resolver. Y también tenemos la opción de resolver conflictos. Qué bueno que nos permitiría resolver los conflictos es fusionando realmente la rama principal en la rama característica. Ahora bien, esto podría sorprenderte, pero en realidad funciona. Déjame mostrarte lo que quiero decir. Permítanme dar clic en resolver conflictos. Esto es como si estuviéramos en estado de fusión donde hay que resolver los conflictos. Y podemos resolver los conflictos así como los habíamos disuelto en nuestra máquina local cuando estamos tratando de fusionar ramas. Así que esencialmente en este caso, GitHub está tratando de fusionar rama principal en la nueva rama de características. Y eso esencialmente traería todos los cambios de rama principal o todos los comentarios de rama principal en la rama característica. Al igual que para mantener los dos cambios. Y voy a dar clic en este botón que dice Mark. Como resultado. Vamos a venir a la fusión. Esto va a crear una confirmación de fusión, y eso apuntará a un par de commits padre. El último comentario de la rama principal y el último commit fuera de la nueva rama de características. Bastante similar a lo que hemos hecho en nuestra máquina local cuando estamos tratando de resolver los conflictos. Mientras margen. Aquí puedes ver que acabamos fusionar main en la nueva rama de funciones. Y esto ha resuelto el problema. Para volver al repositorio, las commits en la rama principal permanecerían como esta. Déjame mostrarte. Pero mientras que si vas a la nueva rama de características, tiene todos los commits en ella en los comentarios que se hicieron y nueva rama de características y también el commit de fusión. Si entras dentro de eso, vas a ver que tiene pareja de padres. Uno de los padres es el último commit de la rama principal, y el otro es el nuevo comentario que acabamos de hacer en la rama de características. Por lo que esta instantánea de confirmación de fusión tendría cambios introducidos en ambas ramas. Y por eso somos capaces de ver todos los commits pertenecientes a ambas ramas. Ahora no estoy seguro de si esto te está confundiendo en realidad, pero esto es en realidad bastante sencillo. Si no entiendes esto, entonces eso está perfectamente bien. Ya hemos discutido un par de maneras de resolver los conflictos. En el último par de conferencias. Puedes ir con ese enfoque o también puedes seguir este enfoque. También puedes hacer lo mismo incluso en tu depositario local. Solo echa un vistazo al proyecto e intenta fusionar la rama principal en tu rama característica una, resuelve los conflictos para que tengas un historial de commit similar en tu máquina local. Y luego vas a empujar todos estos commits al repositorio remoto con el comando push estándar. Volvamos al pull request. Ahora ya no tenemos los conflictos. Esta rama no tiene conflictos con la rama base. Y estamos bien para seguir adelante y realizar merge. Sin embargo, no se puede realizar rebase. No se puede realizar rebase porque como ya sabe, rebase va a reescribir el historial de commit e incluso deshacerse de los commits de fusión. En este caso, no tiene sentido hacer eso. Eso suena confuso. Entonces solo recuerda que no puede realizar rebase. En este caso. Si intentas realizar rebase, dice que esta rama no se puede rebasar debido a lo complejo. El mensaje no es muy claro en realidad, pero espero que haya entendido el punto. Pero podemos fusionar los cambios y comprometerlos fusionar. Ahora podemos deshacernos de la nueva rama de características. Y esa es la forma alternativa de resolver el complejo. Nos vemos a continuación. 94. 1301 Qué es el entrenamiento y por qué el tenedor: Hablemos de para rey en GitHub y su significación. Imagina que tenemos un proyecto de código abierto con el nombre de aplicación abierta en el repositorio de GitHub. Y decir que esto es propiedad del señor Sunda. Ahora cuando digo que este es el proyecto de código abierto, puedes esperar cientos o incluso miles de desarrolladores en todo el mundo que estén dispuestos a contribuir a este proyecto. Ahora imagina la cantidad de trabajo que se ha hecho tiene que hacer para administrar a los colaboradores. Si cilindro qué administrar cientos o miles de colaboradores, se convierte en un trabajo por sí solo. Por ejemplo, cada vez que alguien quiere contribuir, ya sea una contribución pequeña o una contribución grande, todavía hay que sumarlas como colaborador. En segundo lugar, si se utiliza la versión gratuita de GitHub, entonces esencialmente cada colaborador, tendremos el privilegio de fusionar su código en la rama principal. Ahora imagina algún dólar principiante por quien acaba de empezar con la programación. Entregar algún código y módulo esos cambios en la rama principal sin hacer pruebas adecuadas. Obviamente, eso va a crear mucho lío. Por lo que necesitamos una solución a este problema. Bueno, la solución es bifurcar. Entonces, ¿qué es exactamente bifurcación? Imagina que tenemos al señor Luke quiere contribuir a este proyecto y no se le suma como colaborador en este proyecto. Entonces lo que Luke va a hacer es con solo un clic de un botón, ha ido a folk este repositorio en su propia cuenta de GitHub. Se puede pensar en trabajar como clon. Pero en lugar de clonarlo en la máquina local, va a suceder en la salva de GitHub en la cuenta de Luke. En este caso, Luke y renombra este proyecto a cualquiera que sea el nombre de su elección, o también puede mantener el mismo nombre. En realidad no importa. Como convención de nomenclatura estándar. El repositorio predeterminado se conoce como origen y el repositorio original se denomina upstream. Por supuesto puedes llamarlos con cualquier nombre de tu elección. Pero estas son las típicas convenciones de nomenclatura que seguimos como desarrolladores. Entonces cada vez que digo origen, me refiero al repositorio bifurcado. Siempre que digo aguas arriba, me refiero al repositorio original desde donde tenemos cuatro. Ahora mira, haremos un repositorio bifurcado de oficina clon, incluso en su máquina local. Después introducirá todos los cambios que necesite introducir y va a empujar todos estos cambios en el repositorio bifurcado. Mientras tanto, si hay alguna nueva actualización en el depositario original, mire y realmente jalando todos estos cambios en su depósito local y empuje todos esos cambios o nuevos commits a su repositorio bifurcado. De esa manera, el repositorio predeterminado se mantendrá actualizado, pero los cambios recién introducidos en los depositarios originales después Luca se haga con cuáles son los cambios que quiere introducir. Y por supuesto, después de pruebas adecuadas se va a plantear una solicitud de extracción, pidiendo a algunos de allí que acepten todos estos cambios y fusionen esos cambios en la rama principal del repositorio original. Por lo que esta vasija de ahí dentro no necesita escribir acceso para mirar para empezar a contribuir. Este enfoque de contribuir a un proyecto bifurcando el repositorio no sólo es bueno para el propietario del repositorio, sino también el dólar más uno para contribuir al proyecto. Estos son algunos de los vantage es para desarrolladores para usar bifurcación. En lugar de contribuir directamente al repositorio original. Caminar permite a cualquier persona contribuir a un proyecto sin tener el acceso correcto. Porque solo pueden crear un fork de un proyecto, introducir todos los cambios, probarlos y luego levantar pull request. Pueden experimentar libremente con los cambios sin afectar el proyecto original. En algunos casos, podría haber múltiples personas que colectivamente quieran contribuir a un proyecto en particular. En cuyo caso, siempre es mejor bifurcar el depositario original, eliminar todos los cambios, hacer pruebas de integración. Y una vez que se hacen, pueden levantar pull request, pidiendo el depósito original al propietario para tirar en todos los cambios y fusionar esos cambios en la sucursal principal. Caminar te permite usar el proyecto de otra persona como punto de partida para tu propia idea. Una gran cantidad de software o aplicaciones comerciales se iniciaron originalmente con un proyecto de código abierto. Simplemente trabajan en todos los proyectos de código abierto existentes e introducen cambios además de eso y lo venden a sus clientes con la licencia comercial. Y por último, no hay que esperar el acceso correcto. Imagina que estás escribiendo un correo electrónico al dueño posterior pidiendo el eje derecho, y luego esperas para siempre la respuesta. Bueno, con bifurcación, puedes directamente hacia arriba para contribuir al proyecto y competir con las solicitudes de pull sin tener que el acceso correcto al depositario original. Vamos a ver toda esta inacción y más en próximas conferencias. Nosvemos a continuación. 95. 1302 Formar un repositorio público y clonarlo en nuestra máquina local: De acuerdo, veamos cómo podemos bifurcar un repositorio para empezar a contribuir. Ahora imagina que esta es la computadora de Luke y está dispuesto a contribuir a uno de los proyectos de código abierto disponibles en línea. Entonces déjame ir a la cuenta GitHub de Luke. Y aquí está. Y asumir que este es el proyecto al que Luke está dispuesto a contribuir. Este proyecto en realidad es propiedad del Sr. cilindro y mira, no tiene el acceso adecuado a este proyecto o no se le suma como uno de los colaboradores para este proyecto. Esta vez, como loop no puede contribuir directamente a este proyecto, lo que va a hacer es, en realidad va a crear un fork de este proyecto. Por lo que aquí ves una opción que dice ****, puedes agregar el click aquí. Daré clic en el menú desplegable. Y se ve una opción que dice Create a New Fork. Oye, la forma en que te llevarían a esta página donde se te pedirá que des un nombre para tu repositorio. Puedes conservar el mismo nombre que con el depositario original, o puedes cambiarle el nombre a otra cosa. Por ejemplo, tal vez looks, app o lo que sea, no importa. Opcionalmente, también puede proporcionar descripción y hacer clic en este botón que dice crear tenedor. Entonces esencialmente hemos creado un clon del proyecto original en la cuenta GitHub de Luke. Y Luke ahora puede hacer todo lo que de otra manera haría en su propio repositorio público. Y el hecho de que esto sea en realidad un clon o una versión bifurcada de algún otro repositorio. Vas a ver que todo el historial de commit son ramas. Todo es tal cual, excepto un repositorio bifurcado. Vas a ver este icono significa que se trata de un repositorio bifurcado. Y también este texto que dice bifurcado del poli 1996 slash mi tope público, que es el depositario original. Solute, ahora puede empezar a contribuir a este proyecto. Incluso puede agregar colaboradores adicionales. Si Luke está teniendo un equipo de desarrolladores que podrían estar queriendo contribuir a este proyecto. Puedes agregar colaboradores o reglas de protección de sucursales. Todo lo que se puede hacer con un repositorio público. Puedes hacer lo mismo incluso con el repositorio bifurcado. Excepto claro que vas a ver una diferencia del original depositado aquí. Esta referencia será útil en una etapa posterior y vamos a hablar de ello en próximas conferencias. Por ahora. Tratemos de clonar este proyecto. Copiemos la URL HTTPS. Adentro mira computadora simplemente tiene que ir a clonar su propio repositorio. Git clona y pega la URL. Déjame entrar en ese directorio cd. Y déjame escribir el comando git remote guión v significa verbose. Como puedes ver, ya ha agregado un remoto con el nombre origen, y está apuntando al repositorio bifurcado. Entonces cuando digo origen, realidad me estoy refiriendo al repositorio bifurcado. Y abajo de la línea también se requeriría agregar otro remoto, que es remoto aguas arriba. Y eso apunta a que el repositorio original continuará a partir del siguiente. 96. 1303 Contribución de los cambios necesarios: Ahora bien, ¿cuáles son los cambios que Luke quiere aportar a este proyecto? Va a traer todos esos cambios localmente, probarlos, y luego empujar todos esos cambios a su propio repositorio bifurcado con el fin simular ese comportamiento que ha hecho montón de commits. Y por supuesto, como buena práctica, vamos a crear una nueva sucursal. Y ahí es donde vamos a hacer nuestros commits. Eso es lo que he estado predicando lo largo de este curso. Nunca querríamos hacer comercio estáticamente en la rama principal, sino más bien crearemos una nueva sucursal y haremos contribución hueca. Así que vamos a abrir esto con el código de Visual Studio muy rápido y crear una nueva sucursal. Llamémoslo característica diez. A lo mejor. Crear una nueva sucursal. Y simplemente voy a agregar un par de archivos. Un punto TXT, por ejemplo, ir a Source Control, creado un punto TXT. Comete los cambios. Y déjenme hacer uno más comprometido. A lo mejor dos dot dx, dy, lo que sea. Sólo quería asegurarse de que vemos un par de comentarios. Y esta rama característica tiene la palabra introducir nuestros cambios. Tenemos característica una sucursal y hemos hecho un par de comentarios en ella. Se puede ver en esta gráfica aquí, como se puede ver, la característica uno ramas, par de comentarios por delante. La rama principal. Ahora qué pasa si, mientras sigo trabajando en esta característica, tenemos montón de nuevas actualizaciones en el repositorio upstream o en el repositorio original. ¿ Cómo vamos a obtener todas esas actualizaciones en nuestra máquina local así como en el repositorio bifurcado? De eso es de lo que vamos a hablar a continuación. 97. 1304 Sincronización de la reposición Forked con una original y actualización local: De acuerdo, veamos cómo podemos mantener nuestro depositario local así como el repositorio bifurcado en sincronía están al día con el depositario original. fin de simular el comportamiento donde tenemos algunas nuevas actualizaciones en el depósito original hoy. Déjame en realidad ir a cuenta de remitentes. Quién es el propietario de este repositorio. Y déjame hacer un commit en la rama principal, tal vez con solo agregar un archivo. Vamos a darle algún nombre al azar. Algo de ese tipo. Punto de manzana TXT. Perdón por los nombres graciosos. Yo sólo quería mantener las cosas simples. Vamos a crear este archivo. Por lo que tenemos algunos cambios nuevos en la rama original. Ahora hay múltiples formas de mantener nuestro repositorio bifurcado sincronizado con el repositorio original. El del que voy a hablar ahora es el enfoque más fácil de todos. Entonces vayamos ahora a la cuenta GitHub de Luke. Refresquemos la página. Entonces este es el repositorio bifurcado. Aquí se ve un mensaje que dice que esta rama es un commit detrás del policía principal, que es el depositario original. Y aquí también se ve una opción para hundir tenedor. Si da clic en él. Verás la opción de actualizar la sucursal y sí tomar nota de que actualmente estamos en la sucursal principal. Por lo que esencialmente se compara la rama principal del repositorio bifurcado con la rama principal del depositario original. Y así es como GitHub nos está diciendo que en realidad somos un commit detrás de la rama principal del depositario original. Al hacer clic en fork de sincronización, verás la opción de actualizar la sucursal, haz clic en ella. Entonces esto traería y fusionaría nuestros cambios. Y como pueden ver, tenemos ese nuevo expediente por aquí. Ahora, cuando sí lo hizo buscar y fusionar, es como la operación de la piscina. Y eso va a resultar en una fusión de avance rápido. Y no hay manera de que podamos conseguir conflictos aquí porque estamos siguiendo buenas prácticas de no hacer nuestras aportaciones en la rama principal. Creamos una rama característica y ahí es donde estamos trayendo todos los cambios no estaban tocando la rama principal. Entonces, cuando pensamos ambos en los repositorios, no hay forma de que vayamos a ver algún tipo de conflicto por si no estás siguiendo las buenas prácticas y haces comentarios en tu rama principal, bien podrías estar viendo conflictos y luego tienes que lidiar con esos conflictos. Una vez que lo tengas en el repositorio remoto, todo lo que tienes que hacer es tirar estos cambios incluso en tu repositorio local. Hagámoslo muy rápido. Y como puedes ver, obtuvimos las actualizaciones del repositorio predeterminado. 98. 1305 Sincronización de la reposición Forked con original de la repo local: Echémonos un vistazo a la manera de mantener al repositorio bifurcado y al depositario local actualizados con el depositario original. Para eso, hagamos rápidamente un comentario más. En el depositario original, que se encuentra en ventanilla de autobús. Sólo para simular el comportamiento de tener nuevas actualizaciones en la rama principal. Voy a agregar un nuevo archivo, algo de ese tipo. Una vez más, perdón por los nombres graciosos. Ven con el nuevo archivo. Esta vez, lo que vamos a hacer es que en realidad vamos a tirar todos esos cambios en un repositorio local y luego empujarlos a nuestro repositorio bifurcado. A ver cómo podemos hacer eso. Hagámoslo desde Git Bash. También puedes hacer lo mismo desde el código de Visual Studio si lo deseas. primero es lo primero, tenemos que sacar los cambios del Depositario original. ¿ Cómo vamos a hacer eso? Si digo git pull, esto realmente tiraría del control remoto de origen, que es el repositorio bifurcado. Pero en realidad queremos sacarlo del depositario original. ¿ Cómo vamos a hacer eso? En primer lugar, hay que añadir ese remoto. Si digo git guión remoto v, Se ve que tenemos origen degradado y está apuntando al repositorio bifurcado. Agreguemos ahora otro remoto, git, remote add. Y lo voy a nombrar como aguas arriba. Como ya he mencionado antes. Vamos a llamar al depositario original como aguas arriba. Y aquí vamos a proporcionar la URL del depositario original. Así que permítanme copiar esto aquí. También puedo usar este enlace si lo deseo. Este comando acaba de agregar el repositorio upstream. Si vuelvo a ejecutar este comando, ven que ahora tenemos un par de señalamientos. Ahora vamos a tratar de sacar los cambios desde el repositorio de aguas arriba. Git pull luego upstream main. Por lo que queremos mantener actualizada nuestra sucursal principal. Esto ha jalado todos los cambios. Este es el archivo que acabamos de crear. Eso lo puedes ver también en el Código de Visual Studio. Sin embargo, estos cambios aún no están disponibles en nuestro repositorio bifurcado ni en el servidor de origen. Entonces adivina lo que tenemos que hacer a continuación. Empuje de Git. Y esto debería empujar estos nuevos commits al repositorio bifurcado. Si vas a la cuenta de Luke ahora y recargas la página, vas a ver esas actualizaciones. 99. 1306 Llevar nuestros cambios a la reposición forked: De acuerdo, Supongamos que Luke se hace con toda la característica diez cambios. Y ahora está dispuesto a proponer todos estos cambios al remitente, que es el dueño del depositario original o del repositorio aguas arriba. Pero antes de que Luke considere hacer eso, necesita asegurarse de que tiene todas las actualizaciones, todas las actualizaciones más recientes del repositorio ascendente, y se asegura de que su repositorio bifurcado, así como el depositario local, están al día con el mismo. Ya hemos visto cómo se puede hacer en el último par de conferencias. Lo segundo que debe asegurarse de que el bucle es leer esto como rama de características en la parte superior de la rama principal. Entonces hagámoslo muy rápido. Voy a cambiar a característica diez rama. Voy a hacer clic derecho en la última commit fuera de la rama principal. Y luego voy a elegir esta opción que dice rebasar rama actual en esto. Con esto, nos deshacemos cualquier posible conflicto que pudiera ocurrir. Si te encuentras con algún tipo de conflicto, ya sabías cómo lidiar con eso. Una vez que termines con eso, en realidad vas a empujar todos estos cambios al repositorio remoto o al repositorio bifurcado o al origen. Entonces empujemos todos estos cambios. Obtenemos un prompt que dice que la característica de sucursal Dan no tiene sucursal remota. ¿ Te gustaría publicar esta sucursal? Yo digo, vale, quiero elegir el modo ácido de origen. eso quiero publicar o empujar nuestros cambios . Es acertado. Eso ha ido a la cuenta de Luke y ver si las cosas se reflejaron. Y claro, ahora estás viendo déjame recargar la página. Ahora estás viendo esta nueva sucursal. A continuación vamos a ver cómo podemos plantear la solicitud de pull para proponer nuestros cambios al cilindro maestro. Nos vemos a continuación. 100. 1307 Aumentar la solicitud de extracción y fusionar los cambios en el repositorio ascendente: Veamos cómo Lucas puede proponer estos cambios a rendirse levantando un pull request. Hay múltiples formas de hacerlo. Aquí ya ves una opción para comparar y elevar la pull request. Puede hacer clic aquí o puede elegir la rama de características en la lista. A continuación, haga clic en el menú desplegable debajo de contribuir, y verá la misma opción para abrir una solicitud de extracción. Alternativamente, también puede ir a la sección de solicitudes de extracción y plantear una nueva solicitud de extracción. Sea cual sea el camino que sigas, vas a ver la pantalla donde necesitamos comparar las ramas para ver la diferencia de las dos. Aquí vamos a comparar la rama principal fuera repositorio upstream con la rama de características del repositorio bifurcado. El repositorio aquí se refiere al repositorio upstream. Y aquí hemos elegido la rama principal. El repositorio principal aquí está apuntando al repositorio bifurcado. Y aquí tenemos que elegir la rama de características. Así que esto va a mostrar un resumen de todos los cambios que acabamos de introducir en la rama de funciones. Ahora podemos simplemente seguir adelante y crear la pull request. El proceso es bastante similar al proceso de solicitud de extracción del que habíamos hablado antes. Por lo que una vez que se plantea la solicitud de extracción, en realidad pueden revisar los cambios. Él puede aceptar o negar o pedirte que trabajes en manojo de comentarios, etc. Vamos ahora al tablero de las cenizas. Recarga el repositorio principal. Aquí va a ver el pull request. Vamos a dar clic en él. Ya hablamos de una variedad de cosas que podemos hacer aquí. Por ejemplo, sólo puedo decir rebajas y fusionar. Pero antes de eso, ya que tenemos una regla de predicción de rama, para hacer al menos una revisión, revisemos rápidamente los cambios y digamos que estoy contento con todos los cambios. Voy a aprobar y presentar la revisión. Ahora en realidad puedo seguir adelante y elegir cualquiera de estas opciones. A lo mejor me gustaría ir con merge. Confirmar fusión. Y ahora todos los cambios relacionados con esta característica se fusionan en la rama principal. Entonces ves todos esos archivos aquí, un punto TXT y dos puntos TXT. Y estamos dentro de la rama principal. A lo largo de todo este proceso, Luke nunca fue agregado como colaborador en el depositario original o en el repositorio upstream. Sin embargo, pudo contribuir a este proyecto. Espero que tenga sentido. Nos vemos a continuación. 101. 1308 Exploración de proyecto público existente: En este video, vamos a explorar uno de los proyectos existentes disponibles en GitHub y ver si podemos darle sentido a partir de lo aprendido en este capítulo. Si tienes algún proyecto en mente que ya conozcas, entonces puedes buscarlo por aquí. ¿ Se puede ir a explorar, a explorar algunos de los proyectos públicos. También puedes echar un vistazo a proyectos basados en un tema en particular. Aquí vas a ver una lista de temas ordenados en orden alfabético. A continuación te presentamos una lista de los temas más populares. Vamos a dar clic en tal vez reaccionar. Abrámonos aleatoriamente en todos los proyectos aquí. Un x punto js. Simplemente voy a escoger algo al azar. Tal vez este marco icónico. Lo primero que vas a notar una vez que visites la página del proyecto es el archivo léeme. archivo readme normalmente constituiría información sobre el software, cómo se puede instalar en caso de que se quiera empezar como colaborador para este proyecto, ¿cuáles son todos los pasos que implica eso? Para comenzar como colaborador, encontrará proyectos que son plantas y montón de dicha información en el archivo ReadMe. Entonces este es probablemente el punto de partida. Si quieres empezar con un proyecto en particular. Una vez que revisas el archivo ReadMe, en realidad puedes comenzar con la contribución. Pero vamos a explorar la sección Pull Request aquí. Como se puede ver actualmente tiene alrededor de 33 peticiones pobres de actor que aún no se fusionan, se revisan. Básicamente vas a ver un par de tipos de peticiones. El primero es el que hemos hablado en nuestras conferencias anteriores. El segundo es algo de lo que aún no hemos hablado. Se llama Borrador de solicitudes de extracción. Se puede decir que una solicitud de extracción en particular es un borrador para solicitud. Al mirar este icono, si está en gris, entonces es un borrador de solicitudes de extracción. Quizás te estés preguntando qué es un borrador para las solicitudes. Vamos a hablar de ello en próximas conferencias. Pero básicamente, si usted tiene algún cambio que se acaba de proponer cambios para tener la discusión o para tomar retroalimentación, pero no están realmente destinados a ser fusionados. Después se puede plantear un borrador para las solicitudes. Basta con iniciar esa discusión. Todos los demás en realidad pueden echar un vistazo a sus cambios de código y poner algunos comentarios al respecto. Y en base a eso, decidirás si quieres proceder con eso o no. También notas estas llamadas etiquetas a la derecha de cada título de solicitudes de pull. Nuevamente, esto es algo que tocaremos en próximas conferencias. Pero las etiquetas esencialmente le permitirían clasificar las solicitudes de encuesta. En otras palabras, te ayudaría a categorizar las peticiones pobres. Por ejemplo, si hago clic en esta etiqueta, vas a ver todas las solicitudes de pull que corresponden a esa etiqueta en particular. Como propietario del repositorio, si quisiera echar un vistazo a la lista de solicitudes de pull que corresponde a una etiqueta en particular. Yo puedo hacer eso. estar viendo un montón de otras cosas aquí de las que aún no hemos hablado. Podríamos explorarlos en próximas conferencias. Pero supongo que has subido a un escenario donde puedes aprender cosas por tu cuenta. De hecho, ese es el objetivo de este curso para hacerte pararte por tu cuenta. Realmente no puedo enseñar todo lo que hay ahí fuera. Mi trabajo es hacerte sentir cómodo con la tecnología. Y creo que hasta ahora hemos llegado a esa etapa. Ahora depende de ti tendrás que explorar, ir más allá, y hacer algo para ampliar aún más esas habilidades. Una de las mejores maneras de hacerlo es básicamente aportar realmente uno de estos proyectos. Por ejemplo, si estás aprendiendo React o Python o lo que sea, simplemente echa un vistazo a montón de proyectos que están aquí relacionados con ese tema en particular y empieza a contribuir. Todo proyecto debe estar teniendo algunas instrucciones sobre cómo empezar como colaborador. Puedes pasar por eso y empezar con la contribución. Entonces estas son todas las solicitudes de pull planteadas por gente como tú y yo. Y se puede ver que este proyecto ha sido bifurcado por más de 13 mil veces. Al momento de esta grabación. Echemos un vistazo a la lista de temas. Por lo que actualmente hay alrededor de 554 temas. Si quieres reportar un error o sugerir una nueva función, puedes hacerlo también haciendo clic en nuevo número. Puede agregar el informe, un error o una solicitud de una función. Se puede pasar por la documentación, etcétera. Esta maquetación está realmente personalizada para este proyecto. Es posible que veas un diseño ligeramente diferente dependiendo del proyecto que estés viendo. Por ejemplo, digamos que he usado su software y encontré un bug, y luego quise reportar ese bug. Por lo que sin duda puedo dar clic en esto. Y han diseñado un formato para reportar el bug. En primer lugar, querían asegurarse de que leí los lineamientos de contribución. Una vez que haga eso, puedo dar clic en esta casilla de verificación, su código de conducta, etc. El Washington, ¿qué bicho está decidiendo? ¿ Cuál es el comportamiento actual, cuál es el comportamiento esperado? Pasos claros para reproducir, y montón de otra información para ayudar en última instancia a alguien que quería solucionar este error a obtener toda la información que necesitan para corregir el error. Volvamos a temas. Para que puedas echar un vistazo a estos temas. Si crees que puedes arreglar uno de estos, ya sabes qué hacer. Solo tienes que bifurcar el proyecto, clonar el proyecto, tu máquina local, corregir el error, empujar esos cambios al repositorio bifurcado, y luego subir las solicitudes de extracción. Como dije antes, toma esto como una tarea y en realidad contribuye a una extraña, son proyectos valiosos en GitHub. Una vez que tus solicitudes de pull se fusionen o aprueben por los propietarios del código, te va a dar mucha satisfacción y te dará algún sentido de logro. Una vez que veas que eso sucede. Podría tomar algún tiempo para que todo el proceso se complete. Pero te recomiendo mucho que hagas eso. Y de esa manera lo estás armando todo. Lo que has aprendido en este curso hasta ahora. En el resto del curso, vamos a hablar todas las piezas que faltan en estas tecnologías. Pero como dije antes, creo que hemos llegado a una etapa en la que estás por tu cuenta y has aprendido todos los temas esenciales de Git y GitHub. Te deseo buena suerte, pero aún no terminamos con el curso. Tenemos muchos otros temas que discutir también. Entonces sí, tomarlo como una tarea y contribuir a un día libre proyectos valiosos. Nos vemos a continuación. 102. 1401 estrategia de distribución explicada: Hablemos de la estrategia para la ramificación. Tenemos el amo o la rama principal. Y en términos generales, lo que vaya dentro del master o de la rama principal debe estar lista para la producción. En otras palabras, debes asumir que el agua se mete dentro del master o la sucursal principal es algo que tu cliente comenzará a usar. De hecho, también podría estar teniendo algún tipo de automatización en su lugar donde elegirá constantemente el código del maestro o la rama principal, creará un artefacto y los desplegará en la inscripción de producción para que sus clientes reciban ahora todas esas nuevas actualizaciones o características. A modo de ejemplo, imagina que estás desarrollando un sistema operativo como Windows. El momento de entregar algo en el maestro o la sucursal principal, sus clientes podrían ver un pop-up diciendo que hay un nuevo service pack disponible para instalar. A continuación, instalarán ese service pack para obtener todas las últimas características o correcciones de errores. El hecho de que se trate de código listo para producción significa que se debe tener cuidado en cuanto a lo que va dentro del maestro o de la rama principal. Lo que va dentro de la rama principal o principal debe ser absolutamente probado. Código de calidad asegurada que realmente no puedes arriesgarte a tener ningún tipo de bugs. Entonces obviamente por esas razones, no puede hacer que el maestro o la rama principal estén disponibles para que los desarrolladores aporten su código. Si lo haces, entonces cada vez que alguien fusiona el código en la rama principal para todas y cada una de las funciones, tus clientes también van a recibir esas actualizaciones, que por supuesto no son tan probadas. Y obviamente no es una buena práctica. Entonces lo que vamos a tener es que vamos a tener otra rama llamada rama de desarrollo. Y esta va a ser la rama más activa donde contribuirían todos los desarrolladores. De hecho, en el momento en que creamos un repositorio GitHub, vamos a hacer rama de desarrollo como la rama predeterminada para que cada vez que alguien clone el código en su máquina local, vamos a ver el ramade desarrollo como una rama predeterminada. De hecho, no vamos a dejar que nadie contribuya al amo o a la rama principal. En cambio, sólo abriríamos la rama de desarrollo o contribución. Solo un conjunto particular de personas tendrá los permisos en el maestro o la rama principal para fusionar realmente el código probado de calidad. E incluso en desarrollo, cada vez que alguien entrega un código se plantea una pull request. También podríamos estar teniendo algún tipo de automatización aquí , así como para comprobar la calidad del código. Por ejemplo, comprobar si hay alguna vulnerabilidad de seguridad, están tratando de realizar algún escaneo, verificar si hay algún error programático, etc. para asegurarse de que el código aún se adhiere a los estándares de calidad de la organización cada vez que alguien contribuye a esta rama. Ahora imagina que hay un montón de características entregadas en la rama de desarrollo. Y es en este punto en el tiempo, nos dimos cuenta de que en realidad podemos liberar todo este feto al usuario final. Ahora podríamos fusionar todos esos cambios con todas las últimas características de la rama maestra. Así que tus clientes comenzarán a usar. Pero tenemos un paso más que cuidar. En realidad vamos a tener otra sucursal más llamada rama de lanzamiento. Y eso es lo que vamos a fusionar todo el último desarrollo de la rama de desarrollo. La rama de liberación se encuentra entre la rama principal principal y la rama de desarrollo. Es algo así como una inscripción de preproducción donde podríamos hacer algunas pruebas de automatización para asegurarnos de que todas las características funcionen como se esperaba. Una vez que se hace la prueba, todo se llama el asegurado. Luego fusionaremos todos los cambios de la rama Release a la rama maestra real. Y el código se convertiría ahora en la versión oficial del software que utilizarán los clientes. Bueno, estoy seguro de que todo esto podría sonar confuso. Entonces déjame tomar un ejemplo en tiempo real y guiarte a través de este diagrama una vez más. Entonces sí entiendo mejor y lo haremos a continuación. 103. 1402 Estrategia de ramificación con escenario en tiempo real: De acuerdo, Vamos a entender todo esto con un ejemplo rápido en tiempo real. Así que imagina que tenemos un montón de desarrolladores que aportaron su código, un montón de características a la rama de desarrollo. O podría ser el caso de que tu proyecto haya sido bifurcado por un montón de personas. Y levantaron solicitudes de tirón que finalmente se fusionaron en la rama de desarrollo. Pero en última instancia tenemos un montón de características en una rama de desarrollo. Y es en este punto en el tiempo que nos hemos dado cuenta de que en realidad podemos entregar esto al cliente como un nuevo lanzamiento. Ahora podríamos simplemente fusionar todos estos cambios suenan a la rama de lanzamiento. Pero antes de eso, en realidad vamos a crear una rama más, la versión un punto o en absoluto, con el supuesto de que esta es la primera versión del software que estamos lanzando. El tipo de formato que estamos siguiendo por empeorar el software es el llamado versionado semántico. Vamos a hablar de ello en próximas conferencias. Pero por ahora esta es la versión. Y vamos a nombrar nuestra sucursal con ese número de versión. Ya sabes, el propósito de crear esta sucursal en sólo un poco. Así que una vez creamos una rama llamada porción un punto o punto o de la rama de desarrollo. Después fusionaremos todos esos cambios en la rama de lanzamiento. Y aquí es donde ocurren todas las pruebas y cualquier cosa adicional que quieras hacer, puedes hacerlo aquí antes de fusionar esos cambios en la rama maestra, que debería ser código listo para la producción. Por lo que eventualmente termina en el amo o en la rama principal también. Lo bueno de esta estrategia es que mientras estás ocupado lanzando el software y probando el software a fondo, antes de llegar realmente a la producción y Roma y otros desarrolladores pueden realidad continuar trabajando en esa tarea y diluir las características en la rama de desarrollo. Ahora imagina que el cliente ha reportado un bug. A lo mejor un software le permitiría al cliente reportar un bug en el momento en que lo definió. Entonces supongamos que el cliente de cosmovisión encontró el bicho, lo informó. Y te das cuenta de que en realidad es un error muy serio que necesita ser arreglado en prioridad. Entonces lo que tienes que hacer es que vas a crear una sucursal a partir de esta rama de versión. Y vas a incrementar el valor en uno. Nuevamente, esto se llama versionado semántico. Vamos a hablar de ello. Pero esencialmente vas a crear una rama a partir de la versión anterior. Y aquí es donde vas a arreglar el bug. Una vez que arregles el bug, vas a probar todos los cambios. Y luego vas a fusionar todos esos cambios en la rama de desarrollo así como en la rama de lanzamiento y eventualmente en el master o la rama principal también. Por lo que el cliente tendrá el corregido para el informe de error que en realidad voy a demostrar todo esto en GitHub bastante pronto para que tenga una mejor claridad en cuanto a lo que exactamente está sucediendo aquí. Nos vemos a continuación. 104. 1403 Versioning semántico explicado: Hablemos de versionado semántico. versionado semántico es una práctica estándar seguida para adorar en una versión de software en particular o una biblioteca o una API. Y aquí está el formato del versionado semántico. La primera parte es la versión mayor. La segunda parte es la versión menor, y la tercera parte se llama parche. La forma en que funciona el versionado semántico en K, software. El software es ligeramente diferente en comparación con la forma en que funciona en el caso de una API. Hablemos primero de en caso de un software, algo así como un editor de video o un sistema operativo, etcétera. Así que cada vez que tengas algún cambio significativo son una enorme cantidad de características. O tal vez haya eliminado algunas de las características existentes se modifican significativamente, las características existentes, entonces es posible que desee considerar incrementar la versión principal. Cuando hagas eso, vas a restablecer los valores tanto de menor como de parche de nuevo a 0. O si solo tienes un par de características entregadas y no son muy significativas, entonces puedes considerar incrementar el número de versión menor. Y si tienes alguna corrección de errores o hotfixes encima de esta versión, entonces puedes considerar incrementar la versión del parche a medida que introduzcas nuevas revisiones, vas a seguir incrementando el número de parche así. Ahora digamos que has trabajado en un par de características más y son solo cambios menores. Se puede incrementar una vez más el número de versión menor, pero luego hay que restablecer el valor de parche de nuevo a 0. Es así como funciona el versionado semántico. Y como mencioné antes, la forma en que funciona esto en caso de una API, es ligeramente diferente de una API cada vez que incremente el valor de la versión principal significaría que ha introducido cambios significativos que ya no serían compatibles con versiones anteriores. Por ejemplo, tal vez haya eliminado ciertas características o modificado significativamente algunas de las características existentes. Lo que eso significa es que todos los proyectos que estamos usando versión anterior de su biblioteca tendrían que considerar cambiar su código antes de que puedan tomar la última versión de su biblioteca. Eso es lo que significa cuando incrementas la versión mayor. Sin embargo, incrementar la versión menor significaría que las nuevas características o funcionalidades se han agregado y no requiere que nadie modifique el código para que su código sea compatible con su biblioteca. Los parches similares al parche que habíamos hablado antes. Si lo estamos incrementando, eso significa que has proporcionado una corrección de errores o un hot fix. Entonces así es como funciona el versionado semántico. Nos vemos a continuación. 105. 1404 entender las etiquetas Git: Hablemos de etiquetas y consigamos. Etag es simplemente una diferencia que apunta a un punto específico de la buena historia. En otras palabras, el ataque simplemente apuntaría a un commit específico. Ahora esto podría sonar como una rama. Incluso rama sí apunta a un commit específico, e incluso tag sí apunta a un combate específico. Pero la diferencia entre los dos es que la rama se actualizaría cada vez que hacemos un nuevo commit en la rama. Y branch apuntaría a ese último commit, mientras que tag se mantendría constante. Si creamos una etiqueta que apunta a un commit en particular, permanecerá así para siempre a menos que hagamos algo con esa etiqueta explícitamente. Ahora bien, ¿cuál es la ventaja de crear una etiqueta? ¿ Por qué queremos crear una referencia a un commit en particular y mantenerlo constante? Echemos un vistazo. Entonces esto es de nuestro ejemplo anterior, 1 segundo, supongamos que hemos lanzado un nuevo software y eventualmente tenemos son cambios en la rama maestra. Es en este punto en el tiempo vamos a crear una etiqueta, dándole el número de versión del software tiene su nombre. Ya que suponemos que este es un primer release off o software, lo vamos a empeorar como un punto o punto o. y esta etiqueta apunta a este commit en particular, el master o la rama principal. Ahora supongamos que hemos proporcionado un hot fix. Y una vez más, hemos entregado eso fijo en la rama maestra. Vamos a crear otra etiqueta más, dándole algún número de movimiento. Entonces como esto es una corrección de errores o un hot fix, simplemente incrementamos el número de parche por uno. Entonces esencialmente estamos siguiendo el versionado semántico aquí y esta etiqueta apunta o tiene la referencia del commit en la rama maestra con esa corrección. Pero, ¿de qué sirve tener todas estas etiquetas? Bueno, otro caso de uso es, digamos que quería crear un artefacto basado en una versión específica. Entonces tal vez pueda ejecutar un comando diciendo que quiero crear un artefacto para la versión un punto o punto o. ¿ Adivina qué? Puedo ejecutar el comando especificando esta etiqueta. Y la herramienta crearía el artefacto para mí, que luego se puede implementar en la inscripción de producción, etc. O tal vez pueda ponerlo en las notas de lanzamiento para que los clientes lo descarguen y usen. No podemos usar branch en este caso porque branch se actualizaría de vez en cuando. En el momento en que hagamos un nuevo commit en la rama, etiquetas vendrían muy bien en tal situación. A continuación, vamos a echar un vistazo a todo esto en acción para que tengan imagen completa de lo que está sucediendo exactamente y cómo va a funcionar. Nos vemos a continuación. 106. 1405 flujo de trabajo de trazo en acción: De acuerdo, ahora veamos todo en acción y espero que estén listos para esto. Primero sigamos adelante y creamos un nuevo repositorio. Llamémoslo tal vez súper audio. A lo mejor estamos creando una herramienta de edición de audio en absoluto. Y tal vez me gustaría agregar el archivo léeme también. Si lo desea, en realidad puede ir a la configuración y cambiar el nombre de la rama por defecto de main a otra cosa si lo desea. A lo mejor podemos cambiar esto a maestro. No es obligatorio. Pero lo estoy haciendo de todos modos. Voy a crear el repositorio. Como pueden ver, tenemos la rama maestra. Y esta va a ser la llave de producción, lo que significa que lo que pase dentro la rama maestra entraría en la matrícula de producción. A continuación, sigamos adelante y creamos las otras dos ramas. Una va a ser la rama de pre producción, y vamos a entrar nombre como lanzamiento. Y otra rama es para el desarrollo. Llamémoslo desarrollar. Esta sucursal estaría teniendo lo último delúltimo código de último código de todos los contribuidores que están colaborando con nosotros. Pasemos ahora a la configuración y hagamos la rama de desarrollo como una rama predeterminada. Sólo para que si alguien fuera a clonar el proyecto, van a ver la rama de desarrollo como una por defecto donde pueden contribuir. Por lo que vamos a cambiar esta rama de master a desarrollar y dar clic en Actualizar. Ahora si vuelvo, vas a ver la rama de olivo elegida ya porque esa va a ser ahora la rama por defecto. Ahora, con el fin de simular el comportamiento, tener un montón de características en su lugar en la rama de desarrollo. Simplemente voy a agregar un par de archivos. Pero hay que hacer una suposición que tal vez hemos hecho algunos cambios relacionados con las funciones y contribuido a esta rama. Podría darse el caso de que alguien más por el proyecto y plantee solicitudes de pull en esta rama en particular. Entonces quien sea gente este proyecto, se espera, la carrera pull solicita en la sucursal del dólar. No tienen ningún tipo de permiso o no esperamos que nadie haga aportaciones a la rama de liberación, duro la rama principal o la rama maestra. Entonces sigamos adelante y creamos un par de archivos. Crea un nuevo archivo, llamémoslo cuentan con un punto TXT. Sólo para mantener las cosas simples, vamos a crear otro archivo más. Crea una nueva función de archivo para marcar TXT, por ejemplo, y compromete el código. Entonces tenemos manojo de commits aquí. El primero fue el archivo léeme, y los otros dos son para las características. Ahora, ¿qué es lo siguiente que hay que hacer? ¿ Se puede hacer una conjetura? Suponiendo que queríamos lanzar nuestro software o la primera versión de nuestro software al usuario final. Bueno, primero vamos a crear otra sucursal más. Y vamos a nombrar esa rama con versionado semántico. Ya que esta es una versión muy falsa del software que estamos lanzando, vamos a nombrarla como un punto o punto o.Así que vamos a crear esta rama fuera de la rama de desarrollo. En tanto, otros desarrolladores pueden seguir contribuyendo a la sucursal del dólar. Pero lo que vamos a hacer a continuación es que necesitamos fusionar todos estos cambios a la rama de lanzamiento de esta rama en particular que acabamos de crear. Entonces adivina lo que tenemos que hacer a continuación. Forma de plantear solicitudes de pull. Actualmente, la rama de lanzamiento no tiene esta característica conducen a cambios cuándo conseguirlos aquí. Voy a ir a pull requests, crear una nueva pull request. Aquí voy a elegir la rama de lanzamiento y quiero compararla con la rama de versión, llamémosla. Por lo que aquí están todas las características conducen a cambios. Y voy a crear la pull request. Suponiendo que hemos hecho todos los trámites de revisión, escaneo de tablero y todo, sigamos adelante y fusionemos todos estos cambios. No queremos eliminar esta sucursal todavía porque va a venir muy bien en una etapa posterior. Entonces, si vuelves al repositorio y vas a la rama de lanzamiento, ahora tendrías todos esos cambios relacionados con las características. Así que podríamos estar ejecutando algunas pruebas automatizadas y asumiendo que todo está funcionando como se esperaba, ahora hemos decidido empujar todo esto cambia nuestro módulo, estos cambios en la rama maestra por lo que nuestros clientes comenzarán a usar nuestro software. Por lo que una vez más, vamos a plantear otro Pull Request. Nueva solicitud de extracción. Aquí voy a elegir la rama maestra. Y aquí voy a elegir la rama de lanzamiento. Y vamos a seguir adelante y crear la pull request. Combinemos también todos esos cambios a la rama maestra. A lo mejor con tres bits y fusionarse. También podemos Squash commit para combinar todos los commits en un solo commit. Pero creo que estamos bien con esto. Por lo que ahora hemos lanzado oficialmente nuestro software al usuario final. Entonces si hago clic en Maestro, vas a ver la característica llevar a los cambios aquí. Idealmente, se supone que debemos crear una etiqueta aquí mismo. Pero vamos a hablar de etiquetas en próximas conferencias. Nosvemos a continuación. 107. 1406 flujo de trabajo de reparación caliente en acción: De acuerdo, sigamos. Ahora haga una suposición de que en off su cliente ha reportado un error y se da cuenta de que en realidad es un error crítico que necesita ser corregido en prioridad. Y entonces no estás planeando tener un hot fix. Entonces, ¿qué es lo primero que tenemos que hacer? Bueno, ya tenemos una sucursal a mano. El que habíamos creado previamente con el nombre de la versión. Aquí es donde viene muy bien. Podemos crear otra rama fuera de esta rama para arreglar el error. Y luego vamos a fusionar todos esos cambios en la rama de desarrollo así como el lanzamiento y eventualmente en la rama maestra también. Por lo que los clientes obtendrían una actualización con la corrección. Por lo que he elegido esta rama de versión en particular. Vamos a crear ahora otra rama para arreglar el bug y obtenemos la versión que necesitamos dar aquí. Ya que estás caminando en hot fix fue incrementar el valor de la versión de parche por uno. Esta vez el nombre de la sucursal va a ser 101. Voy a crear esta sucursal. Una vez más para simular el comportamiento de arreglar un bug. Permítanme simplemente crear un error de archivo, punto dxdy fijo, lo que sea. Y voy a cometer este cambio. Ahora necesitamos fusionar estos cambios a la rama de desarrollo. O bien podemos hacerlo desde aquí. Podemos ir a tirar la sección transversal y levantar una nueva solicitud de extracción. Elige la sucursal que acabamos de crear y vamos a comparar con la rama develop. Entonces tenemos esto arreglado aquí. Crea una clase de producto y déjanos salir. Así que adelante y fusiona la corrección de errores en la rama de desarrollo. Y claro, si vuelves a la rama de desarrollo, ves la corrección de errores. Vamos a seguir pasos similares para el lanzamiento también. Fuimos a plantear un pull request. Vamos a elegir liberación aquí. Y la rama de corrección de errores borró las solicitudes de extracción. Y eso sí sigue adelante y fusiona estos cambios. Ahora, después de muchas pruebas, como las cosas humanas están funcionando muy bien. Vamos a seguir adelante y fusionar los cambios de la rama Release a la rama maestra. Como puedes ver, ahora tenemos la corrección de errores en la rama de lanzamiento. Vamos a crear una solicitud de extracción muy rápido. Vamos a comparar la rama de lanzamiento. Yo lo siento. Vamos a comparar la rama maestra y la rama de lanzamiento y fusionar todos esos cambios en la rama maestra. Para volver atrás y cambiar a rama maestra debe ser capaz de ver la corrección de errores y así es como se entrega un parche. A continuación, vamos a hablar de cómo podemos crear etiquetas. Y de hecho, nos había faltado crear la etiqueta en la versión anterior de nuestro software. Pero también podemos crear etiquetas para los commits que ya se hicieron. Cómo hacemos eso, hay algo de lo que vamos a hablar a continuación. Nos vemos a continuación. 108. 1407 Creación de etiquetas anotadas vs ligeras Etiquetas empujar etiquetas a distancia: De acuerdo, veamos cómo podemos crear etiquetas. Podemos agregar las etiquetas create en GitHub, o podemos hacerlo desde la línea de comandos desde nuestro Git local también. Vamos a ver los dos caminos. En primer lugar, vamos a explorar cómo podemos hacer eso localmente desde Git Bash. Por cierto, para ahorrar tiempo, ya añadí al señor Luke como uno de los colaboradores de este proyecto. Y aquí está la cuenta de Luke. Lo primero que Luke va a hacer es que en realidad va a clonar este proyecto en su máquina local. Entonces supongamos que esta es la computadora de Luke. Voy a lanzar Git Bash aquí. Y clonemos rápidamente el proyecto. Clon de Git. Voy a pegar el URI. Entonces vayamos dentro de ese proyecto. Despeja la pantalla. Entonces vamos a crear ahora etiquetas. Podemos agregar el crear una etiqueta ligera o una etiqueta anotada. Entonces básicamente hay dos tipos de etiquetas que podemos crear. Cuando se trata de etiqueta ligera es sólo un nombre o un identificador y se nombra a un commit en particular. tanto que cuando se trata de etiqueta anotada, además de un nombre y un apuntado para acomodar. También tendrá algunos metadatos, como el nombre del etiquetador, dirección de correo electrónico, fecha, etcétera. Si desea almacenar todos los metadatos junto con la etiqueta, sería mejor crear una etiqueta anotada y no un tanque liviano. Y en la mayoría de los casos, siempre es relevante crear una etiqueta anotada o un tanque liviano. Por razones obvias. Sabremos quién lo ha creado cuando lo hayan creado. E incluso sabríamos la dirección de correo electrónico de la persona que ha creado ese tanque. Entonces veamos primero cómo podemos crear etiqueta anotada. Básicamente, no hemos creado tag para la primera versión de nuestra aplicación. Entonces vamos primero cuál dominar rama. Si hago git branch, iPhone, nay. Ya ves que tenemos todas estas sucursales son sucursales de rastreo remoto, pero no tenemos una sucursal local para la sucursal maestra. Entonces para conseguir eso, vamos a hacer git checkout o bien cambiar a rama maestra. Ahora echemos un vistazo a la lista de commits que están en la rama maestra. Así que esencialmente aquí es donde idealmente deberíamos estar creando una etiqueta que represente la primera versión de nuestra aplicación. Entonces esto es justo antes del hot fix que habíamos dado. Entonces, ¿cómo vamos a crear una etiqueta para uno de los comentarios anteriores? Echemosun vistazo. Entonces el comando para crear la etiqueta es git tag, guión una etiqueta anotada de cuatro. Y vamos a especificar un identificador único o un nombre para esta etiqueta. Y en la práctica estándar, queremos dar la versión semántica de nuestro lanzado. Por lo que esta va a ser toda la primera versión de nuestra aplicación. Y ahora especificaríamos el hashCode de la antorcha. Queremos que apunte esta etiqueta. Esto es como si hubiéramos retrocedido en el tiempo y creado una etiqueta. En este compromiso particular. Voy a pegar este código hash. Además de eso, también vamos a proporcionar un mensaje significativo describiendo de qué se trata esta etiqueta. Alguna descripción al respecto parecía haberlo estropeado. Volvamos a escribir el comando. Etiqueta Git. Guión a. wee one.org.au especificó el guión hashCode m. descripción de la suma. Si no proporcionas el mensaje con la opción de guión m, vas a ver un editor de texto predeterminado se abre para que ingreses algún mensaje. Si proporciona esta opción, sin embargo, nota etc, se abriría. Por lo que esto debería crear una etiqueta para nosotros. Si ejecutas el comando git tag, vas a ver toda la lista de etiquetas que están disponibles. Entonces si alguien fuera a clonar el proyecto, también van a ver todas estas etiquetas. Ahora vamos a seguir adelante y crear una etiqueta ligera. Y el mando para eso es bastante directo. Obtener etiqueta y un identificador o un nombre para esta etiqueta. Entonces esta vez voy a decir que tenemos un punto, punto uno. Porque por defecto, cuando intentas crear una etiqueta, apuntaría a la misma commit a la que apunta la cabeza. Por lo que actualmente tenía esto apuntando a la última commit off master branch. Y así esta etiqueta, que es etiqueta ligera, porque no hemos proporcionado la opción de separación de palabras, también va a apuntar al escritorio commit off master branch, que incluye la corrección de errores. Y si recuerdas como por versionado semántico, habíamos incrementado el valor de la versión del parche por uno. Vamos a darle a Enter. Y acabamos de crear otra etiqueta más. Uno es etiqueta anotada, y el otro es etiqueta ligera, que no tiene ningún tipo de metadatos en absoluto. Ahora, ¿cómo publicamos todas estas etiquetas en el repositorio remoto? Bueno, simplemente vamos a usar el comando push estándar. Pero tenemos que especificar explícitamente que también queremos empujar etiquetas. Por defecto, el comando push no empujará las etiquetas. Entonces lo voy a hacer saber explícitamente. Entonces vamos a decir git push origin es el remoto donde queremos empujar todo este impuesto también. Podemos especificar qué etiqueta queremos empujar especificando su nombre, el identificador, como así son. También podemos decir tags para empujar todas las etiquetas al repositorio remoto. Ya que Luke ya tiene permiso para ese repositorio, fueron capaces de empujar todas esas etiquetas a este depositario. Y los puedes ver aquí. Si das clic en estas etiquetas, vas a ver que tenemos estos dos tanques continuarán a continuación. 109. 1408 Comprender cómo se almacenan las etiquetas Estado de cabeza independiente con etiquetas: Antes habíamos creado par de etiquetas. Una es etiqueta anotada, la otra es tanque liviano. Veamos cómo se almacenan en realidad. Si vas a la carpeta refs, ahora verás esta carpeta con las etiquetas de nombre. Y ahí es donde vas a ver estas dos etiquetas. Pero anotan etiqueta en realidad se almacena como un objeto. Mientras que el tanque liviano es similar a una rama, no es un objeto. Entonces abramos Washington 101. Y está apuntando a un comentario específico. Tratemos de imprimir bastante este objeto con ese HashCode. Archivo Git cat. En primer lugar, echemos un vistazo al tipo de este objeto. Como se puede ver, está apuntando al objeto cometa. Si eres bastante imprime este objeto, vas a ver los detalles sobre ese commit. Pero ahora abramos el archivo, que era una etiqueta anotada y veamos a qué apunta. Déjame copiar este código hash, volver a Git Bash e intentar imprimir el tipo del objeto. Esta vez, esto va a ser de tipo tag. Y si le das un vistazo al contenido de este objeto tag, vas a ver el commit al que apunta. Y también hay algunos metadatos junto con él. Al igual que el identificador de la etiqueta, quién la ha creado, y alguna descripción sobre la etiqueta también. También podemos ver el estado del repositorio en una etiqueta en particular usando el comando git checkout. Entonces déjame hacer git tag para echar un vistazo a la lista de etiquetas disponibles. Y voy a usar el comando git checkout, especificando el nombre de la etiqueta. A lo mejor me gustaría llevar mi repositorio a esta fecha. Y como pueden ver, estamos en estado jefe desapegado. Ya lo hemos hablado en uno de nuestros capítulos anteriores. Pero si vuelves al directorio de trabajo, no vas a ver ese hot fix. Porque al momento de la creación de esta etiqueta, no tenemos esa solución. Espero que tenga sentido. Nos vemos a continuación. 110. 1409 lanza y creación de etiquetas en GitHub: De acuerdo, hablemos de lanzamientos. Según lo que GitHub tiene que decir sobre los láseres. Aquí está lo que dice. Puede crear una versión para paquete de software junto con las notas de la versión y enlaces a archivos binarios para que otras personas los usen. En esta convocatoria, vas a proporcionar alguna documentación técnica sobre tu lanzamiento. Por lo que querrías enumerar hacia abajo todos los cambios que forman parte del nuevo lanzamiento. Los pasos de instalación, los binarios son ejecutables, etc. Pondrías toda esa información como parte de las notas de la versión para ayudar a tus clientes o usuarios finales a entender todo sobre la nueva versión quenecesitan saber. Así que sigamos adelante e intentemos crear un nuevo lanzamiento en GitHub. Y por cierto, tu organización podría estar usando alguna otra herramienta para documentar el lanzamiento. Si no tienes ninguna herramienta de este tipo, podemos usar GitHub para la misma. Podemos asociar una etiqueta para un lanzamiento en particular. Podemos elegir uno de los existentes por ejemplo. O podemos seguir adelante y crear una nueva etiqueta. Y así es como vas a crear una nueva etiqueta en GitHub. Por ejemplo, tal vez se puede decir que un punto 0 punto dos, o lo que sea. Por el momento no tenemos ningún cambio nuevo. No tiene sentido que aumentemos la versión de nuestro software. En su lugar, solo vamos a usar una de las etiquetas existentes. Así. Vamos a darle un nombre. Suelte V, un punto o punto o por ejemplo. Aquí. Tu bicicleta se toma un tiempo para documentar todo lo relacionado con el lanzamiento. Entonces tal vez enumerarías todos los temas que se abordaron, todas las nuevas características que se introdujeron. Si hay alguna característica en desuso, también querrías enumerarlas. A lo mejor algunos pasos de instalación, descargable, ejecutable, Es etc. Pondrías todo lo que quieres que tu usuario final vea y entienda sobre el lanzamiento. Y una vez que termines con eso, seguirías adelante y publicarías el lanzamiento. Y así es como se ve. Obviamente no hemos poblado esto lo suficiente como para ver realmente algo significativo. Pero esto se libera para ti. Los clientes pueden pasar por toda la descripción sobre el lanzamiento. Y el bajo de guitarra subió automáticamente el código fuente. ¿ Alguien puede descargar si quisieran. Entonces de eso se trata. Nosvemos a continuación. 111. 1501 Desestima las aprobaciones de la solicitud de atracción stale para nuevos commits: Bien, hablemos de esta regla de predicción de sucursal que dice despedir cola, pull request aprobaciones, se empujan nuevas commits. Lo que esto significa es que cada vez que alguien plantea una solicitud de extracción y también asume que incluso la revisión está hecha, pero esa solicitud de extracción, ahora antes de fusionar esos cambios en alguna otra rama llevó a un equipo de dólar por kilómetro o cambios en la sucursal que queremos fusionar. Ahora bien, si permitimos que los cambios sean revisados una vez más, no son de su pupilo. Esta opción es decir, si habilitamos esta opción, eso significa que queremos ordenar el proceso de revisión, una vez más, revisar todos los últimos cambios antes de que pueda fusionarse con otro rama. Deshabilite esta opción, luego anote el abuso necesario para fusionar los cambios. Si has entendido lo que acabo decir, eso está bien y bien. Puedes saltarte el siguiente video. De lo contrario, sólo aguanta. Voy a demostrar lo mismo. Entonces ahora mismo esto está deshabilitado. Permítanme regresar al depositario y rápidamente plantear una solicitud de extracción para ello. Déjame crear otra rama con algún nombre aleatorio es df. Y vamos a tener también un commit. Tal vez agregando un nuevo archivo. Démosle algún nombre, algo así, y cometamos los cambios. Vamos a elevar la solicitud de extracción. Vamos a comparar la rama principal con la rama que acabamos de crear. Crear solicitud de extracción. Crear solicitud de extracción. Entonces esto ha creado las solicitudes de extracción. Necesitamos al menos una revisión aprobada antes de fusionar estos cambios. Ahora la misma persona que en realidad ha planteado una solicitud de extracción no puede revisar su propio código. Para eso. Ya agregué al señor Luke como uno de los colaboradores de este proyecto. Avísame, ve a la cuenta de Luke y acepta rápidamente los cambios. Entonces aquí está la solicitud de extracción de la cuenta de Luke. Y voy a agregar mi opinión voy a revisar estos cambios, aprobando todo. Ahora si vuelves a sumar esos segundos, vas a ver que los cambios fueron aprobados y que puedo seguir adelante y fusionar la pull request. Pero mientras tanto, antes de fusionar los cambios, permítanme intentar hacer otro commit en la nueva rama que acabamos de crear. Voy a volver a la base de código y a esa rama. Y déjame agregar otro archivo con algún otro nombre aleatorio, así y comprometerme los cambios. Si volvemos a las solicitudes de extracción, ahora también vas a ver esos nuevos cambios. este momento puedes ver que no se necesitan revisiones adicionales para fusionar las solicitudes de extracción. Eso es porque esta opción de aquí mismo está deshabilitada. Permítanme habilitar esta opción. Guardar cambios. Déjame ingresar rápidamente la contraseña. Y ahora si tuviera que hacer otro cambio y comprometerme con esta rama, déjeme hacerlo muy rápido. Algo de ese tipo. Comprometer los cambios. Si vuelvo a las solicitudes de extracción, esta vez, verás que necesitamos al menos una revisión una vez más antes de poder fusionar esos cambios. Bueno, ya que el domingo es el propietario de este repositorio, es capaz de ver esta opción para fusionarse realmente sin esperar a que se cumplan los comentarios o sin que se haga la visualización. Pero lo ideal sería que las solapas no puedan ver esta opción. Pero espero que haya entendido el punto de esta regla de protección de sucursal. Te veré a continuación. 112. 1502 Configuración de los propietarios de código con patrones Solicitud de revisión automática: Hablemos de esta regla de protección de sucursales diría que se requiere revisión por parte de los propietarios de códigos. Básicamente github nos permite crear un archivo especial con los propietarios del código de nombre, en donde podemos especificar quién es el dueño qué basado en patrones de archivos. Es algo similar a los patrones que estamos especificando un archivo gitignore de punto. Pero también especificamos quién es el dueño de los archivos que corresponden a esos patrones. Y al habilitar esta opción, nos llamaron automáticamente se solicitaría para su revisión. Siempre que alguien plantea una solicitud de extracción que modifica el código que posee. Sé que esto suena confuso. Y por eso voy a demostrar rápidamente el mismo fósforo. Vayamos a nuestro repositorio. Y aquí estoy en la rama principal, voy a crear un nuevo archivo. Voy a nombrar el archivo como código o enfermera. Tiene que ser exactamente el mismo nombre, todas letras mayúsculas. Y dentro de este archivo voy a especificar uno de los propietarios con un patrón. Por ejemplo, podría decir star dot js y todos los archivos con extensión dot js serían propiedad de let say, look, ya tenemos mirarlo como uno de los colaboran para resolver este proyecto. Entonces, donde quiera que vayas a agregar como propietarios, necesitan tener permisos de escritura para este proyecto. Así que permítanme copiar rápidamente la dirección de correo electrónico de Luke y pegarla aquí. También puedes añadir el nombre de usuario de Luke. De cualquier manera, luke ahora va a ser el dueño de todos estos archivos. Déjame llegar a este archivo. Ahora déjame intentar borrar las solicitudes de extracción con el archivo ab.js 1. Segundo, permítanme crear rápidamente alguna rama aleatoria. Y permítanme agregar rápidamente un nuevo archivo. Scripts punto js. Convertir el archivo. Ahora sigamos adelante y levantemos la solicitud de extracción. Y en el momento en que haga eso, verá esperando la revisión del propietario del código de Luke's under Corp. Ahora si vas a la cuenta de Luke, si hago clic en la solicitud de extracción, esta es la cuenta de Luke. Mira va a decir este mensaje diciendo que necesita revisar una solicitud de extracción. Entonces, dado que el hecho de que Luke es el dueño de todos los archivos dot js y alguien planteó pull request en la misma sucursal donde Luke fue agregado como propietario de estos archivos, get ha preguntado automáticamente Luke para revisar los cambios o la solicitud de extracción. Así que mira, ahora puedes hacer algo con esta revisión. Digamos que ha aprobado los cambios. Y ahora podemos seguir adelante y fusionar todos los cambios. Esta opción ya está habilitada. Ya lo había habilitado y guardé los cambios. Y de ahí, esto ha entrado en vigor. Si desactivamos esto, entonces Luke no habría estado recibiendo la solicitud de revisión. Volvamos al repositorio. Generalmente mantenemos el archivo de propietarios de código en la rama base o en la rama predeterminada. Dado que este archivo se encuentra actualmente ubicado en la sucursal principal, gerente o alguien plantea pull request pidiendo fusionar los cambios a esta sucursal. Ahí es cuando este código en espiral entraría en vigor. Entonces querrás mantener este archivo en una sucursal donde los desarrolladores contribuyan con su código. Fin. Por cierto, hay otro montón de patrones que podemos usar para los que puedes diferir a la documentación oficial, también se proporcionan notas que te dan algunos de los patrones de ejemplo junto con algunos descripción. Voy a mantener esto como notas que puedes descargar y tomarte tu tiempo tratando de entender esto. En realidad es bastante sencillo. Los patrones son más o menos similares a los patrones que incluimos en el archivo punto gitignore. Excepto que también vamos a especificar los propietarios tiene dos cuernos de archivos correspondientes a esos patrones. También puedes especificar equipos. Así que el equipo estaría siendo dueño de un conjunto particular de archivos. Como en este caso. Si sacas uno debate las membresías de GitHub para tu organización, entonces también puedes agregar consideres. Espero que tenga sentido. Te veré a continuación. 113. 1503 Mandar la resolución de la conversación antes de fusionarla: Bien, hablemos de esta regla de predicción de rama que dice que se requiere resolución de conversación antes de fusionarse. Y por cierto, vamos a ignorar hablar esta opción porque esto tiene algo que ver con herramientas externas. Y básicamente, si quieres realizar muchos tipos de comprobaciones antes de fusionar el código en otra rama, querrás habilitarlo. Y hablar de Esto definitivamente está fuera del alcance de este curso en particular porque esto tiene algo que ver con herramientas externas. Pero en términos generales, si quieres realizar algún tipo de comprobaciones como la exploración de vulnerabilidades, estás comprobando para ver algún error programático en el código. Nuestro realizar una integración continua o tal vez implementar el código en un servidor de compilación, obtener el estado de compilación, etcétera. Si quieres trabajar para muchos de ese tipo de cosas, cada vez que alguien plantea una solicitud de extracción, puedes configurarlas aquí. Y esto en realidad depende completamente los estándares de su organización y tenemos que seguir en consecuencia. Entonces tal vez cubriremos todo esto en otros cursos de DevOps, pero vamos a ignorarlo por ahora. Volvamos a esta opción que dice que se requiere resolución de criminalización antes de fusionarse. Permítanme habilitar esta opción. Demuéstrale lo que significa exactamente. Entonces básicamente los hombres a la contraseña muy rápido. Por lo que esta opción está habilitada. Déjame ir a las solicitudes de extracción que habíamos planteado antes. Y como se puede ver, actualmente podemos realizar la fusión debido a que su visión ya está hecha. Pero digamos que el señor Luke tiene un comentario que agregar en el código. Entonces vayamos a la cuenta de Luke. Permítanme abrir el archivo de esta solicitud de extracción. Y digamos que aquí tenemos un montón de líneas de código. Y Luke está poniendo algún comentario. Entonces tal vez algo así como algo de ese tipo. Déjame agrandarlo un poco. Entonces quiero agregar este comando, y vamos a hacer clic en cualquiera de estos botones. Permítanme añadir un solo comentario. Y como el hecho de que hubiéramos habilitado esa opción de regla de protección de sucursal, si ahora vuelvo a la solicitud de extracción de la cuenta de remitentes, déjame volver a cargar la página. Vas a ver que la fusión está bloqueada Una vez más porque hay conversaciones sin resolver. Supongamos que el remitente ha abordado este comentario y va a mencionar lo mismo contestando de nuevo para mirar. Sí, ya lo he comprobado. Algo de ese tipo. Eso es una vez más, volver a la cuenta de Luke. Se ha ido a ver la respuesta aquí. Y una vez que estés satisfecho con la respuesta, Luke va a resolver la conversación. Lo es. Entonces el remitente puede fusionar la solicitud de extracción. Si esta opción no está habilitada, entonces no es necesaria la disolución de la conversación para fusionar el código. Te veré a continuación. 114. 1504 Explorar todas las demás normas de protección de ramos: Hablemos de todas las reglas restantes de protección de sucursales aquí. Estos son bastante fáciles de entender y ya sencillos. Y así podemos encajar todos estos solos en este video. Salir de esta regla de predicción de rama diría que se requiere combates firmados. Esto en realidad requiere que entiendas qué se asignan commits, cómo podemos generar claves privadas y públicas para la firma, encriptación, descifrado, etcétera. Entonces este desierta en capítulo propio. Entonces vamos a hablar de esto en el próximo capítulo. Pero concluyamos este capítulo sobre la regla de predicción de ramas después de tocar rápidamente todas las otras opciones que tenemos aquí. Entonces tenemos esta opción que dice historia lineal requerida. Y como sugiere el nombre, no nos permite tener commits de fusión. Si tienes un commit de fusión, ya no estaríamos teniendo historial de commit lineal. Entonces digamos que he habilitado esta opción. Déjame guardarlo muy rápido. Si vuelves a las solicitudes de extracción, déjame hacer clic aquí. Estas son las solicitudes de extracción que habíamos planteado antes. Ahora bien, si elijo esta opción para crear un commit de fusión, vas a ver este mensaje diciendo, la rama Merge requiere historia lineal. Eso es porque habíamos habilitado esa opción. Pero aún así podemos ver esta opción para fusionar pull request. Eso es porque en realidad estoy haciendo esto desde este bajo segundo, ¿quién es el dueño del repositorio? Déjame editar esta regla de predicción de rama. Tenemos otra opción más para no dejar que eso suceda. Entonces aquí está. Si habilitamos esta opción que dice no permitir pasar por alto, ambas son configuraciones. Y la descripción del mismo dice que la configuración del codo se aplicará a los administradores y roles personalizados con el permiso de protección de derivación de rama. Lo que esto significa es que hasta ahora todas las reglas de producción de sucursales no se aplican realmente a los administradores, no se aplican realmente administradores ni a los propietarios del repositorio. Al habilitar esta opción, los administradores son los propietarios del repositorio, realmente no pueden eludir las reglas de producción de la sucursal. Permítanme habilitar esta opción y guardar los cambios. Ahora si vuelvo a pull request, siendo Sender el administrador del repositorio, ya no podría elegir esta opción. Esto se atenuó. Tampoco puedo hacer clic en él. Si tomas la licencia de organización de GitHub, deberías poder crear un equipo de individuos. Algunos de ellos son Edmond, Algunos de ellos son mantenedores. Podrían tener diferentes roles. Y al habilitar esta opción, las reglas de predicción de rama de aplicación de años dadas para los administradores son el mantenimiento del repositorio. Entre estas dos opciones, tenemos esta opción que dice implementaciones requeridas para tener éxito antes de fusionarse. Bueno, puede usar esta regla para asegurarse de que los cambios se implementen con éxito sin problemas en esta puesta en escena o las pruebas y Romanos antes de que los cambios se puedan fusionar con la rama predeterminada. Ahora bien, esto depende de tu organización que las herramientas que estés usando. Actualmente no tenemos ningún despliegue y configuración romana. Entonces realmente no podemos demostrarlo. A lo mejor este es tema de otro curso. Entonces vamos a saltarnos eso. Y nos quedamos con un par de opciones de regla de predicción de rama. Y estas opciones son aplicables a todos, incluidos los administradores. Hola, los empujes de fuerza significarían que queremos cargar los empujes de fuerza a las ramas protegidas. E incluso podemos elegir quién puede hacer eso. ¿ Si queremos permitir a todos con eje push, como colaboradores por ejemplo? ¿ O queremos elegir específicamente a quién queremos un empuje de baja fuerza? Por ejemplo, Luke ya se agrega como uno de los colaboradores. Puedo elegirlo, por ejemplo, si quisiera. Y finalmente, tenemos una carga de eliminaciones. Entonces, al habilitar esta opción, estamos permitiendo que las personas con Bush Axis puedan eliminar las ramas que coincidan con este patrón. En este caso, estamos diciendo que todas las reglas de predicción de esta rama son aplicables para la rama principal. Y así, al habilitar esta opción, estamos permitiendo que las personas con acceso push puedan eliminar esta rama en particular en este caso. Entonces eso es todo acerca de las reglas de protección de sucursales. Una vez más, vamos a explotar esta opción. En el siguiente capítulo. Teveré a continuación. 115. 1601 imitando los compromisos y la necesidad de haber velado los compromisos: Ahora déjenme demostrarle algo realmente interesante. Seguro que te sorprendería ver que esto sucede. Por el bien de este ejemplo, voy a estar usando uno de los repositorios existentes que hemos estado usando a lo largo de este curso. Por si perdiste el control de lo que trata este repositorio. Solo piensa en esto como algún repositorio aleatorio con un montón de archivos en él. Actualmente este proyecto cuenta con estos dos colaboradores. Tenemos remitente que es el dueño del repositorio, y Luke, quien es uno de los colaboradores de este proyecto. También por el bien de este ejemplo, he inhabilitado las reglas de producción de sucursales para la sucursal principal. Y de ahí que estés viendo este mensaje que dice que tu sucursal principal no está protegida. Ahora una pregunta para ti. ¿ Es posible que el señor Luke haga un comentario a nombre de cilindro sin tomar su consentimiento? Bueno, vamos a echar un vistazo. Imagínese que esta es la computadora del señor Luke. Y para ahorrarle tiempo, ya he clonado el proyecto. Déjame abrir Git Bash aquí. Déjame ejecutar el comando git config para que no eche un vistazo a las configuraciones actuales. Y como puedes ver, usuario y el correo electrónico están apagados. nombre de usuario del señor Luke es Luke's en la Corp y la dirección de correo electrónico es la dirección de correo electrónico Déjame intentar cambiarlos a Saunders. Voy a decir git config nombre de usuario global. Voy a dar el mismo nombre de usuario de Dosis GitHub, así. Y de manera similar, también vamos a cambiar la dirección de correo electrónico y actualizarla con algunas de esas direcciones de correo electrónico. Puedo obtener esto fácilmente en este nombre y dirección de correo electrónico. Pero en el comando git log. Y echando un vistazo a algunos de los comentarios que hizo el señor cilindro. Ahora si hago git config list, vas a ver que el nombre de usuario y la dirección de correo electrónico o no, actualizado con cilindros es un nombre y su dirección de correo electrónico. Permítanme ahora tratar de hacer un compromiso y ver qué va a pasar. Déjame crear rápidamente un archivo con algún nombre aleatorio. Y me voy a quedar como ese archivo muy rápido, git agregar nombre del archivo. Y finalmente git commit con algún mensaje. Vamos a llamarlo cometer mal. Y también voy a empujar estos cambios al repositorio de GitHub. Ahora vamos a GitHub y echemos un vistazo a cómo se reflejaron las cosas por ahí. Actualmente estoy en la rama principal. Déjame volver a cargar la página e ir a cometer. Y como puede ver, podemos ver el compromiso que acaba de hacer el señor Luke. Pero si nota lo que aquí se muestra, dice que este compromiso ha sido hecho por el señor Sunda y está apuntando al perfil de las cenizas. Curiosamente, algunos que no tienen idea alguna de que se haya hecho este comentario. Para alguien que mira el historial de cometer. Van a pensar que esta comisión en realidad está hecha por sunder todo el día, no lo hace el que en realidad ha hecho este comentario. Esto está pasando porque bueno asume que ¿qué los están usando? Una dirección de correo electrónico que se configuró en configuraciones es la misma persona que realmente está haciendo la confirmación. No obstante, tal vez ese no sea el caso. Y lo acabo de demostrar por ti. Esto no necesariamente tiene que ser hecho por colaboradores existentes del proyecto. Alguna persona al azar para el proyecto, y elevar la solicitud de extracción con un montón de commits imitando que esos comentarios en realidad fueron hechos por algún otro usuario, lo que obviamente no es algo que esperaríamos que sucediera. Entonces necesitamos algún tipo de proceso de verificación que verifique para ver si el autor del commit es la misma persona que realmente ha hecho el comité. Y ahí es donde entrarán en escena los commits verificados. Y de eso vamos a hablar a continuación. 116. 1602 Comprender las firmas digitales: Antes de entender lo que nuestro signo compromete, tratemos de entender qué es exactamente una naturaleza distorsionada. No en el contexto de Git y GitHub. Pero en general. Supongamos que tenemos a Bob y Alice. Y Bob quiere mandarle un expediente a Alice. Si envía el archivo como es a Alice, entonces podría suceder que alguien interfiera en la red, manipule el archivo antes de que llegue a Alice. Y Alice no tiene forma alguna de verificar si el archivo ha sido manipulado o si Bob es realmente el remitente. Entonces teniendo eso en mente, Bob va a hacer algo al respecto. Lo que va a hacer es que va a utilizar algún tipo de herramienta para crear la llamada clave pública. Y una clave privada. La clave privada, como su nombre indica, no se supone que se comparta con nadie más. Va a ser con Bob. Y va a guardarlo de forma segura en algún lugar de su sistema de archivos local. Por otro lado, la clave pública se puede compartir con cualquier otra persona. Cualquiera que quiera recibir el mensaje o archivo de Bob en realidad puede tener una copia de la clave pública. En este caso, Bob va a compartir la clave pública con Alice. Alice da sería útil en tan solo un rato. Entonces esta vez, antes de que Bob le envíe el archivo a Alice, va a utilizar su clave privada para firmar digitalmente el documento. Pero, ¿cuál es la distancia que la naturaleza? Bueno, la firma digital es esencialmente un hash de los datos que están encriptados, pero la clave privada del firmante. Ya hablamos del hachís en una de las conferencias anteriores. Pero solo para resumir, valor hash es un valor numérico de una longitud fija que identifica de manera única un dato. O en este caso este expediente. Si haces los mismos datos o el archivo como una función de entrada a hash, haría exactamente el mismo valor hash único sin importar cuántas veces lo hagas. Pero si cambias los datos o el contenido del archivo aunque sea un poco, la función hash devolvería un valor hash completamente diferente. Entonces, esencialmente, el valor hash identifica de manera única un dato dado o un archivo. Cuando digo archivo de datos o un mensaje, todos significan lo mismo. Entonces Bob enviaría el archivo a Alice a través de la red. Ahora Alice tiene que verificar si el mensaje ha sido manipulado fuera del remitente es realmente bombardeado. Ojalá lo vayas a hacer. Bueno, va a usar la clave pública de Bob para descifrar la firma digital y extraer el valor hash de ella. Bueno, cuando digo que va a hacer eso, no es exactamente ella quien va a hacer eso. Ella va a usar algún tipo de herramienta que haga eso. Entonces utilizaría algún tipo de herramienta para averiguar el valor hash del archivo enviado también. Estos dos valores hash son exactamente los mismos, entonces podemos estar seguros de que los datos no han sido manipulados. Y si ella es incapaz de descifrar la firma digital, eso significa que alguien más ha enviado el archivo usando su clave privada y no la clave privada de Bob. Si la firma digital se firma con otra clave privada, Alice no sería capaz de descifrar la naturaleza discursiva usando la clave pública de Bob. Para que de esa manera pueda estar segura de que el archivo no ha sido manipulado y que el archivo en realidad viene de Bob. Si has entendido esto, entonces entender la firma verificada no debería ser un gran problema. continuación vamos a hablar de firmas verificadas. 117. 1603 Comprender los compromisos firmados: Hablemos ahora de commits verificados. El concepto de comentarios verificados no es diferente del concepto de firmas digitales que hemos hablado antes, excepto en lugar de Bob Dylan para haber metido en lugar de Alice. Vamos a tener GitHub. Y en lugar de este archivo, vamos a tener la coma. Supongamos que Luke quiere asignar distalmente un commit y empujarlo al repositorio de GitHub. En GitHub, queremos verificar si ese commit realmente ha venido de Mr. loop. Entonces inicialmente, Luke va a generar claves públicas y privadas, va a subir su clave pública en su cuenta de GitHub. Y va a usar la clave privada para firmar los comentarios. Una vez más, no es exactamente Luke quien haría todo eso. Todo sería atendido por get, sólo ejecutar un simple comando. Cuando ejecuta ese comando, git esencialmente va a asignar distalmente el commit. Y una vez después del bucle empuja el commit a GitHub en el sitio GitHub. Github verificará si ha venido de Luke usando su clave pública. Echemos un vistazo a los pasos de detalle involucrados en todo este proceso. Entonces inicialmente clave local, de género, pública y privada usando alguna herramienta, luego subiría la clave pública en su cuenta de GitHub para que GitHub pueda utilizarla para verificar los commits. Local distal asignar el commit usando su clave privada. Simplemente ejecutando un comando. Luke entonces empujará los cambios a GitHub. Github verificará el commit usando la clave pública de Luke. Si GitHub no puede descifrar los comanches y parece clave pública. Significa que el comediante viene del señor Luke. Alguien más podría haber hecho que ese commit no es su clave privada. continuación vamos a ver toda esta inacción. 118. 1604 Creación de claves públicas y privadas usando GPG: Bien, veamos cómo podemos crear claves públicas y privadas. Ahora suponga que esta es la computadora del señor Luke, y ahora planea crear claves públicas y privadas para él mismo para que puedan ser utilizadas más adelante en el tiempo para su verificación. Para crear esas claves, vamos a estar usando una herramienta llamada GPG, significa GNU Privacy guard. Y es algo que no tienes que instalar por separado. Si ya tienes instalado Git en tu computadora y llegar a ya viene incluido con la herramienta GPG. Y no tienes que instalarlo por separado. En caso de que no estés usando Git Bash, que con una búsqueda rápida en Google, deberías poder encontrar instrucciones sobre cómo instalar GPG para tu sistema operativo. Sin embargo, en este caso, vamos a estar usando Git Bash para lo mismo. Y también asegúrate de no ejecutar estos comandos en la carpeta del repositorio. Para ello, en realidad he creado una nueva carpeta en mi escritorio y aquí es donde voy a ejecutar los comandos. Entonces, antes que nada, asegurémonos de que GPG esté realmente instalado ejecutando el comando GPG dash dash version. Y esto debería mostrar una salida como esta. Ahora ejecutemos el comando para crear las claves públicas y privadas para el señor Luke. El comando para eso es GPG, dash, dash, dash, generate key. Esto nos va a incitar con pocas preguntas. Veamos qué podemos responderles. Aquí tenemos que elegir el algoritmo que queremos usar para generar las claves. Gpt soporta todos estos algoritmos que se enumeran aquí. El predeterminado es el algoritmo RSA, y es el algoritmo que recomiendo usar. Así que simplemente voy a golpear Enter para elegir la opción predeterminada, que en este caso es el algoritmo RSA. A continuación, se nos pidió que ingresáramos el tamaño de la clave. El tamaño máximo de clave que podemos ingresar es de 4,096 bits. Y este es el requisito mínimo para GitHub. Entonces vamos a decir 4 mil 096. Golpea Enter. Aquí nos está pidiendo que ingresemos por cuánto tiempo debe ser válido el caso. Quiero que sea válido para siempre. Voy a dejar la opción por defecto, que es 0. Así que k nunca expiraría. Y deberíamos poder usar estas claves para siempre hasta el momento en que las eliminemos o hagamos algo con ellas. Vamos a presionar Enter para usar la opción predeterminada. Ahora nos está pidiendo conformarnos si realmente pretendemos no caducar la clave en absoluto, yo escribiria y, solo di que si, pulsa Enter. Ahora nos está pidiendo que ingresemos el ID de usuario. Aquí. Voy a proporcionar el nombre de usuario de la cuenta de Mr. Luke's GitHub. Ya lo tengo a mano. Simplemente voy a copiar y pegarlo aquí. Y claro, en tu caso, necesitas ingresar tu nombre de usuario de GitHub. En el siguiente aviso, voy a proporcionar la dirección de correo electrónico de Luke. En tu caso, quieres proporcionar tu dirección de correo electrónico que usaste para registrarte en GitHub. Entonces, esencialmente, ¿cuáles son el nombre y la dirección de correo electrónico que quieres usar para hacer tus commits? Debería proporcionarlos por aquí. Opcionalmente también podemos proporcionar un comentario, pero no me gusta proporcionar nada. Por lo que acabo de darle a Enter. Ahora nos está pidiendo verificar el ID de usuario que acabamos de ingresar. Así que vuelve a verificar y asegúrate de que sea correcto. Una vez que te quites la playera, sólo tienes que introducir el personaje o para decir L K. Se están generando claves. Ahora es posible que recibas un mensaje pidiéndote que ingreses la frase de contraseña. Esto es solo una seguridad adicional para proteger su clave privada. Si alguien te robara tu clave privada, debería poder conocer esta frase de contraseña para poder usar tu clave privada. Esto es solo como una medida de seguridad adicional. Simplemente puedes presionar OK sin ingresar nada. De esa manera, no tienes ninguna frase de contraseña. Sin embargo, obviamente se recomienda que proporciones una frase de contraseña. En mi caso, simplemente estoy entrando por cactus, que no es tan seguro. Si lo quieres más seguro, entonces da una frase de contraseña muy fuerte con combinación de caracteres, números, símbolos, etc. y mi conjetura sólo va a ser cuatro caracteres. ¿Está bien? Obtienes otro aviso rápido que la contraseña no es muy segura, ya que es muy fácil de adivinar. Pero me gustaría usar esa de todas formas. Entonces elijo esta opción que dice tomar esta de todas formas. Me está pidiendo que vuelva a entrar en la frase de contraseña. Voy a hacer justamente eso y golpear Bien. Ahora, mientras se está generando la clave, se recomienda que realices algunas actividades en tu computadora como mover el mouse, ingresando algo en el teclado, etcétera. Y eso es lo que se está recomendando aquí. Dice, necesitamos generar muchos bytes aleatorios. Es una buena idea realizar algunas otras acciones como escribir en el teclado, mover el mouse, utilizar eso, esto, etc. para que la clave que se genere sea más aleatoria. Entonces ambas son claves que se generaron. Puede verificar si se generaron ejecutando el comando GPG con la opción list case. Entonces voy a decir GPG dash, dash, list, dash keys. Por lo que esto ha mostrado la clave pública. Y si dices lista guión, caso secreto, esto va a mostrar los detalles sobre la clave privada. Este no es el caso real. Estos son solo los detalles sobre las claves. Esto va a ser útil en solo un poco. Te veré a continuación. 119. 1605 Exportar clave pública y actualizar la clave de GPG en GitHub: Bien, ahora que hemos creado claves públicas y privadas, intentemos ahora exportar la clave pública para que podamos poner en la cuenta de GitHub de Luke. Y el comando para eso es, vas a configurar GPG. Hyphenate significa armadura. Esta opción es exportar la clave en formato ascii o mode en lugar de binario. Y luego vamos a decir dash, dash , exportarlo para exportar la clave. Y luego vamos a especificar el ID de clave. Ahora, ¿cuál es el ID de clave de nuestros comandos anteriores? Si te das cuenta, donde hemos verificado la clave pública y la creación de la clave privada, también se ha impreso el ID de clave. Y si te das cuenta, la idea clave de las claves tanto públicas como privadas son exactamente la misma. Eso es porque la clave privada no tienen una clave separada ideas tales. Y así GPG solo está mostrando el ID de clave pública a la que se paga la clave privada. Simplemente voy a copiar este identificador. Alternativamente, también puedes usar los soportes UID para User ID, y nosotros también podemos usar el mismo. Pero generalmente se recomienda usar el ID de clave en lugar del UID. Porque en pocas palabras, podría causar conflictos si tienes un KeyStore. Entonces usemos esto para exportar la clave pública. Podemos copiar el texto del bloque de clave pública PGP de inicio. Todo el camino hasta este punto donde vemos el texto y el bloque de clave pública PGP. Simplemente voy a copiarlo. Alternativamente, puede ejecutar el mismo comando. Y usando una llave angular, podemos exportar la clave pública en su archivo. Clave de punto pública, por ejemplo, donde el público se exportaría. Si lo deseas, también puedes exportar la clave privada. Por el momento. Notenemos que hacer eso. Pero sólo estoy demostrando cómo podemos hacer eso. Entonces, en lugar de decir solo exportar, vamos a decir exportar clave secreta dash. Y esto también exportaría clave privada. Y cuando hagas eso, vas a recibir un aviso pidiéndote que ingreses la frase de contraseña. En mi caso, es solo para frase de contraseña de personaje. ¿ Cuál es la frase de contraseña que has creado? Eso pretendía aquí. Una vez que golpeé Bien, tenemos la clave privada volcada en este archivo. Entonces veamos si podemos ir ahí. Si abro este directorio, van a ver estos dos archivos creados. Vamos a abrir el archivo de clave de punto público con Notepad Plus, Plus. Y vas a ver el mismo texto que se vieron en Git Bash. Simplemente voy a copiar esto. Y ahora voy a ir a la cuenta de Luke en GitHub. Esto se ve cuenta de GitHub. Voy a dar click sobre este icono. Y si te desplazas un poco hacia abajo, vas a ver Configuración. Haga clic en eso. Y en el menú del lado izquierdo, haga clic en, haga clic en las teclas SSH y GPG. Y aquí ves opción. Para dar una nueva clave GPG. la sección clave, vas a pegar mortero acaba de copiar la clave pública, título opcional Ignacio, y hacer clic en Agregar clave GPG. A continuación vamos a ver cómo podemos firmar los commits. Te veré a continuación. 120. 1606 Hacer que el compromiso firmado establezca la configuración global verificando los compromisos firmados en GitHub: Bien, veamos cómo podemos hacer commit asignado y conseguir que se verifiquen en GitHub. Ya tengo la mente pública CAP clonada aquí. Déjame abrirlos, obtener bash en el directorio raíz de proyectos. Déjame primero ejecutar el comando git config list. Y como puedes ver, usan el nombre y el correo electrónico se actualizan al de las cenizas, lo cual no es lo ideal. Veamos qué va a pasar una vez que hagamos asignado a cometer. Así que permítanme crear un archivo aleatorio, algo por el estilo. Déjame escenificarlo. Y por cierto, no estoy haciendo esto en la rama principal. Acabo de elegir rama algo aleatoria. En este caso, el nombre de la sucursal es QQQ, que se creará aleatoriamente en una de nuestras conferencias anteriores. No me dejes tratar de hacer asignado a cometer. El comando para eso es git commit. Guión mayúscula, Sí. Asegúrese de que esto sea mayúscula. Sí. De lo contrario, este paseo. Si quieres firmarlo etiqueta, entonces tiene que ser una minúscula. Sí. Entonces guión mayúscula sí. Y guión md para dar algún mensaje a esta confirmación. Llamémoslo mi compromiso o lo que sea. Por lo tanto, el commit ha fallado. Y el mensaje dice que no hay clave secreta. Para el señor Sunda. El ID de usuario de la clave que hemos creado es a eso fuera de Luke's. Pero los buenos conflictos son tener las credenciales a menudo sin embargo. Ambos no coincidieron con Enter. No podemos hacer una señal para comprometernos en este caso. Así que sigamos adelante rápidamente y cambiemos las configuraciones. usuario va a ser GitHub, nombre de usuario de Luke. De igual manera, vamos a actualizar los melodramas a la de parece así. Ahora intentemos hacer commit asignado. Por primera vez lo haces. Se le pediría que ingresara la frase de contraseña. Voy a entrar justo en eso. Golpeado. ¿Bien? Y nuestro compromiso con el éxito. Intentemos ahora empujar estos cambios a GitHub. Así que somos capaces de empujar este commit que ha ido a GitHub y ver qué se reflejó ahí. Así que actualmente estoy en mi repositorio público de aplicaciones y estoy en esta rama, QQQ. Déjame recargar la página. Y como pueden ver, podemos ver el comentario que se acaba de hacer. Y esta vez es con placa verificada. Entonces github es capaz de buscar la clave pública del señor Luke, el autor de The commit, para verificar si el comité es hecho por el señor Luke. Así sucede el proceso de verificación. Si le quitara la clave pública al señor Luke, entonces la placa verificada ya no estaría ahí. Podrías decir levántate diciendo que la verificación no tiene éxito. Y por cierto, si no quieres hacer guión S opción cada vez que quisieras firmar un commit, en realidad podemos introducir un buen conflicto para eso. Entonces vas a decir git config global climate dot JPG sign. Y vamos a poner esto en verdad. Entonces, cada vez que quieras hacer confirmación de firma, no tienes que proporcionar explícitamente la opción guión S. Si estableces esta bandera. Adicionalmente, si tienes varias claves privadas, para evitar ambigüedades, también necesitas hacerles saber qué K12 privado usa para firmar los commits. El conflicto para eso es la clave de firma de usuario. Y vas a proporcionar el ID único de la clave, GPG. Llaves. Puedes proporcionar esta identificación, así. Digamos que hay una persona con intención negativa. Ha creado una clave privada usando las credenciales de Luke y asume que incluso ha empujado el commit al repositorio en el sitio de GitHub. Github no podrá verificar esa confirmación usando la clave pública en la cuenta de Luke. Y de esa manera levantarse sería capaz de verificar que el comité en realidad no viene del señor Luke. Espero que tenga sentido. Teveré a continuación. 121. 1607 Compromisos firmados que firman los compromisos de la firma del código VS: Bien, no hablemos esta regla de predicción de rama que habíamos dejado fuera antes. Dice que se requieren commits firmados. Ya deberías ser capaz de entender esto. Si habilitas esta opción, lo que eso significa es que solo queremos permitir a los cometas señalizados en las ramas coincidentes. Tan simple como eso dice, Este video va a estar muy filmando. Permítanme incluir también una cosa más. Echemos un vistazo a cómo podemos tener firmados commits desde Visual Studio Code. Para eso, permítanme abrir este proyecto usando Visual Studio Code. Entonces la configuración para eso es que necesitas ir al menú Archivo, Preferencias, configuración y buscar. Déjamehacerlo otra vez. Ajustes y búsqueda de GPG. Debe habilitar esta opción que dice habilitar la firma de compromiso. Cerrar ajustes. Hagamos rápidamente una edición en uno de los archivos solo para que podamos cometer algo. Me han puesto en algún texto aleatorio, guarda el archivo. Y déjame comprometerme los cambios. Firmar desde el código VS, algo por el estilo. Y déjame hacer el compromiso. Es posible que se te pida que ingreses la frase de contraseña. Por favor, ingrese y haga clic. Bien. Como ya hice esto antes, no volví a recibir ese aviso. Pero si vas ahora a GitHub y vuelves a cargar la página, claro, necesitamos empujar esos cambios para poder verlos en GitHub. Entonces hagámoslo rápidamente. Vamos a recargar la página. Y como puedes ver, podemos ver ese commit y también se verifica. Espero que tenga sentido. Teveré a continuación.