Transcripciones
1. Introduccion: ¿Estás listo para subir de nivel
tus habilidades de desarrollo? Ya sea que seas
completamente nuevo en él o quieras llevar tus
conocimientos al siguiente nivel, este curso es perfecto para ti. Aprende lo esencial
desde cero y sumérgete en
funciones más avanzadas a medida que avanzas. Git es el sistema de control de
versiones estándar de la industria utilizado por desarrolladores de todo el mundo. Masterizar Git te ayudará a
colaborar de manera más eficiente, realizar un seguimiento de los cambios y administrar
tu proyecto con facilidad En este curso, te guiaré a
paso a través de lo básico. Entendemos qué es, cómo usarlo y por qué es una herramienta esencial
para los desarrolladores. Comandos principales,
aprenda a cometer, crear ramas, fusionar
y revertir cambios Colaboración, aprende a trabajar sin problemas con
equipos usando GitHub. También descubrimos rebasar y
cómo resolver conflictos. Es muy recomendable
que sigas
escribiendo los comandos tú mismo
mientras trabajas el curso. Este enfoque práctico
ayudará a solidificar tu comprensión y hacer que
aprenderlo sea más efectivo La práctica es la clave para
dominar la herramienta. Comienza a
dominarlo hoy y luego bloquea infinitas posibilidades
en tu viaje de desarrollo
2. Instalación y configuración de Git: comprensión de los parámetros globales y locales: Hola, chicos. Hoy
cubriremos los siguientes temas. ¿Qué es GID? ¿Para qué
se utiliza y cómo trabajar con
él? Entonces, ¿qué es GID? Git es un
sistema de control de versiones utilizado para administrar y rastrear cambios en el
código de software y otros archivos. Permite
a los desarrolladores colaborar en proyectos y realizar un seguimiento de diferentes versiones
del código. En otras palabras, Git
almacena todos los cambios realizados tu código en una
base de datos especial llamada repositorio. Con GIT, podemos ver el historial del proyecto para
ver quiénes hicieron los cambios, cuándo se hicieron y
cuáles fueron esos cambios. Sin GID, los miembros del equipo
realizarían cambios en sus copias
locales de archivos y realizarían un seguimiento
manual
de diferentes versiones cambiando el nombre de los archivos o
creando copias Los equipos a menudo
pasaban archivos de lado a otro por correo electrónico o unidad de red
compartida. Si dos miembros del equipo trabajaran simultáneamente
en el mismo expediente, tendrían que
coordinarse entre sí para evitar conflictos. Si se cometiera un error
o se perdía un archivo, no
habría manera de
volver a una
versión anterior del código La consola o interfaz de
línea de comandos es una de las
herramientas más primarias para trabajar con GID. Sin embargo, requiere que
los usuarios tipeen comandos usando
sintaxis y terminología específicas, lo que puede resultar intimidante
para los principiantes. Agradecidamente, Git está
integrado en el código de
Visual Studio como una
herramienta para el control de versiones Esta integración proporciona una
interfaz gráfica de usuario para Git, lo
que facilita a
los desarrolladores el uso Git sin necesidad de
memorizar la sintaxis de la línea de comandos El código de Visual Studio
también ofrece una variedad de extensiones que mejoran la funcionalidad de
Git. Puedes encontrar muchas extensiones de
Git en el mercado de Visual Studio
Code que ofrecen funciones condicionales. Para aquellos que prefieren la interfaz
visual para Git, también
hay herramientas de interfaz
gráfica de usuario independientes disponibles para diferentes sistemas
operativos. Algunas de estas herramientas son
gratuitas mientras que otras son de pago. Empecemos por configurar Git. Primero, ve al sitio web de GIT e instala Git para
tu sistema operativo. No lo voy a instalar porque
ya tengo instalado Git. No es difícil. Sólo tienes que
seguir las instrucciones. Para Linux, puedes usar
sudo Opt Install Git. Para Mac, simplemente descargue y haga
doble clic para Instalar. Antes de empezar a
trabajar con Git, hablemos de algunas configuraciones. La configuración global
se refiere a la configuración que se aplica a todos los
repositorios de Git en su máquina Las dos opciones globales más comúnmente
configuradas son tu nombre y
tu dirección de correo electrónico. Estos se utilizan para identificar quién realizó cada commit
en el repositorio. Al establecer tu nombre y correo electrónico
globalmente en tu máquina, Git los registrará
con cada confirmación. Esto permite a otros usuarios ver quién realizó cambios en
el repositorio. Este comando nos permite ver la configuración
global ya instalada y git. Aquí puedes ver nuestro nombre
global y correo electrónico. Si necesitas un nombre
o correo electrónico diferente para proyectos específicos, puedes usar
configuraciones locales. Las configuraciones locales se aplican
solo a un repositorio específico, mientras que la configuración global
se aplica a todos los repositorios Puedes establecer los ajustes de
configuración global usando el comando Git config
con la bandera global mientras que
los ajustes locales se establecen usando Git config sin
la opción global dentro de un repositorio específico, ve al
directorio de tu proyecto y establece el nombre y el correo electrónico solo
para este repositorio. Puedes usar el comando Git
config list para ver todos los ajustes, tanto globales como locales. Aquí puedes ver nuestro usuario global y los ajustes locales
que acabamos de configurar. Este comando muestra solo los
cambios en la configuración local. Aquí podemos ver el nombre de
usuario y el correo electrónico específicamente establecidos para este
proyecto usando este comando, pero con la opción, global,
solo podemos ver la configuración global. Nuevamente, solo por recordatorio, configuración
general con configuraciones
locales y globales. Para desestablecer una configuración, use el comando Git config
and set Por ejemplo, para eliminar
el nombre de usuario local, utilizamos este comando. Tecleo Git config, dash dash set nombre de usuario. Esto eliminará el nombre de
usuario local de la configuración, pero la
configuración global seguirá estando en su lugar y se utilizará para las commits. Aquí podemos ver claramente que
eliminamos el nombre de usuario y el correo electrónico. También podemos desestablecer los correos electrónicos globales usando
el mismo comando, pero con el prefijo global Esto eliminará el
correo electrónico global de la configuración. Cada sistema operativo, Windows, Mac o Linux, puede usar un formato diferente
para las terminaciones de línea Estas diferencias
pueden causar problemas al compartir archivos
en un repositorio Git, especialmente cuando se trabaja en diferentes sistemas operativos. Para evitar este problema, puedes configurar Git para maneje el final de línea
automáticamente. Esto asegura que los archivos permanezcan
consistentes, libres de errores y se comporten como se esperaba, incluso cuando se realiza el check-out en
diferentes sistemas operativos. Cuando se trabaja en un equipo de
ambiente mixto, estas discrepancias pueden causar conflictos
innecesarios de Div Smtch o problemas en la ejecución de código Al configurar Git para manejar las terminaciones de
línea automáticamente, te aseguras de que los archivos sean consistentes en todas las plataformas, evitando errores y errores
relacionados con las terminaciones de línea Por ejemplo, en Windows, puede configurar Git para que
convierta automáticamente las terminaciones de línea al formato de
Windows configurando el punto
central Atoserf sistemas basados en Unix
como Linux o Mac, puedes configurarlo para input, ya que esta configuración puede
afectar a todos tus proyectos. Lo mejor es
configurarlo globalmente para garantizar la uniformidad en todos los
repositorios en los que trabaja Editores modernos como Vscde, Intelligda y texto sublime manejan las diferencias de línea automáticamente Detectan el formato CLF
o LF y ajustan según sea necesario. Entonces, en muchos casos,
no notarás ningún problema a menos que
trabajes en equipos multiplataforma. Pero la configuración core out un Serra 11 Git sigue siendo una buena práctica para prevenir
posibles problemas. En la siguiente lección,
comenzaremos el proyecto desde cero y aprenderemos los comandos básicos de
Git. Nos vemos.
3. Repositorio de trabajo en etapa en base git comm: Bienvenidos de nuevo, chicos.
Comencemos nuestro primer proyecto, creamos un directorio y naveguemos hasta él usando
la línea de comandos. Ejecuta el comando ls menos A para ver todos los archivos
y directorios, incluidos los ocultos, y vemos que esta carpeta
está completamente vacía. Para inicializar un
repositorio Git en este directorio, usa el comando Git init. Esto crea una carpeta Git de
punto oculto, que contiene todos
los archivos
y directorios necesarios para
el repositorio. En este punto, el repositorio está vacío y aún no
contiene ningún commit. La carpeta git es la
columna vertebral de tu repositorio. Incluye la base de datos Git, que rastrea todos los cambios. El índice, que se
utiliza para archivos de ensayo ,
archivos de
configuración local. Aquí podemos ver los ajustes. También puede notar una
carpeta llamada hooks. Estos son scripts
que Git puede ejecutar automáticamente en
puntos específicos de tu flujo de trabajo. Nota muy importante, nunca borres la carpeta git manualmente, ya que es fundamental que el
repositorio funcione. Muy bien, vamos a crear un
archivo llamado textixty. Lo siento, mi imaginación
está un poco rezagada hoy. Si repetimos el LS
menos un comando, podríamos notar otro archivo
como el almacén de DC en macOS. Yo uso el sistema macOS. Entonces tengo esto. ¿Qué son los archivos de la tienda DC
si estás usando macOS? Por lo que es posible que haya encontrado
en estos archivos. Estos archivos son
generados automáticamente por el sistema
operativo macOS. Están ocultos de forma predeterminada y almacenan metadatos sobre una carpeta, como el tamaño y la
posición de los iconos, las opciones de
visualización de la
carpeta, etc. Si bien estos archivos ayudan a macOS a
recordar cómo te gusta ver tus carpetas. Pueden causar problemas al usar sistemas de control de
versiones como Git. El comando Git status muestra el
estado actual de tu repositorio. Proporciona información
sobre los cambios
realizados en archivos
como archivos que están
modificados pero que aún no escenificado o escenificado y
listos para un En la salida del estado de Git, verás archivos que
están preparados para Comit. Entre ellos, es posible que notes archivos no deseados
como la tienda DCIS en macOS, que pueden abarrotar
tu repositorio Para evitar que Git rastree la tienda
de DC u otros archivos innecesarios, puede crear un archivo
GIT Ignore global. Este archivo se aplicará a todos los repositorios de Git
en su sistema Aquí te explicamos cómo configurarlo. Vaya a su directorio raíz y cree un archivo oculto
para el Global. En DStore o cualquier otro archivo que quiera ignorar a este archivo Aquí puedes ver dos líneas. El primero, Distore ignora solo la coincidencia exacta del
DStorfle El segundo, Distor
ignora cualquier archivo que comience con DStore y
seguido exactamente de un Potencialmente puede ser
Distor uno o Distor dos. Esto proporciona
protección adicional contra nombres de archivos
similares pero ligeramente
alterados. Y por último, configura Git para usar este archivo global Ignorar. A partir de ahora, DesisOrfles será ignorado en todos
tus Puedes verificar esto
ejecutando el comando Git status. El DesisorFle ya no
aparecerá en la lista
de Vamos a agregar y organizar
archivos en Git. Vamos a crear otro archivo, escribir algún contenido en él, como hola y verificar el
estado usando el estado de Git. Git te mostrará los archivos
que han sido modificados o creados pero que
aún no se han escenificado para una Comi Para almacenar archivos en etapas, usa
el comando Git add. Estas son varias formas
de usar este comando. La primera etapa de archivos
específicos. Aquí enumero todos
los archivos que quiero agregar. La segunda etapa de todos los archivos
con una extensión específica. Y aquí utilizo el
punto Asterix y la extensión. Quiero agregar todos los archivos
con esta extensión. Y la tercera etapa
todo cambia a la vez, y aquí uso punto. En este ejemplo,
escenifiquemos todos los archivos Tixti. Ahora el estado de Git mostrará los archivos como preparados
y listos para Commit Hagamos nuestro primer compromiso. Para guardar los cambios, necesitamos crear un commit. Usa el comando Git Commit con la opción menos M para incluir un mensaje
que describa los cambios. En mi caso, será
commit inicial con archivo de texto. GID creará un nuevo commit
con un hash cod único que contiene una instantánea de los archivos por etapas o
cambios si lo fueran Después de esto, ejecute en estado GID y muestre que el
directorio de trabajo está limpio, es
decir, todos los cambios se
han guardado. Voy a explicar esquemáticamente
lo que acabamos de hacer. En Git, hay
tres áreas principales donde los archivos se almacenan y
administran el directorio de trabajo, el área de preparación, el índice
y el repositorio. El directorio de trabajo,
este es el directorio en su máquina local donde realiza cambios en los archivos de
su proyecto. Cualquier modificación realizada
aquí no es
rastreada automáticamente por Git. El área de estadificación o índice. Aquí es donde
agregas los cambios de tu directorio de trabajo que planeas incluir en
tu siguiente commit. Piense en ello como un área de búfer o preparación
donde puede revisar y afinar los cambios antes comprometerlos y
el repositorio. Aquí es donde Git almacena el historial completo de todos los
cambios realizados en tu proyecto, incluidas todas las
versiones comprometidas de tus archivos. Actúa como una base de datos que contiene instantáneas de su proyecto
en varios momentos en el tiempo Entonces, en resumen, el directorio de
trabajo es donde se realizan los cambios. El área de preparación es donde se preparan esos cambios
para un comite, y el repositorio es donde GID guarda el historial
de todos los cambios Comprender estas
tres áreas es crucial para administrar su
proyecto de manera efectiva con GID. En la siguiente lección,
pasaremos
a algunos casos prácticos de
uso. Mar.
4. Cambiar nombre y eliminar archivos en Git: usar comandos Git y comandos de Shell: Bienvenidos de nuevo, chicos.
En la última lección, terminamos creando y comprometiendo proyecto
inicializado Vamos a crear otro cambio y escribir algo
en el archivo TXT. El comando echo text agrega
el texto al archivo TiKt. Ejecutar el estado de Git
revelará nuestros cambios. Aquí podemos ver mensaje que no se
agrega ningún cambio para cometer. Entonces agreguemos estos cambios. En lugar de usar dos comandos
separados, Git add, y luego GIT Commit, podemos realizar ambas acciones
en un solo comando. indicador Menos A
estabiliza todos los archivos modificados, excluyendo los archivos U, y el indicador menos M agrega
un mensaje de confirmación. Vamos a que aquí
resolvimos errores. Después de ejecutar este comando, Git procesará y guardará
todos los cambios en un solo paso. Ahora, el estado de Git
confirma que no
hay nada que confirmar porque
todos los cambios se guardan. Hemos hecho nuestro segundo compromiso
con un solo comando. Podemos ver las dos commits
con el comando Git log. Entonces consideremos
eliminar archivos y Git. El comando LS muestra lo
que tenemos en esta carpeta. El comando RM es
un comando estándar utilizado para eliminar archivos y directorios
del sistema de archivos. Cuando usas RAM
para eliminar un archivo, se elimina permanentemente
de tu sistema, pero Git no está al tanto
de esta eliminación. Por ejemplo, eliminemos el texto del
archivo con Command RM. Después de ejecutar esto, los datos de GIT mostrarán que el
archivo ha sido eliminado, pero los cambios aún deben
ser escenificados y comprometidos Entonces escenifica la eliminación. Los archivos por etapas y Git
están marcados en verde. Entonces, cuando veas archivos
verdes y git, están listos para ser comprometidos y luego cometer los cambios. Ahora vamos a eliminar un segundo archivo. Pero esta vez, usaremos el comando Git RM específico de Git. A diferencia de RM, GITRM
elimina el archivo
tanto del directorio
de trabajo como del repositorio en un solo paso al tiempo que
rastrea la eliminación
en el historial de confirmación Notarás que omitimos
el paso de agregar Git, pero los cambios están
resaltados en verde Eso significa que son buenos
para ir a la siguiente confirmación. Por eso yo uso aquí
solo menos bandera M. Bueno, en resumen, usa
RM para eliminar archivos solo del sistema de archivos y
luego actualizar manualmente Git. Usa GID RM para eliminar archivos y registrar la eliminación en
Git en un solo paso. Entonces, por ahora, nuestra carpeta está vacía. Acabamos de borrar dos
archivos que teníamos. Con el comando touch, creo nuevo archivo app punto py. Después agrégalo al escenario. Comprometer. Cuando haces una confirmación, es posible que veas el mensaje, tu nombre y correo electrónico se
configuraron automáticamente. En la lección anterior,
discutimos configurar Git con tu nombre y correo electrónico usando ajustes
globales o locales. Dado que configuramos los ajustes globales
y locales en la lección anterior y luego
desconfiguramos el correo electrónico y el nombre, Git ahora está usando los valores de
correo electrónico y nombre generados
automáticamente Para evitar este mensaje y asegurar un seguimiento adecuado
de las contribuciones, puedo configurar el nombre de usuario y el
correo electrónico con estos comandos. Pero ahora mismo para este ejemplo, no lo necesito, así que lo
dejo como está. Revisa la carpeta y
podemos ver nuestro archivo. El comando MV es un comando de propósito general para nombre o mover archivos
en el sistema de archivos Si bien funciona para la administración de
archivos, sí notifica a Git
sobre los cambios. Si realizo este comando, Git tratará esto como una
eliminación de la aplicación Pi y adición de la misma
requiriendo la puesta en
escena manual y la confirmación. Entonces edito y me comprometo. Creo otro
archivo app dot pie, lo
agrego al escenario
y lo cometo. Quiero mostrarte la
segunda forma de cambiarle el nombre. Así que por ahora, tenemos
dos archivos renombrados II Dotpy y casi
creados ab dot Cambiemos el nombre de app
dot pi a coordtpy. Alternativamente, puede usar el comando GD&V específico de
GID, que simplifica este proceso Cambia automáticamente el nombre del archivo
en el directorio de trabajo y actualiza los registros de Git preparando los cambios para
la
puesta en escena en un solo paso Realizo Comando LS, y podemos ver nuestro archivo
renombrado coedtpy y el primero Entonces tenemos ventajas
del comando GID y V. Mantiene intacto el historial
del archivo renombrado
en el repositorio de Git Además, simplifica
el proceso
combinando los pasos de cambio de nombre
y puesta en escena Después de ejecutar Git y V, el archivo está listo
para una confirmación y estado de
Git mostrará la operación de cambio de nombre por
etapas Al comprender estos comandos, puede manejar
las adiciones, eliminaciones y renombraciones de archivos de
manera más eficiente mientras mantiene el control de versiones
adecuado Ver en la siguiente lección.
5. Dominio de .gitignore: configuración, tipos de parámetros y gestión de la información del usuario en Git Config: Bienvenidos de nuevo, chicos.
Discutamos expedientes que no deberían
ser comprometidos. Cuando trabajas en un proyecto, a menudo
encontrarás archivos y directorios que no necesitan ser incluidos en tus commits. El archivo GID Ignorar
ayuda a gestionar esto. El archivo Ignorar GID es un archivo de configuración utilizado
por Git para definir y rastrear archivos y directorios que deben ignorarse y excluirse
del control de versiones. En una lección anterior,
configuramos un archivo
Gig Nur global para archivos de
sistema que
no queremos incluir
en ninguno de nuestros proyectos Y en esta lección vamos a crear un GiignerFle específicamente
para Primero, creo un archivo oculto llamado punto GiteGNR en el
directorio raíz de nuestro proyecto El GIIgOlfle se puede colocar ya sea en el repositorio a través directorio o en
subdirectorios específicos, y afectará a todos los archivos y directorios dentro de
su Puedes encontrar un montón de ejemplos de
Giegnor en Github. Estos ejemplos varían según el proyecto y el
lenguaje de programación, ya que cada uno tiene archivos
o directorios específicos que no
deben incluirse en el repositorio compartido del
proyecto. Por ejemplo, muchos lenguajes de
programación generan archivos temporales, registros o artefactos de compilación que son innecesarios
para el control de versiones. GitHub incluso proporciona plantillas
Gitegnor específicas del
idioma para
varios frameworks Entonces consideremos la
sintaxis común y GitegNorfils. Al usar efectivamente GiegnoFle, puede personalizar qué archivos
y directorios
debe y directorios Se pueden ver algunos ejemplos
de patrones comunes. Este patrón significa que se todo
el contenido
del directorio TMP, ignorará todo
el contenido
del directorio TMP,
incluidos todos los subdirectorios
y archivos O podemos ignorar
archivos por extensión. Este patrón ignorará todos los archivos con la extensión de
registro. Mediante el uso de un signo de exclamación, puede especificar
una excepción para la En este caso, todos los archivos de
registro serán ignorados excepto el registro de depuración. El asterisco actúa como comodín que coincide con cero
o más Por ejemplo, asterisco
punto TiKT ignorará
todos los tixTfles El asterisco Wilder coincidirá con todos los archivos
dentro de un coincidirá con todos los archivos
dentro de un directorio, pero no con sus subdirectorios. Suficiente teoría, practiquemos. Para demostrarlo, limpio
el directorio del proyecto
y luego agrego el directorio del proyecto
y luego agrego un directorio temporal llamado
TMP y TikTFLE Y además, escribo hola al TikTFLE dentro de
la carpeta Temp Inicialmente, el directorio TEM y su contenido aparecen en
la salida de estado GIT. Si decidimos que este directorio no
debe incluirse
en ningún comits, podemos escribir la siguiente
regla en el archivo Git Ignorar El comando ECO crea o sobrescribe GitegNorfle En nuestro caso, escribo
TAM dos Git Ignore, y esto significa que GID ya no
rastreará ni incluirá el
directorio TAM en commits, incluso si se
realizan cambios dentro de él El comando CAT dot Git Ignorar muestra el contenido
del archivo Git Ignorar
en el terminal. Después de guardar este patrón
y volver a ejecutar el estado Git, el directorio TAM ya
no es visible. Esto asegura que
no
cometeremos accidentalmente archivos innecesarios
del directorio TAM. Ahora agregaremos y
comprometeremos nuestros cambios. Sin embargo, cuando lo hago, nos encontramos con
un mensaje preocupante porque el correo electrónico y el nombre de usuario para este proyecto no han
sido configurados. Como dije antes,
GID
genera automáticamente los valores predeterminados de correo electrónico
y nombre de usuario, pero es mejor
configurarlos manualmente. Por ahora, vamos a configurarlos
localmente para este proyecto. Primero, asigno un nombre de usuario. A continuación, configuré un correo electrónico. Para demostrarlo, creo
un nuevo archivo de prueba dt, y comprometo los cambios. Ejecutar el comando de registro de Git confirma que el nuevo nombre de usuario y correo electrónico aparecen en el
historial de viajes, y
los mensajes de advertencia anteriores se han ido Nos vemos en la siguiente lección.
6. Fundamentos de GitHub: clonación de repositorios, cambios mediante push & pull y configuración de conexiones SSH: Bienvenidos, B, chicos. Git no es
solo un sistema de control de versiones. Es un sistema de control de
versiones distribuido, lo que significa que no necesitas
un servidor central para funcionar. Cada desarrollador tiene
su propia copia local de Git que almacena
todo el historial de desarrollo del proyecto. Cuando los desarrolladores hacen cambios, primero los graban
localmente en sus computadoras. Entonces, si así
lo desean, pueden compartir
sus cambios con compañeros o recibir
actualizaciones de otros. Sin embargo, en proyectos del mundo real, generalmente se
crea
un servidor central para mayor comodidad. Este servidor actúa como un centro
de colaboración donde todos los desarrolladores pueden enviar sus cambios y obtener
actualizaciones de otros. Cualquier computadora remota con acceso
adecuado puede
servir como servidor Git. Plataformas como GitHub, Gitlab y Bitbucket son populares soluciones basadas en
web para alojar repositorios Git Estas plataformas proporcionan
infraestructura para almacenar código, administrar el acceso
y facilitar la colaboración en
proyectos usando Git. Además, cada plataforma tiene
sus características únicas, atrayendo desarrolladores y equipos de diversas habilidades y necesidades. Hoy, nos centraremos en Github y aprenderemos a crear repositorios de eliminación
y clonación, así
como configurarlos como un sabio
para una comunicación segura Así que empieza por ir
al sitio web de GitHub y
registrarte para obtener una cuenta. Ingrese su dirección de correo electrónico, que será utilizada para el registro de la
cuenta. Haz clic en el botón Continuar
y confirma tu correo electrónico. Como ya tengo una cuenta, simplemente
iniciaré sesión y procederé
a crear un nuevo repositorio. Para crear un nuevo repositorio,
siga estos pasos. Especifique el
nombre del repositorio. Debe ser único. Establece visibilidad, elige entre
público o privado, público, es visible para todos, haciendo posible que otros
clonen tu repositorio. Los repositorios públicos son ideales para exhibir carteras o
compartir proyectos de código abierto Privado restringido a usted
y a sus colaboradores, apto para trabajo comercial
o privado. También tenemos el archivo léeme, que normalmente
contiene instrucciones sobre el proyecto
y su propósito. Generar archivo punto GTI Nor, lo que ayuda a excluir
los archivos necesarios de ser rastreados Sí, Github puede generar automáticamente un Gitegnorfle adaptado al lenguaje de programación que
esté Ahora, hemos creado
con éxito un repositorio Github con
algunos archivos iniciales. Nuestra siguiente tarea es
clonarlo a nuestra computadora local. Para clonar repositorio a través de
tu computadora local, primero, abre tu
repositorio en Github. Haga clic en el botón de código y seleccione un enlace para
clonar el proyecto. Tendrás tres opciones HTTPS, SSH o Github CLI Nos centraremos en clonar usando
SSH porque es seguro y elimina la necesidad ingresar repetidamente
tus credenciales Para clonar a través de SSH, es
necesario generar una
clave SSH y agregarla a En su computadora local, genere una clave SSH
usando el terminal Genero claves SSH usando
el comando SSH Kagan. Se utiliza para todos los sistemas
Macs que quieras para Windows. El proceso es el mismo en todas las plataformas con opciones
para diferentes tipos de claves. Durante el proceso,
se le preguntará dónde guardar la llave. Puede especificar una ubicación personalizada o aceptar
el directorio predeterminado. Como ya tengo una clave generada, me saltaré este paso. Después de generar la clave, navegue hasta el directorio
donde se guardó. Encontrarás dos archivos, la clave privada, mantenla
segura y la pública. Esto es lo que
agregaremos a Github. Copiar el contenido
del archivo de clave pública. Vaya al Github,
a la configuración SSH y haga clic en Nueva clave SSH Asigne un nombre descriptivo, pase la clave pública y confirme ingresando
su contraseña de Github. Ahora se configura el eje SSH. Clonemos el repositorio. Copia el enlace SSH de
tu repositorio Github, abre la terminal y navega
hasta el directorio
donde quieres
clonar el proyecto y ejecuta
el siguiente comando Una vez completado,
verás los archivos del proyecto en tu computadora local exactamente como están en el repositorio de
Github. Eso es. Has creado correctamente un repositorio en Github. Nos vemos en la siguiente lección.
7. Cómo hacer cambios locales a GitHub, eliminar repositorios y configurar la conexión CLI: Bienvenidos de nuevo, chicos.
Repasemos rápidamente cómo eliminar un
repositorio Github del servidor remoto Para eliminar un proyecto en Github, vaya a la configuración
del repositorio. Desplázate hacia abajo para encontrar la
opción de eliminar repositorio, y finalmente confirma que
realmente quieres eliminarlo. Eliminar el repositorio en Github no afecta
tu copia local. Desde que clonas el repositorio, puedes seguir trabajando
con él localmente. Ahora, vamos a
crear rápidamente un nuevo proyecto, nombra proyecto de prueba. Y usa la CLI de Github
en lugar del enlace SSH. Primero, necesitarás
instalar la CLI de Github. Consulte la documentación de la CLI de
Github para obtener instrucciones de instalación Github CLI es una herramienta de línea común que interactúa con
Github desde el terminal, mientras que las interfaces gráficas se utilizan a menudo para Saber usar la
CLI de Github es igualmente importante. Por ejemplo, los servidores normalmente no tienen interfaces gráficas, y es posible que deba trabajar a
través de la consola. Aquí pueden ver, ya que repito todos los pasos necesarios
de la documentación. Al configurar la CLI de Github, se
le harán algunas preguntas durante el proceso de
configuración Una de las preguntas es si
quieres conectarte a un servidor Enterprise Github
o usar el Github predeterminado. Dado que la mayoría de los usuarios
trabajan con Github, puedes elegir no usar
Enterprise Git a menos que
estés trabajando en organización que aloje su propia instancia de
GitHub Enterprise. A continuación, se le pedirá que seleccione el método
de autenticación. Debe elegir SSH
para la conexión. SSH es una forma segura
y conveniente comunicarse con el servidor
Github, lo que le permite empujar, extraer e interactuar con
sus repositorios
sin ingresar su credencial Después de seleccionar SSH,
la CLI le pedirá que utilice una clave SSH
publicada existente o que genere una nueva. Y darle un nombre para
identificar el dispositivo. Una vez que hayas nombrado la clave, la CLI de
Github
cargará automáticamente tu clave SSH pública
a tu cuenta de GitHub Es posible que se te pida que te autentiques usando tus credenciales de Github, como volver a ingresar un
código de verificación único para confirmar la acción Después de este paso, tu configuración de la
CLI de Github está completa y puedes asegurar
clonar, empujar, extraer e interactuar con
repositorios de Github usando Cuando clonas un proyecto
usando este comando, la conexión a GIT Hub se establece
automáticamente. El comando usa
el protocolo Git para recuperar todo el
repositorio a tu computadora Entonces, una vez que el comando se ejecute
con éxito, tendrá un clon
completo
del repositorio y podrá
comenzar a trabajar localmente. Aquí navegé hasta el
directorio del proyecto clon. Para verificar la conexión
al repositorio remoto, usa el siguiente comando
Git remote menos V. Este comando te mostrará la conexión al repositorio
remoto. De forma predeterminada, se llama origin, pero se puede asignar un
nombre personalizado al clonar un proyecto. Ahora aprendamos cómo enviar cambios al repositorio
remoto de Git. Vamos a hacer algunos cambios locales y empujarlos al repositorio
remoto de Git. Modificaré el
archivo léeme y agregaré algunos cambios. Agregue estos cambios al área de
espera y compromételos. Así que aquí puedo ver nuestro commit para empujar estos cambios al repositorio
remoto, ejecutar git push origin main. Aquí, orgion es el nombre de la
conexión, y principal es la rama a la
que empujamos nuestros cambios Después de
impulsar con éxito los cambios, puedes visitar GitHub
para ver las actualizaciones. Podrás ver los detalles de
la confirmación y
ver los cambios exactos. Con líneas añadidas marcadas en verde y líneas eliminadas en rojo. Hagamos los
cambios de extracción inversa del repositorio
remoto a su proyecto local. Modifico el archivo ReadMe en GitHub, que creará un nuevo coamit Ahora en tu proyecto local, verás dos kamits
mientras estás en GitHub, verás tres amits Para obtener los cambios
de Github,
ejecuta el comando Esto publica las
últimas actualizaciones de la sucursal principal remota en
tu repositorio local. Después de la extracción, el archivo
Léeme en su computadora local
reflejará los cambios
realizados de forma remota. Consideremos otro escenario. Tienes un proyecto
localmente en tu computadora, y ahora quieres subirlo
a Github para
compartirlo con otros. Comienza creando una carpeta
e inicializándola con Git, como hicimos en lecciones anteriores Yo creo Test TikTFLE
y escribo hola en él. Y luego, por supuesto, sumar a
esta etapa y comprometerla. Después de hacer algunos cambios
y comprometerlos localmente, estás listo para subir
el proyecto a Github. Para subirlo a Github, crea un nuevo
repositorio en Github. Esta vez, no agregues Read
M file o Git Ignore. Github te proporcionará instrucciones
específicas para subir tu proyecto. Acude a tu terminal y ejecuta estos
comandos uno por uno. El primer comando establece una conexión con el repositorio
remoto. El segundo comando asegura que tu repositorio local
use la rama principal. Si tu proyecto usa master, este paso lo renombra a main El tercer comando empuja
los cambios al Github. La opción menos U vincula tu sucursal principal local con
la rama principal remota, lo que
facilita
la inserción de cambios en el futuro sin
especificar parámetros adicionales. Después de empujar, actualiza
tu página de GitHub para ver el proyecto, tus archivos y confirmaciones ahora
deberían aparecer
en el repositorio. Así que hemos cubierto cómo
eliminar el repositorio,
crear uno nuevo, clonarlo usando GitHub CLI,
push changes, pull updates, y aplaudir el
proyecto local a Has hecho un gran trabajo.
Nos vemos en la siguiente lección.
8. 7 crea ramas: Bienvenidos de nuevo, chicos.
Hoy, profundizaremos en trabajar con
sucursales y commits. Empezamos desde el principio. Proyecto Totalmente Nuevo. Yo creo directorio vacío. Ejecutar el estado de Git aún no mostrará nada porque no hemos
inicializado el proyecto Primero, haré un simple cambio escribiendo hola al
TikTifle Read Me Este archivo se creará
automáticamente con el comando. Solo recuerda hacer eco de este comando, escribe hola a la tixTifle
Léame A continuación, el comando Git init
inicializa el proyecto, creando una carpeta git oculta Ahora Git comenzará a
rastrear nuestros cambios. Para confirmarlo, ejecute s menos A para mostrar tanto los archivos ocultos como
los regulares. Verás la carpeta Git
y el archivo readmitixty. Ejecutar el estado de Git ahora muestra nuestros cambios que deben
agregarse y comprometerse. Vamos a encargarnos de esto. En el código de
Visual Studio, hay una extensión
llamada GID graph, que proporciona una interfaz
gráfica conveniente para ver el historial de confirmaciones. Para instalarlo, abra
el panel de extensiones, en código VS, busque gráfico
GID e instálelo. Mapea visualmente sucursales, cambios, fusiones y más Una vez instalado, notará un icono de gráfico GID en
el panel inferior. Al hacer clic se muestra
el estado actual del proyecto. Aquí vemos que estamos en la rama principal,
la rama predeterminada. El commit inicial
etiquetado en él proyecto, haciendo clic en el Commit nos permite ver todos los archivos
cambiados en ese Commit. Por ejemplo, al
hacer clic en Rhythm txt muestra exactamente lo que se agregó. Ahora voy a crear ramas
usando múltiples métodos. En primer método, ejecute el
comando Git branch, feature one, para crear una nueva
rama llamada feature one. Después usando el comando GeTheKoFeature uno,
cambiamos Consulta la gráfica para ver que ahora estamos en
la rama fit one. En esta rama, escribo el proyecto de
línea en el TikTifle. Aquí está. Después agregue estos
cambios y cometerlos. Hagamos otra.
Escribo la tercera línea en TikTifle y esta
línea se comprometerá A después de hacer otra confirmación, veremos ambas confirmaciones en la función una rama
en el gráfico de Git. Ahora voy a crear
otra rama, pero para esto, voy
a usar otro comando. Con el comando
Git checkout main, cambio a la rama principal. Entonces ahora mismo estamos
en la rama principal. Solo para recordar, aquí
no tenemos estos dos commits
anteriores. Yo uso el comando
Got menos B y luego nombre de mi segunda
rama cuentan con dos. Esto crea y cambia a
una nueva rama simultáneamente. En la función a rama, crearé una nueva aplicación de archivos
Python dot py y agregaré una sencilla función de impresión
Hello World. Puedes crear cualquier archivo y escribir algo en
él. Depende de ti. Git status muestra el archivo
que necesitamos d y commit. Después de poner en escena y
comprometer esto, veremos el primer Gamit para la característica dos
en la gráfica GID Entonces, por ahora, tenemos
tres ramas característica
principal una
y cuentan con dos. Main tiene solo un proyecto
commit innit. Como nos ramificamos de main, la nueva característica de rama uno comienza desde la misma confirmación
inicial del proyecto
principal init e incluye dos confirmaciones adicionales que
acabamos de hacer en la característica uno Comete uno y Comete dos. Lo mismo con la característica de
rama dos. Esta rama tiene el proyecto
inicial commit int y el commit
que acabamos de hacer. Comprometer uno, característica dos.
9. Fusiona 8 ramas en diff: Averiguemos cómo
fusionar ramas. fusión de ramas Git
es el proceso de combinar cambios de
una rama a otra, normalmente fusionando una rama de entidad en
rama principal Esto integra las
actualizaciones y garantiza que todos los cambios se
consoliden en una sola rama. Al presionar la flecha hacia arriba, puedes repetir los comandos
anteriores que ejecutaste en la consola. Volveré
al comando donde
escribí hola mundo
al archivo app punto pi. Voy a cambiar texto
para cometer dos. Y vuelva a ejecutar el comando, escribiendo una
línea diferente en el archivo. Si abro el archivo app punto py, podemos ver la segunda
línea, simplemente dit. Además, si presiono
cambios no comprometidos en Gig graph, podemos ver este archivo,
y nuevamente, nuestra segunda línea
con plus que acabamos Después agrego estos cambios
y los comprometo. Estoy haciendo esto para que podamos ver más commits en cada rama. Esto lo hará más claro
cuando fusionemos estas ramas, ya que podremos ver todos los
commits que se hicieron. Entonces ahora mismo, hice
los cambios en la característica de rama dos. Después me cambié a la rama principal. De inmediato, notamos que falta
nuestro AbdtPifle. Esto se debe a que el ABDTPifle fue creado en la rama
característica dos, y ahora estamos en Aún no hemos fusionado
los cambios. Si abrimos nuestro ritmo txt, también
veremos solo
el saludo inicial. Escribimos desde el principio. Para ver todas las sucursales, el comando Git branch nos muestra todas las sucursales que
actualmente tenemos localmente. Esto incluye nuestra
rama principal indicada por el asterisco y las dos
ramas que creamos Si estás trabajando
y no puedes recordar qué ramas
ya se han fusionado, hay un comando útil
rama Git, dash dash, fusionado. Esto muestra las sucursales que ya se
han
fusionado con la rama actual. En nuestro caso, todavía no se
ha fusionado nada, así que solo vemos nuestra sucursal principal. También hay comando para
mostrar ramas no fusionadas, rama
Git, dash
dash, no fusionadas Las listas de las ramas
que tienen cambios que aún no se han fusionado
en nuestra rama principal. Ahora, estando en la rama donde
planeamos fusionar los cambios, ejecutamos el comando git
merge y especificamos la rama desde la que
fusionaremos los cambios. Empecemos con la
primera característica de rama uno. Después de fusionarse, vemos dos líneas adicionales en
nuestro archivo léeme Tixty A continuación, pasamos a la rama característica
dos y comenzamos a fusionar todos los cambios de la segunda rama
a la rama principal Nuevamente, al estar en la rama principal, ejecutamos el
comando kit merge y especificamos, por
supuesto, la rama
característica dos. Aquí puedes ver el mensaje. No te preocupes, se
crea un nuevo commit durante la fusión. Puedes cambiar el mensaje de commit o
dejarlo como está. Desde que estamos aprendiendo a
trabajar para conseguir el terminal, ha abierto
un editor de texto. El tuyo podría ser nana o VIM dependiendo de
lo que esté instalado En mi caso, es editor de VIM, por lo que este comando significa
escribir y salir En este punto,
hemos logrado fusionar ambas sucursales
en nuestra sucursal principal. Ahora, todos los cambios que hicimos
están en la rama principal. En la gráfica de Git, podemos elegir qué
rama específica queremos para ti. Si hay muchas sucursales, podría ser difícil rastrear todas
las commits para cada una. Entonces aquí podemos elegir uno u otro y ver claramente todos los
commits en esta rama. El comando Git log muestra todos los commits que
tenemos actualmente en nuestra sucursal. Si quieres ver el
historial de Commit en formato gráfico, puedes usar Git log graph. Esto mostrará
algo similar a lo que vimos en la
interfaz gráfica donde
podemos ver claramente nuestras commits
y las commits merge de la
característica uno y la característica dos. El comando Git log D graph es otra forma de visualizar
todo lo que hemos hecho. Supongamos que está trabajando en un servidor sin interfaz
gráfica. En ese caso, puedes ver la misma información
directamente desde el terminal ejecutando
el comando Git log. Poder trabajar con la
terminal es muy útil. Imaginemos que la
característica uno y característica dos son dos características. Estamos desarrollando para nuestra app. Si queremos ver en
qué se diferencia el estado de la
característica uno
de la característica dos, podemos cambiar a la rama
feature one y usar el comando Git DIV para
comparar las diferencias. Especificamos la rama con la
que queremos comparar, en este caso, cuentan con dos. Entonces aquí estamos comparando y buscando diferencias
entre dos ramas, característica uno y característica dos. Veremos que faltan los ABDTPifles
en la característica uno, y también tenemos dos
líneas adicionales en el En este ejemplo, el comando
Gi Div
nos muestra las diferencias
entre las dos ramas, destacando lo que está
presente en la característica dos, pero que falta en la característica uno. Si queremos comparar el commit actual en nuestra
rama con un commit específico, podemos volver a usar el comando Git
Div. Pero esta vez, necesitamos
especificar el commit con el
que queremos compararlo. Para ello, primero necesitamos
encontrar el hash del Camt con el que
queremos comparar Podemos ver los
hashes de Commit ejecutando Git log o simplemente
viendo Git graph Cada commit tiene único, pero no tenemos que
escribir el hash completo. Nos permite utilizar los
primeros caracteres. Normalmente primero siete,
que suele ser suficiente para identificar a Cami una vez que
tenemos el hash, podemos ejecutar este comando Y esto nos mostrará
las diferencias entre nuestro estado de trabajo actual
y el commit especificado. Por ejemplo, aquí
en la terminal, podemos ver que en
el estado actual, tenemos adicional
de línea, Commit dos. Podemos ir al Giggraph
y ver lo mismo. Presiono la función uno, Commit dos. Este es el Commit actual que
tenemos ahora mismo. Y aquí podemos ver esta línea. En la siguiente lección,
seguiremos trabajando con
ramas y commits. S.
10. Resolver conflictos de fusión en Git: una guía completa: Bienvenidos de nuevo, chicos. Sigamos
trabajando con sucursales. Actualmente estoy en la
rama característica uno, que creé a partir de
la rama principal. Aquí voy a hacer algunos cambios. Usando este comando, agregaré
una línea a Read MitixTifle. Imaginemos que hemos estado haciendo múltiples commits,
y por alguna razón, ahora
necesitamos verificar los cambios no comprometidos en
tu directorio de trabajo en comparación con el último Gamit En la
lección anterior, aprendimos cómo el comando GI Div funciona
el comando GI Div con ramas
para mostrar diferencias. También analizamos los
commits específicos usando sus hashes. Hoy, te voy a mostrar cómo funciona
Git Div con
los cambios en tiempo real. Quiero ver qué he modificado y qué aún no
se ha agregado al
área de espera. Para ello, usaré
el comando GI Div. Este comando muestra los cambios
no comprometidos en el directorio de trabajo en
comparación con el último commit
en esta rama Estos cambios no se han
agregado al área de espera. Si abro el
archivo de texto, léeme Tixty, veremos la línea que
acabo de agregar con el
comando en la terminal Después de ver la línea agregada, ejecutaré el comando, obtendré diff, dash, dash, escenificado Pero esta vez, no veremos ningún resultado porque
este comando muestra las diferencias entre
los cambios que
ya se han escenificado y la
última versión comprometida Entonces, para ver la diferencia entre área del
escenario y la última versión
comprometida, necesito agregar todos nuestros
cambios al área del escenario. Voy a agregar estos cambios
al área de puesta en escena, pero sin comprometerme todavía. Bueno, imaginemos que tomamos un descanso para el café y
al regresar, nos olvidamos de lo que habíamos
agregado y escenificado Para comprobar lo que está escenificado, pero aún no comprometido, podemos usar Div da da escenificado Este comando muestra la
diferencia entre el último commit y los
cambios que se escenifican, pero aún no se han comprometido. Ahora podemos revisar estos cambios
antes de realizar el commit. Una vez que cometemos los cambios, ejecutar Div escenificado de nuevo no mostrará nada
ya que
no hay más diferencias entre los cambios de etapa
y el último Gamit Del mismo modo, ejecutar Git div
tampoco devolverá ninguna salida. Y no
quedan cambios
no comprometidos en el directorio de trabajo A continuación, cambiemos a la rama principal y fusionemos los
cambios de la característica uno. Recuerda, al fusionar ramas, necesitas estar en la sucursal que quieres fusionar
los cambios Como queremos fusionar la
característica uno en la media ejecutamos Git
merge, feature one. Esto crea un
commit de fusión donde podemos modificar el mensaje de commit
o dejarlo como está. Anteriormente, también creamos otra rama
llamada característica dos. Ahora, voy a cambiar a esa sucursal. En la característica dos, tenemos tres
commits el commit inicial, que fue heredado
de la rama mía cuando creamos la rama
featured two. Y dos compromisos adicionales que se hicieron específicamente
para esta rama. Adicionalmente, tenemos
una nueva app de archivos en Pi, y en Red Mitixt
solo vemos el texto hola Por lo que el estado de la rama característica
dos es completamente diferente de la característica
uno o ramas principales. Ahora agregaré otra línea al
archivo Redmtixt y Después de esto, volveré a
cambiar a la rama
principal e intentaré
fusionar estos cambios. Al estar en rama principal, ejecuto el comando
git merge feature two. Y vemos que nos encontramos con nuestra primera resolución de
conflictos Git. Específicamente, agregamos una línea
en la entidad a ramificar, pero ya hay
algo escrito en la rama principal ya que ambas
líneas existen en un mismo lugar, entran en conflicto entre sí. Entonces, para completar nuestra fusión, necesitamos resolver
estos conflictos. Vamos a los expedientes,
que entran en conflicto,
los identificamos y los arreglamos. Elegimos lo que queremos conservar. Cuando abro el archivo, podemos ver una
presentación visual con marcadores que identifican
el estado actual. A continuación, podemos ver los cambios de la característica a la rama que
estamos a punto de fusionar. Resulta que dos líneas de dos ramas diferentes
existen en la misma ubicación, pero contienen contenido diferente. En casi cualquier editor, puede optar por aceptar
todos los cambios entrantes. Conserva lo que tienes actualmente
en la sucursal y rechaza los cambios entrantes o mantén todo fusionando
ambas versiones En este caso, podrás resolver
automáticamente
estos conflictos, dejando toda la información
de ambas ramas. También puedes comparar
estos cambios y ver exactamente qué es lo
que hay que resolver. A la derecha,
tenemos nuestra característica a rama de la que
estamos fusionando cambios, y en la izquierda, tenemos
nuestra rama actual Al hacer clic
en Resolver en el Editor de marzo, se abre en gráfico GIN. Esto le permite resolver
manualmente el conflicto durante la fusión de
sucursales En el editor de marzo, puedes revisar las
diferencias entre versiones
conflictivas del archivo y elegir qué
cambios conservar Después de resolver conflictos
y guardar los cambios, se completa el proceso de
fusión de sucursales Ya que no todos
trabajan con GID graph, voy a resolver los conflictos
directamente en el propio archivo. Planeo mantener la línea de la rama característica dos y también mantener todo
de la rama principal. Entonces vamos a los archivos
con conflictos, los identificamos y los arreglamos. Elegimos qué conservar. Y si se necesitan ambos
cambios contradictorios, dejamos todo menos
hacer ligeras modificaciones Ahora ejecutando el estado de Git nos
mostrará los nuevos cambios. Hicimos estos cambios manualmente
en el archivo Rhythmtixti, manteniendo todo
desde la rama principal
y agregando cambios de la rama y agregando cambios Agregamos los cambios
y hacemos un Camite. En Giddigraph, es muy conveniente ver
la diferencia Ahora, en la rama característica dos, miramos el
archivo Rhymitixty y podemos ver nuestro mensaje de saludo
junto con nuestro En tanto, si cambiamos a la rama principal y comprobamos
el Rhythm TixTifle, mostrará todo lo
que
acabamos de hacer, los cambios anteriores y
la última línea que agregamos de la característica
a la En la siguiente lección,
te
presentaré con un
comando muy útil. Nos vemos.
11. 10 reset de reflog hard soft: Bienvenidos de nuevo, chicos. Ahora quiero presentarles un comando
muy útil, pero necesito hacer algo de
preparación primero. Así que volvamos a nuestra
rama de características y cambiemos a ella. Aquí en el archivo ab dot B, imaginemos que quiero eliminar
una función, y lo hago. Después de eliminar la
segunda declaración de impresión, agregaré estos cambios
y los comprometeré. Entonces volveré a cambiar a la rama principal y
fusionaré estos cambios. El comando Git log mostrará nuestro último commit donde fusionamos la característica dos
en la rama principal. Y ahora tiempo para
otro comando, quiero presentarles. Cada vez que realizas
operaciones como mover, crear o eliminar
confirmaciones o ramas, Git almacena las secciones
en el registro de Rf. Y esto permite restaurar
el repositorio a puntos
anteriores y también recuperar
confirmaciones eliminadas que fueron
sobrescritas y realizar fusiones
incorrectas Bueno, es realmente un comando
muy útil. El flog realiza un seguimiento de la última posición de
referencia I durante un cierto periodo, pero quiero notar
que el vlog se almacena localmente y no se comparte
con repositorios remotos Ahora, imagina que lamento
fusionar esta rama, y urgentemente necesito deshacerla idealmente sin dejar
rastro en el historial de cometer Actualmente, estoy en el
commit fusionado de la característica dos, pero necesito
revertir una commit. Para verificar qué cambió, ejecutaré get DF
y luego cometeré hash. Esto muestra la
diferencia entre el estado actual y
el commit especificado. Como puede ver, el
commit actual difiere de la que
especificé específicamente porque falta la segunda
declaración de impresión. Esto significa que el commit anterior contiene el estado que
necesitamos porque quiero restaurar esta línea y nadie debería ver
que fue eliminada. Giro dash dahart restablece
completamente su directorio de trabajo y compromete el historial
al punto especificado Cuando ejecutas, GitRst
dash dashart, get mueve tu rama a
la confirmacion especificada, elimina todo en los cambios comprometidos
y borra las confirmaciones que vinieron
después de la confirmacion Pero ten cuidado. Esta
operación es irreversible. No se puede recuperar
los cambios de señora a menos que estén
apareciendo ahí un azote Después de ejecutar el comando, nuestra segunda
declaración impresa está de vuelta. Lo hicimos borrado. Nuestro comité de fusión se ha ido. Y si ejecutamos Gift Log, podemos ver que la
rama principal ha vuelto
al commit de conflicto fijo tal como lo era antes de la fusión. Como mencioné anteriormente,
el comando Git raf log muestra todo lo que hemos hecho. Cuando ejecuto Git flock, vemos que la
abración de reinicio moviendo la rama de nuevo a
commit 44 F 18, el inicio del commit
volvemos
al
commit merge que acabamos de levantar, es
decir, esta acción
no está exenta de consecuencias, pesar de que git reset dash
dash hard borra todos los Siguen existiendo en el
relock por un tiempo limitado. Ya que hemos
aprendido a retroceder a las confirmaciones
anteriores sin guardar esta acción en el historial de
confirmaciones, usando el comando Gitvlog Aprendamos también a deshacer este rollback sin crear caos en la historia del commit Es decir,
retrocedemos a un commit previo, quitando de la historia todo lo que vino
después de él. Ahora queremos deshacer
esta reversión. Así que deberíamos
volver al vlog, copiar el hash
del commit merge, y ejecutar el
comando git reset, dash dash hard y hash Y ahora, mira esto.
Nuestro gráfico de compromiso es exactamente como era antes. Todos los nombres de Commit y sus
hashes permanecen sin cambios. En este momento usamos el comando
con la opción hard. Ahora hablemos de
otro comando. Git reset dash dash soft. A diferencia de GitrSet dash dash hard, la opción soft deshace
los últimos Camuts pero mantiene todos los cambios en su directorio
de trabajo Ahora mismo, nuestra sucursal
está en el mismo estado antes de
que nos enteráramos del comando GDR set dash
dash hard command Repitamos todas las acciones
que hicimos con la opción dura. Pero esta vez, usando
la opción soft. Así que vamos a rehacer R y D de
la característica para fusionar. Pero esta vez usamos GITR set, DDR soft, y otra vez,
tiene nuestro Esto mueve nuestra sucursal de nuevo
al Camt anterior
antes de la fusión Y ahora echa un vistazo al comando soft de
GitrSet das Dar deshizo la fusión de
característica la eliminación de la
segunda declaración impresa También
se deshizo la eliminación de la
segunda declaración impresa, pero a diferencia de Hart, los
cambios siguen ahí Actualmente, estos cambios de
etapa pueden ser comprometidos, modificados
o descartados. Este comando es útil cuando
cometiste algo
por error y quieres modificarlo o te olvidaste de
agregar un cambio y necesitas
actualizar el último commit. O si quieres arreglar
el mensaje de commit, a diferencia de hard git reset, D soft hace y elimina cambios, mantiene los cambios en
el área y te permite volver a cometer
fácilmente. Guitri dijo que soft es
más seguro porque solo mueve el puntero de rama sin afectar tus cambios, lo que te permite modificarlos y
volver a comprometerlos según Pero la opción difícil no
debe usarse con precaución
porque
descarta permanentemente los cambios
tanto en el directorio
de trabajo como en el área de preparación, dificultando
o incluso imposible recuperar esos cambios
una vez que se han ido Bueno, por ahora, eso es todo. Nos vemos en la siguiente lección.
12. 11 Enmiende el encoger de las ramas: Hola chicos, y
seguimos trabajando con Git. Vayamos al
grano enseguida. Imagina que hicimos un
terrible compromiso. Por ejemplo, así. Actualmente, estoy en la rama del
pescador, y veo el último commit con
algún mensaje sin sentido No sólo eso, si
entramos, veremos que Read
me file tiene cambios que también son por
decirlo suavemente. No genial. El comando Git commit amend se utiliza para
realizar cambios en el último commit. Específicamente, se
utiliza para agregar nuevos cambios o cambiar
el mensaje de compromiso. Lo primero que haremos es arreglar esos cambios sin sentido que
vimos en el archivo readme Escribiré algo
más o menos plausible. Luego agregaremos estos cambios al área
de preparación y ejecutaremos el comando
Git commit amend. Al ejecutar la modificación
GID Commit, se crea
un nuevo comité, que captura el estado
actual de los archivos. Si después de comprometerse, te das cuenta que olvidaste agregar
algunos cambios importantes, cometiste un error en
el mensaje de commit o decidiste cambiar
todo por completo. El
comando Modificación de Git Commit permite
realizar cambios
adicionales en el último commit sin crear uno nuevo. En otras palabras,
reescribe tu compromiso. Te permite hacer cambios
rápidamente y corregir errores
si te
equivocaste localmente y quieres cambiar el commit anterior sin
abarrotar el abarrotar Así que también arreglemos nuestro mensaje de compromiso
sin sentido. Esto es lo que vemos
después de enmendar. Mostrará el último
commit con detalles. Podemos notar que se cambió el
mensaje
y se modificó la línea en el archivo
léeme. Nuestro commit cambió completamente el mensaje y
modificó los cambios que estaban dentro
sin abarrotar el historial de commits con commits
innecesarios Lo que hicimos esencialmente, fue que Git
retrocedió un commit, e hicimos cambios y
reescribimos este Cammit Por favor, preste atención.
No lo modificamos. Ahora reescribimos vamos a
trabajar con sucursales. El comando de rama GID muestra
todas las sucursales que tenemos. ¿Cómo podemos eliminar
sucursales innecesarias localmente? Actualmente, contamos con sucursales principales y
dos de nueva creación. Si has completado
tu tarea en una sucursal y ya
no la necesitas, ya has fusionado
los cambios en la rama principal, y puedes eliminarla localmente para que
no te moleste. El comando rama GID
menos D en minúsculas, y el nombre de la rama
eliminarán esta rama localmente Si existe en
el servidor remoto, permanecerá
ahí, pero localmente, ya no
tendrás esta
sucursal. Ahora voy a cambiar a la
característica una rama, que sigue ahí, y voy a hacer más commits
para mostrarte otra cosa. Añadiré nueva línea al archivo Rhythmtixty y los
comprometeré por separado,
para que puedan ver las para que puedan ver Al trabajar con Git, puede
haber una situación tengas varias commits
consecutivas que quieras
combinar en una sola mientras preservas los
cambios de estas commits. Esto puede ser útil para
mejorar el historial de commit, reducir su cantidad
o preparar un historial limpio y comprensible
al cometer cambios en el repositorio principal. Entonces hicimos cambios, agregamos si alineas
a nuestro archivo RID M. Ahora cambiamos a la rama principal para fusionar todos estos cambios. El comando git merge squash te
permite combinar
commits en uno solo. Estos cambian el
historial de commits fusionando los cambios de múltiples commits
en uno que cometes Aquí podemos ver claramente que al
estar en la rama principal, tenemos un commit
que consta de tres commits de nuestra
característica una rama. A veces, después de haber
completado tu tarea, hiciste muchas amidas
en tu sucursal, probaste varias variantes,
experimentaste y realmente no quieres que todas estas sean visibles
en la historia general Es decir, tu objetivo es
tomar todos estos cambios en un commit y
fusionarlos en la
rama principal en el proyecto. Después de ejecutar el comando Git
merge squash, todos los cambios de la característica
una rama se combinan en una sola commit como si se
hicieran directamente
en la rama actual. La característica de una rama
en sí permanece sin cambios, lo que le permite
eliminarla o mantenerla sin
afectar el historial mental. Después de completar la tarea y fusionar los cambios con
la rama principal, puede eliminar la rama de
entidad ya que ya no es necesaria Y ahora quiero mostrarles cómo forzar la eliminación de la
rama,
aunque aún no se haya empujado o fusionado porque sabemos que
no
podemos eliminar una
rama en ella si tiene cambios no comprometidos o no
fusionados Para ello, haré un commit y no
lo fusionaré con la rama principal. Como pueden ver, hice
un cambio en el archivo, lo
agregué al
área de preparación y lo comprometí. Entonces me cambiaré a
la rama principal. Si necesitas eliminar una rama
y los cambios no se han fusionado porque de
repente se volvieron innecesarios, el comando habitual de
eliminación de rama con menos D en
minúscula no funcionará. No te permitirá
eliminar la rama,
sino mediante el uso de la opción menos
la mayúscula Obliga a Git a eliminar la rama independientemente
de su estado de fusión. Es importante tener cuidado
con este comando ya que elimina
irreversiblemente la
rama y Antes de la eliminación, asegúrese de no perder ningún cambio
importante. En la siguiente lección,
profundizaremos en trabajar con registros usando el comando Git
log. Mar.
13. Trabajar con registros de Git: personalizar la salida del registro y utilizar alias: Ahora pasemos a los registros. A menudo, es necesario ver
el último comite o el último par de commits para evitar mostrar todo el registro Puede ejecutar el
comando Git log y especificar cualquier número
con signo menos. Esto nos mostrará los últimos comits en
la historia del repositorio Usé menos dos y me
mostraron los dos últimos registros. El
comando Git log d stat se utiliza para ver estadísticas detalladas de
los cambios de las dos últimas emitidas Cuando ejecuta Git log stat, muestra los archivos modificados junto con las estadísticas de
corrección. El parámetro Git log pretty
one line se utiliza para mostrar
cada commit en el historial del repositorio en un formato compacto donde cada commit se muestra
en una línea separada. El
parámetro pretty one line instruye a Git sobre cómo formatear la salida
del historial de commit Con este parámetro, vemos una vista conveniente con el Commit has y el
mensaje en una línea. El
parámetro Git Log pretty format se utiliza para mostrar el historial de Commit con la capacidad de personalizar
el formato de salida. Este comando permite especificar un formato de salida personalizado
utilizando marcadores de posición especiales Puedes usar estos
marcadores de posición para mostrar varios atributos de Commit,
como Commit, has, author, commit
message, date y más Por ejemplo, muestro
solo el nombre del autor. En esta variante, muestro el hash abreviado y el nombre
aors para cada commit Hagamos que la salida sea
más conveniente. Aquí muestro el hash
abreviado, nombre de
aors, la fecha en que se realizó
el commit y el mensaje para cada Bueno, puedes
mejorarlo aún más agregando una gráfica. Es decir, hacemos casi lo mismo, pero con la adición
de la bandera gráfica, y vemos una salida de registro hermosa y
conveniente. El registro de Git, ya que el comando se utiliza para mostrar
el historial de commit, comenzando desde un punto
específico en el tiempo. Ahora veamos el registro. Por ejemplo, durante los
últimos tres días. El parámetro Since
le permite especificar un día o un período de tiempo a partir del cual desea ver
el historial de commit. Este parámetro acepta
varios formatos de fecha. Puede especificar
una fecha absoluta como el 1 de enero 2023 o un rango de tiempo relativo como dos días o un mes. Y en las últimas 4 horas, solo
hicimos dos emite O digamos,
por ejemplo, la última semana, o para el último día y 3
horas, también podemos mezclarlo. Escribiré un comando que
hará una selección en una línea donde
podamos ver el hash, el mensaje de commit
abreviado, y donde el autor es Denis, asegurando que estos son
commits frescos de los últimos dos días Y claro, si estás trabajando con Git en una interfaz
gráfica, puede
que no necesites esto,
pero aún así es bueno saberlo. Hablemos ahora de los alias de
Git, cómo crearlos y eliminarlos. El comando Git
config Global menos L se utiliza para ver la
configuración de Git globalmente. El parámetro global indica
que estamos trabajando con configuraciones
globales de Git que se aplican a todos los repositorios
de tu sistema Este comando listará todas las configuraciones de git que
se han establecido en su sistema. Ahora pasemos a los alias
de Git. Un Aas es un mecanismo que
permite crear atajos o comandos personalizados que utilizan una secuencia de
otros comandos de Git Con alias, puede
crear sus propios comandos en lugar de ingresar manualmente comandos
largos de complejos Aquí podemos ver que
anteriormente he creado
varios alias Y tomemos el primero. En lugar de escribir el comando
completo git status, puedo escribir ST. Esto
es un atajo. O aquí hay otro alias
donde simplemente puedo escribir GID IF y obtener toda la
información que
obtendría si ingresara este comando completamente en la línea de comandos. Practicemos la creación de
estos alias. Por ejemplo, tomaré un comando que
muestre ramas, rama
Git, y tomaré
un alias para ello, reemplazándolo con
la abreviatura BR. Ahora voy a usar mi alias
anterior IF y vemos nuevo alias
BR y funciona. Si utilizo esta abreviatura, veremos nuestras sucursales exactamente como si entráramos
al comando completo. Ahora, intentemos
eliminar estos alias. El comando unset elimina
lo que ya hemos creado. Puedo borrar nuestro alias
que muestra todas las sucursales. Ahora no existe ese alias, y el comando no funciona. Si queremos ver todas las sucursales, necesitamos ingresar el
comando completamente de nuevo. Además de crear tu ***, hay una extensión
para el shell SH. Para quienes trabajan con Mac y tienen SH en
sus computadoras, puede aprovechar la funcionalidad
adicional, que le permite usar
alias o comandos cortos para ejecución
más cómoda y
rápida las operaciones
de uso frecuente y Git Tener una lista de atajos
listos para hace que sea más fácil y
rápido usar Git. En la documentación de Git, puedes ver la lista
de alias disponibles Por ejemplo, el comando
simple GB mostrará todas las ramas de Git. Esta abreviatura
significa rama. La abreviatura GCF nos
mostrará la configuración de Git, y el comando GST mostrará el estado del directorio de
trabajo Entonces, por ahora, eso es todo. Nos vemos en la siguiente lección. Mar.
14. Entendiendo Git Rebase: qué es y por qué deberías usarlo: Bienvenidos de nuevo, chicos. Y ahora voy a hablar de
lo que es rebase en git Rebase es el
proceso de mover o fusionar una secuencia de kamits
en un nuevo La razón principal para usar rebase es preservar una
historia lineal de un proyecto Por ejemplo, imagina
una situación en
la que la rama principal haya progresado desde que empezaste a trabajar
en una rama característica Ahora, desea incorporar
las últimas actualizaciones de la rama principal a
su rama de características mientras
mantiene su historial limpio, haciendo que
parezca que está trabajando en función de los últimos
cambios de la rama principal. Esto hace que sea más fácil fusionar su rama de entidades de nuevo
en la rama principal más adelante. Rebase es especialmente
útil y fácil entender en el flujo de trabajo
que involucra futuras sucursales Así que comencemos. Si miras una estructura gráfica típica de
Git, verás el historial de ramas
fusionadas y en desarrollo formando una gráfica. Con el tiempo, esta gráfica puede
enredarse bastante, dificultando la
atracción de cambios específicos El comando git rebase ayuda a mantener un historial
más limpio y organizado Demostraré rebase en un proyecto donde hemos estado
trabajando con fusiones simples Ahora mismo, nuestra historia
contiene muchas ramas fusionadas, haciéndola algo desordenada Mientras se trabaja en un proyecto, generalmente
hay un repositorio
remoto donde el código se
actualiza constantemente para garantizar que su versión local del
proyecto se mantenga actualizada. Con la versión remota,
debe extraer
los últimos cambios antes de
realizar una rebase El primer paso es obtener
los últimos cambios
del repositorio remoto y
actualizar su sucursal principal local Como mi proyecto de prueba no está conectado al repositorio
remoto, no
tengo ningún
cambio nuevo que extraer. Sin embargo, en tu caso, este paso asegura que tu sucursal principal local sea idéntica a la
del repositorio remoto. A continuación, cambio a
mi rama de funciones, que ya contiene commits. Presta atención a
los hashes Commit. Esto es importante
para entender lo que sucede durante la rebase En este punto, la rama
principal local contiene nuevos cambios que faltan en la rama
de entidades. Mientras trabajaban en equipo, otros colegas han fusionado sus ramas de características
en la rama principal, y usted ha extraído
esos cambios del servidor remoto a
su sucursal principal local. Tu tarea ahora es fusionar tu rama de entidad
usando rebase El comando Git re base esencialmente hace que
parezca que hubieras comenzado a trabajar en tu rama de características desde la
última rama de Camt en mente Visualmente, aparece como
si la rama de la característica se moviera encima de
la última Camt No obstante, en realidad,
Git reescribe los ácaros, razón por la
que te
pedí que conocieras los hashes Commit Cuando comienza la rebase,
mueve la cabeza a la última
commit de la rama principal y comienza a reproducir las commits desde
la rama de características una por
una hasta esta última En nuestro caso, se produce un
conflicto matrimonial, lo cual es totalmente normal. En este punto,
tienes tres opciones. Resuelva el conflicto manualmente
y continúe la rebase usando el comando G base
dash dash continua, omita el conflicto mit y pase al
siguiente usando el salto base O abortar la rebase
y volver al estado anterior usando
el comando git rebase,
dash, dash, Resolveré el conflicto
y continuaré rebasando. Después de arreglar el problema, GIT abre un editor de texto, lo que nos permite modificar
el mensaje de commit, pero simplemente lo
guardaremos tal como está. Una vez que se completa la rebase, la cabeza vuelve a
nuestra rama de características Cambia junto
con las acciones de Git, primero desde el último
commit de la rama principal hasta el primer commit
de rebase de la rama feature Después al siguiente commit rebasado, y finalmente al
último commit rebasado A pesar de que todos los commits permanecen sin cambios en
términos de contenido, sus hashes comite
han sido Los commits originales aún
existen en el repositorio, pero ya no son visibles. Con el tiempo, serán
retirados por recolección de basura. Después de rebasar, cambiamos a la rama principal y
ejecutamos el comando, git rebase Git analizará
el brranch principal, identificará cualquier cambio faltante y aplicará estas
tres commits desde la rama de características a la última commit
y a la rama principal En este punto, podemos empujar nuestra rama principal actualizada de nuevo
al repositorio remoto. Pero como mi versión de mi proyecto no está conectada al repositorio
remoto, saltaré este paso al
hacer commits durante la rebase, a menudo abre win por defecto, lo que puede no ser
conveniente para todos Si prefieres un editor
diferente, puedes configurarlo
usando el comando. Git config global core editor, y en mi caso, nano. O si prefieres usar el
código VS como editor predeterminado, puedes usar este comando. Si no usas
el flanco de peso, el editor podría
abrirse como una página en blanco en lugar de permitirte
editar el mensaje de compromiso O puedes reemplazarlo por
cualquier otro editor que prefieras. Ya que me siento cómodo con
nano, me quedaré con él. Chicos, aprendimos a usar git rebase para mantener un historial de commit lineal
limpio Vimos cómo resolver conflictos, manejar operaciones de rebase y cambiar el editor predeterminado de Git Enhorabuena por
completar el curso. Hiciste un gran progreso, y ahora tienes un sólido
entendimiento de GID. El siguiente paso es
seguir practicando. Cuanto más uses Git,
más confianza te volverás. No se limite a confiar en la teoría. Aplica lo que has aprendido
en proyectos reales. Explora diferentes
funciones de git e intenta
utilizarlas en proyectos personales para
profundizar tu comprensión Recuerda que Git es una herramienta
esencial para los desarrolladores, y cuanto más practiques,
mejor estarás usándolo de manera eficiente
en varios flujos de trabajo. Buena suerte y seguir codificando.
Olha Al
