Unidad Temática I. GIT.pdf

Unidad Temática I. GIT 1. Control de Versiones 1.1 Definición El control de versiones es un sistema que registra cambios realizados en archivos o conjunto de archivos a lo largo del tiempo, permitiendo que puedas recuperar versiones anteriores de los mismos en caso de...

Unidad Temática I. GIT 1. Control de Versiones 1.1 Definición El control de versiones es un sistema que registra cambios realizados en archivos o conjunto de archivos a lo largo del tiempo, permitiendo que puedas recuperar versiones anteriores de los mismos en caso de ser necesario. Es una herramienta fundamental en el desarrollo de software y en la gestión de proyectos colaborativos, ya que facilita el trabajo en equipo, la coordinación de cambios y la gestión del código fuente. 1.2 Importancia del Control de Versiones 1. Pilar central de DevOps: Los sistemas de control de versiones son fundamentales en la metodología DevOps, ya que permiten una colaboración eficiente y rápida iteración del código fuente de un proyecto. 2. Copias de seguridad constantes: Trabajar con control de versiones garantiza que siempre haya una copia de seguridad de todo el código y los archivos del proyecto. Cada modificación se registra y se almacena en un historial accesible. 3. Confirmaciones (commits): Las actualizaciones de los proyectos se agrupan en confirmaciones, que son registros de los cambios realizados en el código fuente. Esto permite un seguimiento preciso de cada modificación y quién la realizó.  4. Restauración instantánea: En caso de errores o regresiones, los usuarios pueden revertir a versiones anteriores de los archivos de manera rápida y sencilla. Esto facilita la corrección de problemas y la restauración de funcionalidades previas. 5. Registro detallado de cambios: Los sistemas de control de versiones proporcionan un registro completo de todos los cambios realizados en el proyecto, lo que incluye quién realizó cada modificación y en qué momento. 6. Colaboración fluida: Al utilizar un sistema de control de versiones, todos los miembros del equipo pueden trabajar en varios archivos simultáneamente y fusionar fácilmente sus cambios en un repositorio centralizado. 7. Gestión de errores simplificada: Con acceso al historial completo del proyecto, es más fácil realizar un seguimiento de los errores y corregirlos de manera efectiva. También facilita la restauración de funciones eliminadas accidentalmente. 1.3 Funcionamiento del Control de Versiones 1. Rama principal o tronco maestro: Al crear un repositorio nuevo, se abre la rama principal o tronco maestro. Esta es la rama principal donde la base de código ingresa al canal en el que se compila y se implementa para que lo vea el usuario final. 2. Ramas: Las ramas son versiones paralelas de la base de código principal. Bifurcar es el proceso de crear ramas del código a partir de la rama principal. Esto permite que los desarrolladores introduzcan cambios en su propia rama sin afectar directamente la rama principal. 3. Beneficios de las ramas: Al crear ramas, los desarrolladores pueden trabajar en cambios específicos sin afectar la rama principal. Esto proporciona un entorno seguro para experimentar y desarrollar nuevas funcionalidades. 4. Fusionar: El sistema de control de versiones puede fusionar las ramas separadas en la rama principal una vez que los cambios han sido probados y están listos para ser integrados. Los desarrolladores pueden fusionar sus cambios en la rama principal cuando lo deseen. 5. Estrategias de bifurcación: Una estrategia de bifurcación adecuada es fundamental para evitar conflictos en el código y problemas con las compilaciones. Esto implica establecer políticas y procedimientos para la gestión de ramas, la fusión y la resolución de conflictos. 6. Sistemas de control de versiones: Los buenos sistemas de control de versiones proporcionan herramientas y funcionalidades que facilitan la  gestión de ramas y la fusión de cambios, lo que permite a los equipos sincronizarse sin problemas y corregir cualquier posible conflicto en el código. 1.3.1 Funcionamiento del Control de Versiones – Comparación Caso Real. Estás trabajando con un equipo para construir una casa. Cada miembro tiene una tarea específica: levantar paredes, instalar ventanas, pintar, entre otros. Si todos trabajaran directamente sobre la casa al mismo tiempo sin coordinación, podría haber problemas; por ejemplo, el pintor podría empezar a pintar antes de que las ventanas estén instaladas, causando desorganización y caos. Paso 1: Clonar el Repositorio (Obtener una copia del plano) Cada trabajador toma una copia del plano de la casa (el repositorio) y trabaja en su propia copia. Esto les permite realizar cambios en su área de trabajo sin afectar el trabajo de los demás. Ejemplo Git: Usas git clone para obtener una copia del repositorio. Paso 2: Crear una Rama (Trabajar en una tarea específica) Cada trabajador crea una rama específica en la que trabajará su tarea. Por ejemplo, el que instala ventanas crea una rama llamada "ventanas". Mientras trabaja, su trabajo no afecta el trabajo en otras ramas, como la pintura o la construcción de paredes. Ejemplo Git: Usas git branch ventanas y luego git checkout ventanas para comenzar a trabajar en esa tarea. Paso 3: Commit (Guardar Progreso) A medida que el instalador de ventanas avanza, realiza "commits", que son como guardar copias de seguridad de su trabajo. Cada commit tiene un mensaje que describe el progreso o cambios realizados, como "Ventanas del primer piso instaladas". Ejemplo Git: Usas git add. para preparar los cambios y git commit -m "Ventanas del primer piso instaladas" para guardarlos. Paso 4: Merge (Fusionar cambios) Una vez que todas las ventanas están instaladas, el trabajador fusiona su trabajo en el plano principal de la casa (la rama principal). Antes de fusionar, se asegura de que no haya conflictos o problemas con el trabajo de otros. Ejemplo Git: Usas git checkout main para volver a la rama principal y luego git merge ventanas para fusionar los cambios. Paso 5: Resolver Conflictos Si durante la fusión se descubre que la instalación de ventanas interfiere con otra tarea (por ejemplo, el pintor ya comenzó), el instalador de ventanas y el pintor trabajan juntos para resolver el conflicto, asegurándose de que ambas tareas se integren sin problemas. Ejemplo Git: Si hay conflictos, Git te alertará, y tendrás que resolverlos manualmente antes de completar la fusión. Paso 6: Revertir Cambios si es Necesario Si después de la fusión se descubre un problema serio con las ventanas, el instalador puede revertir su trabajo a un estado anterior, utilizando el historial de commits. Ejemplo Git: Usas git revert o git reset para volver a un commit anterior. Conclusión: Al final, el plano principal de la casa (el repositorio Git) está completo, con todas las tareas integradas armoniosamente. Este proceso asegura que cada tarea se realice correctamente y en el orden adecuado, evitando problemas y permitiendo la colaboración efectiva entre todos los miembros del equipo. Este es un ejemplo sencillo de cómo Git facilita la colaboración en proyectos, permitiendo a cada miembro del equipo trabajar en sus tareas sin interferir en el trabajo de los demás, y asegurando que todos los cambios se integren de manera eficiente y sin errores. 1.3.2 Funcionamiento del Control de Versiones - Detallado La primera imagen representa la diversidad de lenguajes de programación y tecnologías (como HTML, Python, Java, entre otros) conectados por flechas, lo que indica su interacción en un ecosistema de desarrollo de software. Cada uno de estos elementos podría representar un componente de un proyecto, en donde GIT se encargaría de gestionar las versiones y las colaboraciones entre desarrolladores. La segunda imagen encapsula un aspecto fundamental de GIT, la capacidad de tomar instantáneas (iconos de documentos o archivo conectados por flechas bidireccionales) del trabajo en diferentes etapas. Esto permite a los desarrolladores guardar versiones de su código a las que pueden volver si es necesario y rastrear los cambios a lo largo del tiempo, proporcionando una red que reduce el riesgo de perder trabajo. La tercera imagen describe un proceso común en GIT, la carpeta Working representa el directorio de trabajo, lugar donde se realizan cambios en los archivos. Cuando se confirman cambios en GIT, se crea una instantánea (La carpeta “snapshot-0” y “snapshot-1”), estas instantáneas registran el estado del proyecto en diferentes momentos, permitiendo capturar nuevas características como "feature 1" y "feature 2" de manera independiente. Los directorios etiquetados como working muestran diferentes estados del proyecto en momentos específicos, estos directorios son las áreas de trabajo. Cada snapshot (desde el 0 al 5) representa un punto en el tiempo en el que se guardaron cambios en el repositorio, como adiciones, modificaciones o eliminaciones de archivos. A continuación, en la cuarta imagen se ilustra un mensaje de commit, una descripción textual que acompaña a un commit, conformado por un resumen, que es una descripción breve y concisa de los cambios realizados y una fecha de finalización, que indica el momento en que se completaron los cambios y se realizó el commit. La quinta imagen ilustra un flujo de trabajo en Git. La rama principal contiene commits continuos. Se lanza una versión estable (Release Version 1.0) desde snapshot-40, pero se descubren errores (bugs) en el Snapshot-99, lo que lleva a la creación de una nueva rama para corregirlos y luego de ser resueltos, se continúa con nuevos desarrollos en esta nueva línea o rama. La sexta imagen representa Git como un árbol ayuda a visualizar cómo se organizan y gestionan las versiones en un repositorio. El tronco del árbol representa la rama principal del proyecto, comúnmente llamada "main" o "master", es la línea base del desarrollo. Las ramas son las divisiones que se extienden desde el tronco principal, cada una permite trabajar en diferentes características, correcciones o versiones sin afectar el tronco principal. Los nodos, representados como cuadrados, simbolizan los commits, puntos de control que registran los cambios realizados en los archivos del proyecto y las flechas o líneas que conectan los nodos y las ramas, mostrando cómo los cambios y las versiones se relacionan entre sí, indicando el flujo de los cambios, también muestra cómo las ramas se fusionan de vuelta al tronco principal o entre sí. Como se mencionó anteriormente, después de la liberación de la versión 1.0, se descubren errores. Para corregirlos, se crea una nueva rama donde se hacen los cambios necesarios. La palabra branch indica que las carpetas Snapchat-? y snapshot-109 están en ramas diferentes, es decir, son líneas de desarrollo separadas. Snapchat-? es parte de una rama creada para corregir errores, mientras que snapshot-109, es parte de otra rama que fue creada para continuar el desarrollo o agregar nuevas funcionalidades. Estas ramas se desarrollan de manera independiente, y los cambios en una rama no afectan a la otra a menos que se fusionen más adelante. La siguiente imagen representa visualmente cómo funcionan las ramas en GIT, estas permiten trabajar en diferentes líneas de desarrollo sin afectar la rama principal. Visualmente, una rama como "branch1" puede estar representada por una serie de carpetas conectadas que reflejan diferentes estados del proyecto, culminando en un punto de referencia o "snapshot-x". Otra rama, "branch 2", puede bifurcarse desde un punto específico en la historia de "branch1" y desarrollarse de manera independiente, resultando en su propio "snapshot-y". Esto permite crear, fusionar y comparar ramas para gestionar el código de manera más eficiente. A la izquierda, se aprecia una línea de cambios que siguen uno tras otro, como un historial. A la derecha, se ven ramas, representando desarrollos paralelos, como nuevas funciones o arreglos de errores. Ambos caminos, el de la izquierda y las ramas de la derecha, pueden existir al mismo tiempo sin interferir entre sí. Las flechas de colores indican diferentes acciones o direcciones en el proyecto, lo que permite trabajar en varias cosas a la vez sin afectar la línea principal de desarrollo. Esta imagen, simboliza a diferentes desarrolladores o colaboradores trabajando en el proyecto, esto sugiere que cada rama en el diagrama puede estar siendo gestionada o modificada por un usuario específico. Esto muestra como con GIT varias personas pueden trabajar en paralelo en distintas ramas del proyecto, reflejando el flujo de trabajo colaborativo en el desarrollo de software. Cada commit incluye un resumen del cambio, la fecha en que se hizo, la instantánea padre que muestra el commit anterior en el historial, estableciendo una cadena de cambios donde cada nuevo commit se basa en el anterior, y el nombre y correo electrónico del autor. Esto ayuda a entender qué se modificó, cuándo, y quién lo hizo. La siguiente ilustración muestra cómo GIT registra los cambios en archivos a lo largo del tiempo. A la izquierda, se ve un commit con un mensaje, una marca de tiempo, el autor y un código único. A la derecha, otro commit resalta un documento con un código SHA1 (etiqueta única) y tiene una marca de tiempo y un autor diferentes. Esto muestra cómo GIT usa códigos únicos y marcas de tiempo para seguir las modificaciones realizadas por diferentes personas en distintos momentos. A continuación, se representa una operación de rebase, una forma de combinar cambios de una rama en otra, pero en lugar de fusionar los commits, reorganiza la historia de los commits para que parezca que se aplicaron directamente sobre la rama de destino. Es útil para mantener una historia de commits más lineal y ordenada. La imagen ilustra el proceso de merge en GIT, donde tres ramas (master, math y bugfixes) con diferentes commits se combinan. Antes del merge, las ramas están separadas y contienen cambios distintos. Después del merge, los cambios de la rama math se integran en master, mostrando que los commits de math se alinean con los de master. Esto combina los cambios de diferentes ramas en una sola rama principal, facilitando el desarrollo colaborativo. En esta ilustración, se representa el área de staging, una zona intermedia donde los archivos modificados del directorio de trabajo se preparan antes de ser confirmados en un commit. Cuando se mueven estos archivos al staging, están listos para ser incluidos en una instantánea o snapshot, que se crea al hacer un commit. Este commit captura el estado actual del área de staging y lo guarda en el historial de Git, permitiendo registrar y rastrear los cambios realizados en el proyecto. 1.3.3 Operaciones GIT - Pull. La operación de "pull" se refiere a la acción de obtener cambios desde un repositorio remoto y aplicarlos a tu repositorio local. Básicamente, estás "extrayendo" o "recuperando" los últimos cambios que se han realizado en el repositorio remoto y actualizando tu copia local para que esté sincronizada con la versión más reciente del código. Cuando realizas un "pull", el SCV (como Git) comparará los cambios en el repositorio remoto con los cambios en tu repositorio local y fusionará automáticamente los cambios si es posible hacerlo sin conflictos. Si hay conflictos entre los cambios locales y remotos, el SCV puede solicitar que los resuelvas antes de completar la operación de "pull". - Push. La operación de "push" se refiere a la acción de enviar tus cambios locales a un repositorio remoto. Básicamente, estás "empujando" tus commits locales al repositorio remoto para que otros miembros del equipo puedan acceder a ellos y colaborar en el proyecto. Cuando realizas un "push", el SCV enviará tus commits locales al repositorio remoto y los incorporará a la rama específica en la que estás trabajando. Es importante tener en cuenta que, para realizar un "push", necesitas tener los permisos adecuados en el repositorio remoto. Si no tienes los permisos adecuados, no podrás realizar la operación de "push". 1.4 Tipos de Control de Versiones 1.4.1 Sistemas de Control de Versiones Centralizados. En este tipo de sistemas, existe un único repositorio central donde se almacena toda la historia y las versiones de los archivos. Los usuarios trabajan con copias locales de los archivos y realizan cambios que luego se sincronizan con el repositorio central. Ejemplo: Subversion (SVN) Subversion es un sistema de control de versiones centralizado ampliamente utilizado en proyectos de software. Los desarrolladores trabajan con copias locales de los archivos y utilizan comandos para enviar cambios al repositorio centralizado. SVN gestiona la historia de los archivos y facilita la colaboración en equipo. 1..4.2 Sistemas de Control de Versiones Distribuidos. En este tipo de sistemas, cada usuario tiene una copia completa del repositorio, lo que significa que no dependen de un servidor central. Esto permite a los usuarios realizar cambios y trabajar de forma independiente, incluso sin conexión a internet. Los cambios se pueden sincronizar entre las diferentes copias del repositorio. Ejemplo: Git Git es el sistema de control de versiones distribuido más conocido y utilizado en el mundo del desarrollo de software. Cada desarrollador tiene una copia completa del repositorio en su máquina local y puede realizar cambios, crear ramas (branching), fusionar ramas (merging) y gestionar la historia de los archivos de manera independiente. Git facilita la colaboración en equipos distribuidos y ofrece una potente gestión de versiones. 2. ¿Qué es GIT, GitBash y GitHub? 2.1 Git: Es un sistema de control de versiones distribuido que fue creado por Linus Torvalds en 2005 para el desarrollo del kernel de Linux. Permite a los desarrolladores trabajar en proyectos de software de manera colaborativa, manteniendo un registro de los cambios realizados en los archivos a lo largo del tiempo. 2.1.1 Características. Distribuido: Cada usuario tiene una copia completa del repositorio, lo que permite trabajar de forma independiente y sin conexión a internet.  Ramificación (branching) y fusión (merging) eficientes: Permite crear ramas para trabajar en nuevas características o arreglos de errores sin afectar la rama principal (por lo general llamada "master" o "main"). Luego, es posible fusionar los cambios de una rama a otra de manera controlada. Velocidad y eficiencia: Git está diseñado para ser rápido incluso con proyectos de gran tamaño. Gestión de versiones: Permite llevar un registro detallado de los cambios realizados en los archivos a lo largo del tiempo. Facilita el trabajo colaborativo: Permite a múltiples desarrolladores trabajar en un mismo proyecto sin interferirse entre sí. Amplia comunidad y soporte: Git es ampliamente utilizado en la industria del desarrollo de software, por lo que hay una gran cantidad de recursos disponibles y una comunidad activa que puede proporcionar soporte. 2.2 GitBash: Es una interfaz de línea de comandos que proporciona una terminal de Unix para sistemas Windows. Permite a los usuarios ejecutar comandos de Git y trabajar con repositorios Git, ya que viene con su instalación incorporada. 2.3 GitHub: Es una plataforma de desarrollo colaborativo basada en la nube que utiliza Git como sistema de control de versiones. Permite a los desarrolladores alojar y revisar código, gestionar proyectos, colaborar en equipo y realizar un seguimiento de los cambios en el código. GitHub cuenta con una amplia comunidad de desarrolladores y ofrece integraciones con una variedad de herramientas y servicios de terceros. 3. Conceptos Básicos de Git y sus Comandos más Utilizados. 3.1 Descarga e Instalación de Git en Windows 1. Descargar Git: Ve al sitio web oficial de Git: https://git-scm.com/ y haz clic en el enlace de descarga para Windows para comenzar la descarga. 2. Ejecutar el instalador: Una vez que se complete la descarga, haz doble clic en el archivo descargado para ejecutar el instalador de Git. 3. Configurar el instalador: Selecciona el idioma que prefieras para la instalación y haz clic en "OK". 4. Aceptar los términos de la licencia: Lee los términos de la licencia de Git y, si estás de acuerdo, marca la casilla "I accept the terms in the License Agreement".  5. Seleccionar componentes: En la siguiente pantalla, puedes dejar las opciones predeterminadas o personalizar la instalación según tus necesidades. Asegúrate de que "Git Bash Here" esté seleccionado, ya que proporciona una terminal de línea de comandos con Git. 6. Seleccionar el editor de texto: En la siguiente pantalla, se te pedirá que elijas un editor de texto predeterminado para Git. Puedes elegir entre Nano, Notepad++ o usar el editor de texto predeterminado de Git. Selecciona tu preferencia y haz clic en "Next". 7. Configurar el PATH del sistema: En la pantalla "Adjusting your PATH environment", se te darán tres opciones: "Use Git from the Windows Command Prompt": Esto te permitirá utilizar Git desde el símbolo del sistema de Windows. "Use Git and optional Unix tools from the Command Prompt": Esto te permitirá utilizar Git y herramientas Unix adicionales desde el símbolo del sistema de Windows. "Use Git from Git Bash only": Esto limitará el uso de Git solo a la terminal de Git Bash. Elige la opción que prefieras y haz clic en "Next". 8. Seleccionar el emulador de terminal (opcional): Si quieres, puedes elegir entre "MinTTY" o "Windows' default console window" como el emulador de terminal. Selecciona tu preferencia y haz clic en "Next". 9. Configurar la línea de finalización de los comandos (autocompletado): Selecciona si deseas utilizar el "Git Credential Manager" para habilitar la línea de finalización de los comandos. Haz tu selección y haz clic en "Next". 10. Instalar Git: Haz clic en el botón "Install" para comenzar la instalación de Git en tu sistema. 11. Finalizar la instalación: Una vez que la instalación haya finalizado, haz clic en "Finish" para cerrar el instalador. 3.2 Conceptos Básicos de Git. 1. Repositorio (Repository): Un repositorio Git es un almacén de datos donde se guarda el historial de cambios de un proyecto de software. Puede ser local (en la máquina del usuario) o remoto (alojado en un servidor como GitHub o GitBash). 2. Commit: Un commit representa un conjunto de cambios realizados en los archivos del proyecto en un momento específico.  Cada commit tiene un mensaje descriptivo que resume los cambios realizados. 3. Rama (Branch): Una rama es una línea de desarrollo independiente dentro del repositorio. Permite trabajar en nuevas características o arreglos de errores sin afectar la rama principal del proyecto (generalmente llamada "master" o "main"). 4. Fusión (Merge): La fusión es el proceso de combinar los cambios de una rama en otra. Se utiliza para incorporar los cambios realizados en una rama de desarrollo a la rama principal del proyecto. 5. Conflicto de fusión (Merge conflict): Ocurre cuando Git no puede realizar automáticamente la fusión de cambios debido a conflictos en los archivos. Se debe resolver manualmente, seleccionando qué cambios mantener y qué cambios descartar. 3.3 Comandos más Utilizados en Git. 1. git init: Inicializa un nuevo repositorio Git en el directorio actual. 2. git clone: Clona un repositorio Git existente en la máquina local. git clone 3. git add: Agrega cambios de archivos al área de preparación (staging area) para ser incluidos en el próximo commit. git add , si es git add. quiere decir que se le hace a todo el proyecto. 4. git commit: Crea un nuevo commit con los cambios en el área de preparación. Un commit es como una "foto" de los archivos en un momento determinado. Cada commit tiene un mensaje que describe los cambios realizados. git commit -m "Mensaje descriptivo del commit" 5. git push: Sube los commits locales a un repositorio remoto. git push 6. git pull: Descarga los cambios del repositorio remoto y los fusiona con la rama actual. git pull 7. git branch: Lista, crea o elimina ramas. Crear una rama: Para crear una nueva rama en Git, puedes utilizar el comando git branch seguido del nombre de la nueva rama que deseas crear. Este comando crea una nueva rama en el repositorio, pero no cambia a esa rama, es decir, sigues trabajando en la rama actual. git branch nombre de la rama Listar ramas: Para ver la lista de todas las ramas en tu repositorio Git, puedes usar el comando git branch. Este comando muestra todas las ramas disponibles en el repositorio, resaltando la rama en la que te encuentras actualmente. Eliminar una rama: Para eliminar una rama en Git, puedes usar el comando git branch -d seguido del nombre de la rama que deseas eliminar. Este comando elimina la rama especificada. Sin embargo, si hay cambios en la rama que aún no han sido fusionados en otra rama, Git no permitirá la eliminación de la rama por seguridad. git branch -d. 8. git merge: Fusiona los cambios de una rama en otra. git merge Cuando ejecutas git merge , Git fusionará los cambios de la rama especificada en la rama en la que te encuentras actualmente. Si no hay conflictos entre los cambios, Git realizará la fusión automáticamente y crearán un nuevo commit de fusión. Sin  embargo, si hay conflictos, Git te pedirá que resuelvas esos conflictos manualmente antes de que se pueda completar la fusión. Ejemplo: Supongamos que estás trabajando en una rama llamada master y deseas fusionar los cambios de la rama javascript en tu rama actual. El siguiente comando realizará la fusión: git checkout master git merge javascript 9. git status: Muestra el estado actual del repositorio, incluyendo archivos modificados, archivos en el área de preparación y ramas. git status -s. Los estados que pueden aparecer son: Untracked files (archivos no rastreados): Son nuevos archivos en el directorio de trabajo que Git aún no está rastreando. Aparecen con ??. Staged (archivos en el área de preparación): Archivos que han sido modificados y luego añadidos al área de preparación con git add. Se muestran con A para nuevos archivos y M para archivos modificados. Modified but not staged (archivos modificados, pero no preparados): Son archivos que han sido cambiados, pero no se han añadido al área de preparación. Se muestran con M en la segunda columna. Deleted (archivos eliminados): Archivos que han sido eliminados del directorio de trabajo pero que aún no se han reflejado en el área de preparación. Se muestran con D. Renamed/Copied (archivos renombrados o copiados): Git detecta que un archivo ha sido renombrado o copiado, mostrando R o C. 10. git log –oneline: Muestra un historial condensado de los commits en una sola línea, lo que facilita la visualización de la historia del repositorio. Cada commit se muestra en una única línea, mostrando su hash de commit (identificador único) seguido del mensaje de commit. Es útil para obtener una visión general rápida de los cambios realizados en el repositorio. 11. git reset –hard: Se utiliza para restablecer el estado del repositorio al estado de un commit específico. Con la opción --hard, todos los cambios realizados en el directorio de trabajo y en el área de preparación se descartan y se restauran según el commit especificado, lo que implica una eliminación completa de los cambios no confirmados. Este comando es útil para deshacer cambios no deseados o para volver a un estado anterior del repositorio de forma definitiva. 12. git diff [archivo] para precisar la muestra. El comando git diff --cached mostrará el contenido que se ha añadido al área de ensayo, es decir, los cambios que se incluirán en el historial si se hace commit. 13. git checkout: Para cambiar a una rama específica, puedes utilizar el comando git checkout seguido del nombre de la rama. Este comando te permite moverte entre diferentes ramas de tu repositorio. git checkout nueva-rama 3.4 Ejemplo Usando Comandos Git. 1. Crea un directorio (prueba) y dentro creamos un directorio css, un directorio js y un archivo index.html, dentro del directorio css creamos un archivo estilos.css, lo mismo hacemos con el directorio js y dentro creamos un archivo javascript.js. Todo esto lo hacemos con el programa Visual Studio Code, luego abrimos la consola con el comando Ctrl + ñ, este comando nos ubica en la ruta indicada. 2. Para crear o inicializar un nuevo repositorio GIT, navega a la carpeta de tu proyecto y ejecuta: git init. Esto creará una carpeta oculta.git que contiene todos los archivos necesarios para gestionar el repositorio. 3. Se verifica el estado de los archivos del proyecto: git status -s. 4. Realiza algunos cambios en los archivos del proyecto y añádelos al área de preparación: git add. 5. Se verifica el estado de los archivos del proyecto: git status -s. 6. Crea un nuevo commit con los cambios y proporciona un mensaje descriptivo: git commit -m "Inicio del proyecto". Nota. La primera vez que se realiza un commit solicita la información de nombre y correo, utilizando las siguientes instrucciones: git config --global user.email "[email protected]" y git config --global user.name "Nombre". Cada vez que se agregue un commit de un archivo determinado se debe ejecutar primero el comando: git add. 7. Se realizó un cambio en el archivo index.html y se ejecutó un commit proporcionando un mensaje descriptivo: git commit -m "Primer cambio". 8. Se listan las ramas hasta el momento con el comando git branch. Luego se crea una rama para cada directorio (css y js). Se listan nuevamente las ramas para visualizar los cambios realizados. Para movernos entre ramas utilizamos el comando git checkout, por ejemplo, para movernos a la rama estilos lo hacemos de la siguiente manera: git checkout estilos Realizamos un cambio en el archivo index.html y en el archivo estilos.css  Para ver el listado de los cambios y su descripción se utiliza el comando git log –oneline. Esto te mostrará una lista de commits con información como el autor, la fecha, y el mensaje del commit. Para visualizar los cambios realizados a nivel de código en determinado archivo se utiliza el comando git diff nombre del archivo. Para nuestro ejemplo, git diff 2ae1f19 PS C:\Users\ANDRES\Desktop\prueba> git diff 2ae1f19 diff --git a/css/estilos.css b/css/estilos.css index e69de29..86bf755 100644 --- a/css/estilos.css +++ b/css/estilos.css @@ -0,0 +1,3 @@ +.fondo { + background-color: blue; + } \ No newline at end of file diff --git a/index.html b/index.html : 9. Para fusionar las tres ramas (master, estilos y javascript) en una sola rama se utiliza el comando git merge nombre de la rama, primero debemos cerciorarnos que nos encontramos en la rama master (con el comando git checkout master) y luego ejecutamos git merge estilos y git merge javascript PS C:\Users\ANDRES\Desktop\prueba> git merge estilos Auto-merging index.html CONFLICT (content): Merge conflict in index.html Auto-merging css/estilos.css CONFLICT (content): Merge conflict in css/estilos.css Automatic merge failed; fix conflicts and then commit the result.  10. Para subir el repositorio desde Visual Studio Code a GitHub, es necesario tener abierta la cuenta de GitHub y crear un nuevo repositorio en el icono + opción New Repository, se le asigna un nombre, de tipo public y luego, con las siguientes líneas de código en la consola de Visual Studio Code se sube el proyecto a GitHub: git remote add origin https://github.com/usuario/prueba.git git branch -M master git push -u origin master 11. Para eliminar un repositorio en GitHub, sigue estos pasos: 1. Ve a la página principal del repositorio que deseas eliminar en GitHub. 2. Haz clic en el botón "Settings" (Configuración) en la esquina superior derecha del repositorio. 3. Desplázate hacia abajo hasta la sección "Danger Zone" (Zona de peligro). 4. Haz clic en el enlace "Delete this repository" (Eliminar este repositorio). 5. Te pedirán que escribas el nombre del repositorio para confirmar la eliminación. Escribe el nombre del repositorio tal como se muestra. 6. Haz clic en el botón rojo "I understand the consequences, delete this repository" (Entiendo las consecuencias, eliminar este repositorio). Una vez que confirmes la eliminación, el repositorio y todos sus datos asociados serán eliminados permanentemente. Ten en cuenta que esta acción no se puede deshacer, así que asegúrate de que realmente quieres eliminar el repositorio antes de proceder. 12. Visualización del Árbol de Commits Puedes visualizar el árbol de commits para ver cómo se relacionan las ramas y los commits entre sí. Usa el siguiente comando para una visualización simplificada: git log --graph --oneline –all 5. GitHub Pages GitHub Pages es un servicio de alojamiento de sitios web estáticos que permite a los usuarios publicar sitios web directamente desde sus repositorios de GitHub. Es una excelente manera de compartir documentación, proyectos personales, blogs, sitios web estáticos y más. 5.1 Características. 1. Fácil de usar: GitHub Pages es fácil de configurar y usar. Simplemente puedes alojar tu sitio web estático directamente desde un repositorio de GitHub. 2. Integración con Git: Como GitHub Pages utiliza Git para el control de versiones, puedes gestionar tu sitio web utilizando Git como lo harías con cualquier otro proyecto. 3. Soporte para dominios personalizados: Puedes asociar tu propio nombre de dominio con tu sitio web alojado en GitHub Pages, lo que te permite tener una URL personalizada para tu sitio. 4. Plantillas predefinidas: GitHub Pages ofrece una serie de plantillas predefinidas que puedes utilizar para configurar rápidamente tu sitio web. 5. Totalmente gratuito: GitHub Pages es un servicio gratuito para todos los usuarios de GitHub, lo que lo convierte en una opción económica para alojar sitios web personales y proyectos de código abierto. 5.2 Cómo Utilizar GitHub Pages. Ya con el repositorio creado en GitHub y deseas crear una página web utilizando la función de GitHub Pages, puedes seguir estos pasos: 1. Ve a la página de tu repositorio en GitHub. 2. Haz clic en la pestaña "Settings" (Configuración) en la parte superior derecha del repositorio. 3. Desplázate hacia abajo hasta encontrar la sección "Pages". 4. En la opción "Source" (Fuente), selecciona la rama que contiene tu código fuente. Por lo general, esto sería la rama 'main' o 'master'. 5. Selecciona la carpeta de tu proyecto que contiene los archivos HTML, CSS, JavaScript, u otros archivos necesarios para tu sitio web. Si tu proyecto está en la raíz del repositorio, puedes seleccionar "/root". 6. Haz clic en "Save" (Guardar). GitHub Pages ahora comenzará a construir tu sitio web a partir de los archivos seleccionados en la rama especificada. Una vez que la construcción esté completa, podrás acceder a tu sitio web utilizando la URL proporcionada en la sección "GitHub Pages" de la configuración de tu repositorio. Esta URL generalmente seguirá el formato https://.github.io/. Asegúrate de que tu proyecto tenga una estructura de archivos adecuada para una página web y que incluya un archivo HTML principal, así como cualquier otro recurso necesario (CSS, JavaScript, imágenes, etc.).