【Herramientas prácticas】-Git+GitLab

1. Introducción a Git

1.1 ¿Qué es Git?

Git es un sistema de control de versiones distribuido que se utiliza para rastrear y administrar cambios en el código del proyecto. Fue creado por Linus Torvalds en 2005 para ayudar a los desarrolladores a colaborar mejor, realizar un seguimiento de los cambios de código y volver fácilmente a las versiones anteriores.

Git tiene muchas ventajas sobre los sistemas de control de versiones centralizados tradicionales. No solo permite que cada desarrollador tenga una copia completa del proyecto (repositorio local), sino que también puede trabajar sin depender de un servidor central. Esto permite a Git realizar el control de versiones y el trabajo de desarrollo incluso cuando la conexión de red es inestable o el servidor no está disponible.

1.2 El concepto básico de Git

Antes de usar Git, es muy importante comprender algunos conceptos básicos.

1.2.1 Almacén (Repositorio)

Los repositorios de Git son donde se almacenan el código y el historial de versiones. Contiene todos los archivos del proyecto y los metadatos asociados a esos archivos. Cada proyecto suele tener un repositorio principal, que se puede crear en su computadora local o en un servicio alojado como GitLab.

1.2.2 Comprometerse

Confirmar es una de las operaciones más básicas en Git. Representa un cambio en el código del proyecto. Cada confirmación tiene un identificador único (hash SHA-1) que se usa para rastrear y hacer referencia a ese cambio.

1.2.3 Sucursal

Una rama es una copia en Git que se usa para desarrollar una función de forma independiente o resolver un problema. De forma predeterminada, cada proyecto tiene una rama maestra (generalmente "maestra" o "principal"), y otras ramas de funciones se crean a partir de la rama maestra. El beneficio de la bifurcación es que permite que los miembros del equipo trabajen en paralelo sin interferir con el código de los demás.

1.2.4 Fusionar

La fusión es el proceso de fusionar los cambios de una rama a otra. Cuando se desarrolla una función o se resuelve un problema, la rama relacionada se puede fusionar nuevamente con la rama principal, de modo que la rama principal también tenga estos cambios.

1.2.5 Repositorio Remoto

Un repositorio remoto es una copia de un repositorio Git almacenado en la red o en un servidor. Al interactuar con almacenes remotos, los miembros del equipo pueden compartir código, colaborar en el desarrollo e impulsar cambios locales en almacenes remotos o extraer los últimos cambios de almacenes remotos.

1.3 Instalar y configurar Git

Antes de que pueda comenzar a usar Git, primero debe instalar Git y realizar una configuración básica.

  1. Instalar Git: Dependiendo de su sistema operativo, descargue e instale Git. Git puede ejecutarse en varias plataformas, como Windows, Mac y Linux. Una vez completada la instalación, ingrese en el terminal de la línea de comando git --versionpara verificar si la instalación se realizó correctamente y ver la información de la versión de Git.

  2. Configure Git: después de instalar Git, debe configurar su nombre de usuario y dirección de correo electrónico, que aparecerán en sus registros de confirmación.

    Ingrese el siguiente comando en la terminal de línea de comandos, reemplazando el nombre de usuario y la dirección de correo electrónico con su propia información:

    git config --global user.name "Your Name"
    git config --global user.email "[email protected]"
    

Ahora que instaló y configuró Git, puede comenzar a usar Git para rastrear y administrar el código de su proyecto. A continuación, aprenderemos los conceptos básicos sobre cómo inicializar un repositorio, realizar confirmaciones y crear ramas.

Si no está familiarizado con el contenido del comando, puede utilizar

git --help
以及
git help 特定指令进行查询

2. Introducción a los almacenes comunes de código en la nube

En el desarrollo de software, el almacén de código en la nube es una herramienta clave para la colaboración en equipo y el alojamiento de código. A continuación, se presentan varias plataformas comunes de almacenamiento de código en la nube: GitHub, Gitee y Huawei CodeHub.

2.1. GitHub

GitHub es la plataforma de alojamiento de código fuente abierto más grande del mundo, fundada en 2008. Proporciona un sistema de gestión de repositorios Git en línea fácil de usar, así como muchas funciones de colaboración potentes. Las características clave de GitHub incluyen:

  • Amplia gama de proyectos de código abierto: hay millones de proyectos de código abierto en GitHub, incluidos varios lenguajes de programación, marcos y herramientas, etc.
  • Problemas y solicitudes de extracción: los miembros del equipo pueden informar problemas o realizar solicitudes de funciones enviando problemas. Al mismo tiempo, las solicitudes de extracción permiten a los miembros del equipo compartir y discutir sus modificaciones al proyecto, lo que facilita la revisión del código y el trabajo de fusión.
  • GitHub Actions: proporciona herramientas integradas de integración continua/implementación continua (CI/CD) para facilitar la creación, prueba e implementación automáticas de proyectos cuando se confirma el código.
  • Colaborar y socializar: los usuarios pueden discutir proyectos, enviar preguntas y solicitudes de extracción, y seguir proyectos de interés.

2.2. casa rural

Gitee (nube de código) es la plataforma de alojamiento de código más grande de China, establecida en 2013. Es similar a GitHub y proporciona funciones de colaboración en equipo y alojamiento de almacén de Git. Las características clave de Gitee incluyen:

  • Velocidad de acceso rápida: el servidor Gitee está ubicado en China, para los desarrolladores chinos, la velocidad de acceso es más rápida.
  • Servicio de versión empresarial: Gitee proporciona un servicio de versión empresarial, que brinda a los usuarios empresariales más personalización y funciones de valor agregado.
  • GVP (Gitee Valuable Project): Gitee proporciona recursos gratuitos y soporte para algunos proyectos de alta calidad para ayudar a que el proyecto crezca mejor.

2.3 Hub de código de Huawei

Huawei CodeHub es una plataforma de alojamiento de código en la nube lanzada por Huawei para el almacenamiento de código y la colaboración en equipo. Está desarrollado principalmente para Huawei internamente, pero también admite el registro de cuentas personales. Las características clave de CodeHub incluyen:

  • Soporte de nivel empresarial: diseñado para grandes empresas y proyectos, proporciona una gestión de código segura y confiable y funciones de colaboración en equipo.
  • Servicio global: los servidores CodeHub de Huawei se implementan en todo el mundo para garantizar la velocidad de acceso y la estabilidad para los usuarios globales.

Resumir

GitHub, Gitee y Huawei CodeHub son poderosas plataformas de almacenamiento de código en la nube que brindan funciones como colaboración en equipo, alojamiento de código e integración continua, lo que facilita a los desarrolladores administrar y colaborar en el código en la nube. De acuerdo con factores como los requisitos del proyecto, la ubicación geográfica y las políticas corporativas, los desarrolladores pueden elegir una plataforma de alojamiento de código que se adapte a ellos.

3. Instalación e implementación de GitLab

Instalar GitLab en CentOS

  1. Instalar paquetes dependientes:

    Abra una terminal y ejecute el siguiente comando para instalar los paquetes dependientes de GitLab:

    sudo yum install -y curl policycoreutils-python openssh-server postfix
    sudo systemctl enable sshd postfix
    sudo systemctl start sshd postfix
    sudo firewall-cmd --permanent --add-service=http
    sudo systemctl reload firewalld
    

    Aquí se instalan paquetes como curl, policycoreutils-python, openssh-server y postfix, que son necesarios para ejecutar GitLab.

  2. Agregue la fuente de software de GitLab e instale GitLab:

    Ejecute los siguientes comandos en una terminal para agregar las fuentes de software de GitLab e instalar GitLab:

    curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.rpm.sh | sudo bash
    sudo EXTERNAL_URL="http://your-gitlab-domain.com" yum install -y gitlab-ee
    

    Tenga en cuenta que http://your-gitlab-domain.comreemplace con su nombre de dominio o dirección IP real de GitLab.

  3. Configure e inicie GitLab:

    Una vez instalado, ejecute los siguientes comandos para configurar e iniciar GitLab:

    sudo gitlab-ctl reconfigure
    

    Esto configurará GitLab e iniciará todos los servicios necesarios.

  4. Establezca un nombre de usuario y contraseña de administrador:

    Requisito previo: es necesario asegurarse de que Gitlab y Redis estén en estado de inicio al mismo tiempo. Puede ejecutar gitlab-ctl starto gitlab-ctl restartcomando para iniciar o reiniciar.

    Ejecute el siguiente comando en la terminal para configurar el nombre de usuario y la contraseña del administrador de GitLab:

    gitlab-rails console -e production
    # 低版本可以尝试使用下面一句命令:
    gitlab-rails console production
    

    Una vez en la consola de GitLab, ejecute los siguientes comandos para configurar el nombre de usuario y la contraseña del administrador:

    user = User.where(id: 1).first
    user.username = 'your_admin_username'
    user.password = 'your_admin_password'
    user.password_confirmation = 'your_admin_password'
    user.save!
    exit
    

    Reemplace your_admin_usernamey your_admin_passwordcon su propio nombre de usuario y contraseña de administrador.

    Aviso:

    GitLab habilita la verificación de la política de contraseñas de forma predeterminada para mejorar la seguridad de la cuenta. Esta verificación evita el uso de contraseñas fáciles de adivinar o comunes. Debe elegir una contraseña más segura que no se descifre fácilmente.

    Aquí hay algunas sugerencias al crear contraseñas:

    1. Longitud: elija una contraseña de al menos 8 caracteres. Las contraseñas más largas son más seguras.
    2. Caracteres mixtos: utilice una combinación de letras mayúsculas y minúsculas, números y caracteres especiales. Por ejemplo, utilice letras mayúsculas, minúsculas, números y caracteres especiales (p. ej.: @#$%^&*).
    3. Evite palabras y frases comunes: Evite palabras comunes, fechas, información personal y frases comunes que son fáciles de adivinar como contraseñas.
    4. No reutilice las contraseñas: evite usar la misma contraseña en varias plataformas y cuentas. Utilice un administrador de contraseñas para generar y almacenar contraseñas aleatorias y únicas.
  5. Configure el nombre de dominio:

    /etc/gitlab/gitlab.rbConfigure su nombre de dominio en el archivo :

    sudo nano /etc/gitlab/gitlab.rb
    

    Agregue lo siguiente al archivo, your-gitlab-domain.comreemplazándolo con su nombre de dominio o dirección IP real de GitLab:

    external_url 'http://your-gitlab-domain.com'
    

    Guarda el archivo y cierra.

  6. Reconfigure y reinicie GitLab:

    Ejecute el siguiente comando para reconfigurar y reiniciar GitLab para que la configuración del nombre de dominio surta efecto:

    sudo gitlab-ctl reconfigure
    sudo gitlab-ctl restart
    

Ahora, ha instalado y configurado con éxito el servicio GitLab, y también se han configurado el nombre de usuario, la contraseña y el nombre de dominio del administrador. Puede acceder a su nombre de dominio o dirección IP de GitLab a través de un navegador e iniciar sesión con una cuenta de administrador para una mayor configuración y administración. Recuerde modificar la configuración relevante de acuerdo con la situación real y siga los documentos oficiales y las mejores prácticas para la instalación y configuración.

4. Funcionamiento de Git: conceptos básicos de Git

Git es un poderoso sistema de control de versiones que ayuda a los desarrolladores a rastrear y administrar los cambios de código para los proyectos. En esta sección, cubriremos las operaciones básicas de Git, incluida la inicialización de un repositorio, la adición de archivos, la confirmación de cambios y la visualización del historial.

4.1 Inicializar el almacén

Antes de que podamos comenzar a usar Git, debemos inicializar un nuevo repositorio local de Git. Abra una terminal en el directorio de su proyecto y ejecute el siguiente comando:

git init

Esto creará un nuevo repositorio de Git en el directorio actual y generará una carpeta oculta en el directorio raíz del proyecto .gitpara almacenar la configuración de Git y la información del historial de versiones.

4.2 Agregar archivos

nosotros podemos usar

git status 

Ver el estado de envío y control de los archivos en el directorio git

Antes de que el archivo se pueda incluir en el control de versiones de Git, debemos agregar el archivo al área de ensayo (Área de ensayo). Ejecute el siguiente comando para agregar el archivo:

git add <filename>

O, si desea agregar todos los archivos modificados al área de preparación a la vez, puede usar el siguiente comando:

git add .

4.3 Confirmar cambios

Una vez que los archivos se agregan al área de preparación, podemos confirmar esos cambios en el repositorio local, produciendo una versión local. Ejecute el siguiente comando para confirmar:

Hay tres métodos de presentación:

El primer método: agregar registros manualmente

git commit

Luego se abrirá la herramienta vi, debe explicar el contenido enviado, puede usar esc para salir de la edición, :wq para guardar la edición

imagen-20230719202154184

El segundo tipo:

git commit -m "Commit message"

Commit messageEs la información descriptiva de este envío, que puede explicar sucintamente el contenido y el propósito de este envío.

Nota: después de modificar o agregar archivos o eliminar archivos, aún debe ejecutar git add y luego verificar su estado antes de realizar la operación de git commit

El tercer tipo:

Las operaciones de dos pasos se pueden combinar en la ejecución de un solo paso

git commit -am '备注'

Tenga en cuenta que el segundo paso solo puede agregar y enviar archivos que hayan sido rastreados, lo que puede entenderse como agregar y enviar solo para operaciones de modificación y eliminación.

4.4 Ver historial

Git Log es un comando para ver el historial de confirmación de Git. Puede mostrar los detalles de cada confirmación en el proyecto, incluido el autor, la fecha, el hash de la confirmación y la descripción de la confirmación, etc. En esta nota didáctica, presentaremos siete operaciones Git Log de uso común.

4.4.1. registro de git

git logcomando para mostrar el historial de confirmaciones de un proyecto. De forma predeterminada, enumera todas las confirmaciones en orden cronológico, con las confirmaciones más recientes en la parte superior. Cada registro de confirmación incluye un hash de confirmación, un autor, una fecha de confirmación y una descripción de la confirmación.

git log

4.4.2. registro de git -p -2

git log -p -2El comando mostrará los dos últimos registros de confirmación y mostrará los cambios específicos de cada confirmación. Esto permite ver qué modificaciones introdujo cada confirmación.

git log -p -2

4.4.3. registro de git --autor

git log --authorEl comando nos permite filtrar los registros de confirmación por el nombre del autor de la confirmación. Esto es muy útil en proyectos colaborativos de varias personas, donde puede encontrar rápidamente el historial de confirmación de un autor.

git log --author="John Doe"

4.4.4. registro de git --oneline

git log --onelineEl comando mostrará el historial de confirmación de manera concisa, cada confirmación ocupa solo una línea y solo se muestran el hash de la confirmación y la descripción de la confirmación.

git log --oneline

4.4.5. registro de git --gráfico

git log --graphEl comando puede dibujar gráficos ASCII para mostrar el historial de fusión de ramas, para ver la fusión de ramas de manera más intuitiva.

git log --graph

4.4.6. git log --pretty=una línea

git log --pretty=onelineEl comando muestra el historial de confirmaciones en un formato personalizado, aquí onelinese usa el formato.

git log --pretty=oneline

4.4.7. registro de git --pretty=formato

git log --pretty=formatLos comandos nos permiten personalizar el formato de salida del historial de confirmaciones de una forma más flexible. Podemos usar marcadores de posición específicos para mostrar información de confirmación.

git log --pretty=format:"%h - %an, %ar : %s"

El comando anterior mostrará el historial de confirmación en un formato similar a "commithash-authorname, tiempo relativo: descripción de la confirmación".

4.5 Diferencias entre antes y después de la modificación del archivo de seguimiento

En Git, puede usar git diffel comando para comparar la diferencia antes y después de la modificación. Este comando puede ayudarnos a ver las diferencias entre el directorio de trabajo y el área de preparación, o ver las diferencias entre el área de preparación y la última confirmación. A continuación se describen dos operaciones Git Diff de uso común.

4.5.1. diferencia de git

git diffEl comando se utiliza para comparar las diferencias entre las modificaciones en el directorio de trabajo y el área de ensayo. Mostrará el contenido de modificación específico del archivo, incluidas las líneas agregadas, eliminadas y modificadas.

git diff

El comando anterior mostrará la diferencia entre los cambios no preparados en el directorio de trabajo y el área de preparación actual.

4.5.2. git diff --staged o git diff --cached

git diff --stagedEl comando o git diff --cachedse usa para comparar las diferencias entre el área de preparación y la última confirmación. Mostrará la diferencia entre los cambios por etapas y la última confirmación.

git diff --staged

El comando anterior mostrará la diferencia entre los cambios por etapas y la última confirmación.

Estas dos operaciones de Git Diff pueden ayudarnos a comprender la diferencia entre el antes y el después de las modificaciones, y nos ayudan a revisar y comprender las modificaciones que hemos realizado. Tenga en cuenta que al usar git diffel comando, puede restringir la diferenciación a archivos específicos agregando un parámetro de ruta de archivo.

Recuerde que Git Diff solo muestra lo que se modificó, no cambia ningún archivo ni confirma ningún cambio. Solo se usa para mostrar información de diferencias para ayudar a los desarrolladores con la revisión del código y el control de versiones.

4.6 Ignorar archivo Git

En Git, podemos .gitignoreespecificar los archivos y directorios que se ignorarán a través del archivo, y estos archivos ignorados no se agregarán al control de versiones. Los siguientes son varios métodos de ignorar archivos de uso común:

4.6.1. .gitignore

.gitignorearchivo es un archivo de texto que enumera archivos y directorios para ignorar. Podemos agregar patrones en este archivo para hacer coincidir archivos o directorios para ignorar.

Ejemplo .gitignorede contenido de archivo:

HELP.md
target/
!.mvn/wrapper/maven-wrapper.jar
!**/src/main/**/target/
!**/src/test/**/target/

### STS ###
.apt_generated
.classpath
.factorypath
.project
.settings
.springBeans
.sts4-cache

### IntelliJ IDEA ###
.idea
*.iws
*.iml
*.ipr

4.6.2. /node_modules

/node_modulesIndica ignorar el directorio y su contenido bajo el directorio raíz del proyecto node_modules. Por lo general, este directorio contiene una gran cantidad de bibliotecas dependientes de terceros, que no deben agregarse al control de versiones, ya que pueden reconstruirse a través de yo archivos package.jsoncomo este.package-lock.jsonyarn.lock

4.6.3. *.registro

*.logIndica ignorar todos los archivos .logcon sufijos. Esto se usa comúnmente en proyectos para ignorar los archivos de registro, ya que los archivos de registro a menudo crecen y ocupan espacio y no son adecuados para su inclusión en el control de versiones.

4.6.4. *.cremallera

*.zipIndica ignorar todos los archivos .zipcon sufijos. Esto se usa comúnmente en proyectos para ignorar tarballs, ya que pueden compilarse o usarse para distribución y no deben incluirse en el control de versiones.

4.6.5. git rm -r --en caché.

Si algunos archivos se han enviado por error al control de versiones y desea eliminarlos del control de versiones pero mantenerlos en el directorio de trabajo, puede usar la opción git rmdel comando . --cachedEsto eliminará el archivo especificado del área de preparación, pero lo mantendrá en el directorio de trabajo local.

git rm -r --cached .

El comando anterior eliminará todos los archivos en el directorio actual del área de almacenamiento temporal, incluidos los archivos enviados al control de versiones por error.

Recuerde, antes de ignorar archivos, asegúrese de que no estén comprometidos con el control de versiones. Debido a que una vez que se confirma un archivo, .gitignoreya no funcionará en él, debe usar git rmel comando para eliminarlo del control de versiones.

4.7 Operación de restauración de Git

En Git, existen diferentes comandos y estrategias para revertir archivos o confirmaciones. A continuación se muestra un conjunto completo de operaciones de restauración de Git, incluida la restauración de archivos modificados, la restauración de archivos en etapas y la restauración del historial de confirmaciones.

4.7.1 Restauración de archivos modificados

Si realizó cambios en un archivo en su directorio de trabajo pero no lo agregó al área de preparación, puede restaurar el archivo con el siguiente comando:

git checkout -- [filename]

Este comando [filename]restaurará el archivo al estado en el que se encontraba en el momento de la confirmación más reciente. Tenga en cuenta que esta operación perderá la modificación del archivo en el directorio de trabajo, confirme antes de ejecutar.

4.7.2 Restauración de archivos provisionales

Si ya ha agregado un archivo al área de preparación, pero desea restaurarlo al estado de la última confirmación, puede usar el siguiente comando:

git reset HEAD [filename]

Este comando [filename]eliminará el archivo del área de preparación, pero mantendrá sus modificaciones en el directorio de trabajo.

Luego puede restaurar los archivos en su directorio de trabajo a su último estado comprometido con el siguiente comando:

git checkout -- [filename]

Este comando [filename]revertirá el archivo a su confirmación más reciente, descartando los cambios en el directorio de trabajo.

También puede usar git checkout para restaurar la versión al contenido anterior

git checkout [版本号] -- [fileName]

4.7.3 Restauración del historial de confirmaciones

Si desea volver a un estado de confirmación anterior, puede usar el siguiente comando:

git log

Este comando mostrará el historial de confirmación y obtendrá el hash de la confirmación que desea revertir.

Luego, use el siguiente comando para volver al estado de confirmación especificado:

git reset --hard [commit-hash]

Este comando apunta la rama actual a la confirmación especificada, descartando todas las confirmaciones posteriores. Úselo con precaución, ya que esto eliminará futuras confirmaciones.

Nota: La operación de restaurar el historial de confirmación es irreversible, asegúrese de comprender esto y haga una copia de seguridad de su código o comuníquese con otros desarrolladores del proyecto antes de realizarlo.

Este es un conjunto completo de operaciones de restauración de Git, que incluye la restauración de archivos modificados, la restauración de archivos preparados y la restauración del historial de confirmaciones. Según sus necesidades específicas, elija la estrategia de restauración adecuada para recuperar archivos o confirmaciones. Recuerde, antes de realizar cualquier operación de reversión de Git, es mejor confirmar su operación primero, para no perder cambios o confirmaciones importantes.

4.7.3.1. git reset --cabeza dura^

Use git reset --hard HEAD^el comando para restaurar el puntero HEAD y el directorio de trabajo de la rama actual al último estado de confirmación. Este comando descartará la confirmación más reciente y todas las confirmaciones posteriores.

git reset --hard HEAD^

El comando anterior HEAD^significa el último envío. Al ejecutar este comando, volverá al estado del último envío.

4.7.3.2. git reset --cabeza dura^^

De manera similar, git reset --hard HEAD^^el puntero HEAD y el directorio de trabajo de la rama actual se pueden restaurar al penúltimo estado de confirmación usando el comando. Este comando descarta las dos últimas confirmaciones y todas las confirmaciones posteriores.

git reset --hard HEAD^^

El comando anterior HEAD^^significa el penúltimo envío, al ejecutar este comando, volverá al penúltimo estado de envío.

4.7.3.3. git reset --hard HEAD [código hash]

Otra forma es usar el hash de confirmación para volver a un estado de confirmación específico. Puede usar git logel comando para obtener el hash de la confirmación que desea revertir.

git log

Una vez que tenga el hash de la confirmación que desea revertir, puede usar el siguiente comando para revertirlo:

git reset --hard [hashcode]

en el comando anterior [hashcode]está el hash de la confirmación específica a la que debe volver.

Tenga en cuenta que antes de realizar una operación de restauración, asegúrese de haber realizado una copia de seguridad del código y las confirmaciones importantes. La reversión es irreversible y perderá los cambios no guardados y las confirmaciones posteriores

Ver el número de versión del puntero:

git reflog

5. Operación Git - gestión de sucursales

La ramificación es una de las funciones más poderosas de Git, que le permite desarrollar una función de forma independiente o solucionar un problema en un proyecto sin afectar la estabilidad de la rama principal. En esta sección, aprenderemos cómo crear ramas, cambiar ramas, fusionar ramas y resolver conflictos de fusión.

En Git, la bifurcación es una característica muy útil que nos permite administrar fácilmente diferentes versiones de código en el desarrollo de proyectos. A continuación se muestra un conjunto de comandos de manipulación de ramas de Git de uso común, que incluyen la creación, el cambio y la eliminación de ramas.

5.1 Crear una sucursal

Para crear una nueva rama, use el siguiente comando:

git branch [branch_name]

Esto creará una nueva rama llamada donde está la confirmación actual [branch_name], pero todavía estás atascado en la rama actual.

5.2 Cambiar de rama

Para cambiar a una rama ya existente, puede usar el siguiente comando:

git checkout [branch_name]

Esto lo cambiará a [branch_name]una rama existente nombrada y cambiará su directorio de trabajo a esa rama.

O, si desea crear y cambiar a una nueva rama de una sola vez, puede usar el siguiente comando:

git checkout -b [branch_name]

Esto creará una nueva rama [branch_name]y cambiará su directorio de trabajo a ella.

5.3 Eliminar sucursal

Si desea eliminar una rama que se ha fusionado, puede usar el siguiente comando:

git branch -d [branch_name]

Esto eliminará [branch_name]la rama fusionada llamada . Si la rama no se ha fusionado (aún no se ha fusionado con la rama maestra), el uso -dde la opción no eliminará, esto es para evitar la eliminación accidental de cambios no fusionados.

Si está seguro de que desea eliminar las ramas no fusionadas, puede usar el siguiente comando:

git branch -D [branch_name]

Esto eliminará a la fuerza la [branch_name]rama no fusionada llamada . Utilice -Dla opción con precaución, ya que eliminará la rama de forma irreversible.

Pero, de hecho, al eliminar una rama, la rama se puede restaurar, como describir el valor hash y el nombre de la rama al eliminar la rama.

imagen-20230720021533974

Podemos crear una nueva rama para la recuperación.

git branch master 9cfb21e

Siempre que el nombre y el valor hash de la rama sean coherentes con la versión escrita y eliminada

5.4 Ramas de consulta

git branch

5.5 Fusión de sucursales

En Git, fusionar ramas es el proceso de fusionar cambios de una rama a otra. Esto hace posible fusionar código y modificaciones en diferentes ramas en una nueva confirmación, aplicando así una función o corrección a la rama principal o a otra rama de destino. El siguiente es el funcionamiento general de la fusión de sucursales:

5.5.1 Cambiar a la rama de destino

Primero, debe cambiar a la rama de destino en la que desea fusionarse. Por ejemplo, si desea fusionar la rama Característica en la rama principal (generalmente la rama maino master), puede usar el siguiente comando:

git checkout main

5.5.2 Fusión de sucursales

Use el siguiente comando para fusionar la rama de origen (como la rama de función) en la rama de destino (rama maestra):

git merge feature

El comando anterior fusionará los cambios en la rama Característica en la rama maestra en la que se encuentra actualmente.

5.5.3 Resolución de conflictos (si los hubiere)

Resolver conflictos cuando Git fusiona ramas es una tarea común en el desarrollo. Cuando dos ramas modifican la misma parte del mismo archivo al mismo tiempo, Git no puede determinar automáticamente qué cambio debe conservarse, lo que genera un conflicto. Estos son los pasos para resolver los conflictos de combinación:

5.5.3.1 Combinar git merge [branch_name]con

Primero, use git merge [branch_name]el comando para fusionar la rama de destino con la rama de origen. Por ejemplo, para fusionar la rama Característica en la rama principal (generalmente la rama maino master), puede ejecutar el siguiente comando:

git checkout main  # 切换到主分支
git merge feature  # 合并 Feature 分支到主分支

5.5.3.2 Usar git statuspara ver la causa del conflicto

Después de realizar la combinación, si hay conflictos, puede usar git statusel comando para ver los archivos y los motivos en conflicto:

git status

git statusSe mostrará una lista de archivos en conflicto y se le indicará que los conflictos deben resolverse.

5.5.3.3 Usar git merge --abortfusión de abandono

Si encuentra problemas durante el proceso de fusión o desea abandonar la fusión, puede usar git merge --abortel comando para volver al estado anterior a la fusión e ignorar la fusión:

git merge --abort

5.5.3.4 Seleccionar manualmente el contenido correcto

Abra el archivo en conflicto y Git marcará las partes en conflicto con <<<<<<<, =======y . >>>>>>>Debe editar manualmente el archivo, decidir qué cambios conservar y cómo resolver los conflictos. Después de modificar el archivo en conflicto, guárdelo.

5.5.3.5 git addAdición de archivos resueltos en conflicto mediante

Cuando haya terminado de resolver los conflictos, use git addel comando para marcar los archivos resueltos como resueltos:

git add [resolved_file1] [resolved_file2]  # 添加解决冲突后的文件

5.5.3.6 Uso git commitde commit para resolver cambios conflictivos

Finalmente, confirme git commitlos cambios resueltos en conflicto con el comando:

git commit -m "Resolve merge conflicts"  # 提交解决冲突后的更改

Ahora, los conflictos se resuelven y la combinación se completa con éxito.

5.6 Ver gráfico de líneas de versión

En Git, puede usar diferentes opciones para ver un gráfico de líneas del historial de versiones, que muestra la relación entre las confirmaciones y la estructura de la rama. Aquí hay algunos comandos de uso común para ver el gráfico de línea de versión:

5.6.1. registro de git

Utilice git logel comando para mostrar el historial completo de confirmaciones, incluidos los detalles de cada confirmación, pero no muestra gráficamente el gráfico de líneas de la versión.

git log

5.6.2. registro de git --oneline

Utilice git log --onelineel comando para mostrar el historial de confirmaciones de manera sucinta, mostrando solo una línea por confirmación, incluido el hash de la confirmación y la descripción de la confirmación.

git log --oneline

5.6.3. registro de git --oneline --gráfico

Utilice git log --oneline --graphel comando para mostrar un gráfico de líneas del historial de confirmaciones y mostrar gráficamente la estructura de la rama.

git log --oneline --graph

5.6.4. registro de git --una línea --gráfico --todos

Utilice git log --oneline --graph --allel comando para mostrar un gráfico de líneas del historial de confirmaciones, incluidas todas las ramas.

git log --oneline --graph --all

5.6.5. git log --oneline --graph -[número]

Utilice git log --oneline --graph -[number]el comando para limitar el número de confirmaciones que se muestran. Reemplace [number]con la cantidad de confirmaciones que desea mostrar, por ejemplo, para mostrar las últimas 5 confirmaciones, use:

git log --oneline --graph -5

Esto mostrará un gráfico de líneas de las 5 confirmaciones más recientes.

Las opciones en los comandos anteriores --onelinesimplificarán la salida, haciendo que los diagramas de líneas sean más compactos y legibles. Y --graphla opción mostrará un gráfico de líneas del historial de confirmaciones, lo que lo ayudará a comprender mejor la estructura de la versión del proyecto.

6. Operación Git - almacén remoto

Un repositorio remoto es un repositorio Git almacenado en una red o servidor, que permite a los miembros del equipo compartir código, colaborar en el desarrollo y mantener copias de seguridad del código. En esta sección, aprenderemos cómo vincular repositorios remotos, enviar cambios, extraer cambios y resolver conflictos de fusión.

6.1 Almacén remoto asociado

Antes de asociar un repositorio local con un repositorio remoto de GitLab, debe crear un repositorio en blanco en GitLab. Luego, ejecute el siguiente comando en el directorio del almacén local:

git remote add origin <remote-repository-url>

Reemplace <remote-repository-url>con la URL de su repositorio remoto de GitLab. Este comando agregará un alias de repositorio remoto nombrado en el repositorio local origin.

6.2 Impulsar cambios

Cuando haya realizado algunos cambios en el almacén local y desee enviar estos cambios al almacén remoto, ejecute el siguiente comando:

git push origin <branch-name>

Esto <branch-name>enviará los cambios de la rama al repositorio remoto. Si desea enviar todos los cambios desde su sucursal local al repositorio remoto, puede usar --allel parámetro:

git push --all origin

6.3 Tirando de cambios

Cuando los miembros de su equipo realicen algunos cambios en el repositorio remoto y desee obtener estos últimos cambios, ejecute el siguiente comando:

git pull origin <branch-name>

Esto obtendrá <branch-name>los últimos cambios de la rama del repositorio remoto y los fusionará en la rama local en la que se encuentra actualmente.

6.4 Resolución de conflictos

Al extraer cambios de un repositorio remoto, a veces se producen conflictos. Esto generalmente se debe a que sus cambios locales entraron en conflicto con los cambios del repositorio remoto en la misma ubicación. Los pasos para resolver conflictos son similares a los pasos anteriores para resolver conflictos cuando se fusionan ramas.

Primero, Git marcará el conflicto en el archivo de conflicto. Debe editar estos archivos, resolver conflictos y guardar cambios. Luego, ejecute el siguiente comando para completar la combinación:

git commit -m "Merge remote-tracking branch 'origin/branch-name'"

El comando anterior confirma los cambios combinados en la rama local.

Nota: Al resolver conflictos, verifique dos veces el código para asegurarse de que no haya errores y asegúrese de que la confirmación final sea correcta.

A través de las operaciones de almacén remotas anteriores, puede colaborar con los miembros del equipo en el desarrollo y obtener los últimos cambios de código a tiempo. El almacén remoto facilita y hace más eficiente el desarrollo colaborativo de varias personas, al tiempo que garantiza la coherencia y la seguridad del código. Recuerde realizar una confirmación antes de enviar y extraer código para asegurarse de que su espacio de trabajo esté limpio para evitar conflictos y cambios de código accidentales.

7. Operación GitLab

GitLab es una poderosa plataforma de hospedaje de código que brinda funciones completas para respaldar la colaboración en equipo y la integración continua/entrega continua. En esta sección, aprenderemos cómo configurar un servidor GitLab local, crear proyectos, agregar miembros, usar Issue para rastrear problemas y tareas, manejar solicitudes de combinación e introducir los conceptos de integración continua y entrega continua.

7.1 Construir GitLab local

Para construir un servidor GitLab localmente, puede usar el paquete de instalación de Omnibus o el código fuente para la instalación. Aquí tomamos el paquete de instalación de Omnibus como ejemplo para presentar brevemente los pasos de construcción:

  • Descargue el paquete de instalación de Omnibus
  • Ejecute el script de instalación y configure GitLab
  • Inicie el servicio GitLab

Tenga en cuenta que puede consultar la documentación oficial de GitLab u otros tutoriales para conocer los pasos de construcción detallados.

7.2 Creación de un proyecto

Después de configurar con éxito el servidor GitLab local, puede crear un nuevo proyecto en GitLab. Inicie sesión en GitLab y siga los pasos a continuación para crear un proyecto:

  • Haga clic en el botón "Nuevo proyecto" en la barra de navegación superior
  • Ingrese el nombre del proyecto, la descripción y otra información
  • Elige visibilidad y acceso
  • Haga clic en el botón "Crear proyecto" para completar la creación del proyecto

7.3 Agregar miembros

Una vez creado el proyecto, puede invitar a otras personas a unirse al proyecto y colaborar en el desarrollo. Siga los pasos a continuación para agregar miembros:

  • Ingrese a la página del proyecto, haga clic en la pestaña "Configuración"
  • Seleccione la subpestaña "Miembros"
  • Ingrese el nombre de usuario o la dirección de correo electrónico de GitLab del miembro
  • Establezca el nivel de permiso de los miembros (como Desarrollador, Mantenedor, etc.)
  • Haga clic en el botón "Agregar al proyecto" para invitar a los miembros a unirse al proyecto

7.4 Seguimiento de problemas

GitLab proporciona una poderosa función de seguimiento de problemas para registrar y administrar problemas y tareas en proyectos. En la pestaña "Problemas" de la página del proyecto, puede crear nuevos problemas, asignar personas responsables, establecer prioridades, etiquetas, etc.

7.5. Fusionar solicitudes

Merge Requests es una función en GitLab para confirmar y manejar fusiones de código. Los desarrolladores pueden enviar su código a la rama principal mediante la creación de Solicitudes de fusión y, después de la revisión y discusión por parte de otros miembros, finalmente se fusionan en la rama principal.

7.6. CI/CD

La integración continua (CI) y la entrega continua (CD) son procesos importantes en el desarrollo de software moderno. GitLab proporciona herramientas integradas de CI/CD para ayudarlo a compilar, probar e implementar automáticamente proyectos cuando se confirma el código. A través de archivos de configuración .gitlab-ci.yml, puede definir procesos de CI/CD y automatizar compilaciones e implementaciones.

Los anteriores son algunos pasos clave del funcionamiento de GitLab. Al configurar un servidor GitLab local, crear proyectos e invitar a miembros, puede lograr el desarrollo colaborativo del equipo. Use Issue para realizar un seguimiento de los problemas y Merge Requests para manejar la combinación de códigos, lo que hace que el proceso de desarrollo sea más ordenado y eficiente. Y, al configurar el proceso de CI/CD, puede lograr una integración continua y una entrega continua, mejorando la velocidad y la calidad de la entrega de software. Recuerde usar de manera flexible las funciones de GitLab para respaldar su proceso de desarrollo de acuerdo con las necesidades reales y la escala del proyecto.

imagen-20230720184216181

imagen-20230720184301827

7.7 Crear una clave secreta

ssh-keygen

(2)

Luego aparece [Generando par de claves rsa pública/privada.
Ingrese el archivo en el que guardar la clave (/c/Users/Lenovo/.ssh/id_rsa):], presione [Enter],

(3)

[Directorio creado '/c/Users/Lenovo/.ssh'.
Ingrese la frase de contraseña (vacío si no hay frase de contraseña):] aparecerá para solicitarle que ingrese la contraseña (en este momento, la contraseña es invisible),

(4)

【Ingrese la misma frase de contraseña nuevamente:】, ingrese la contraseña nuevamente, presione Enter,

imagen-20230720142929400

Hay un archivo [id_rsa.pub] en .ssh, la clave creada se almacena aquí, pero no se puede abrir haciendo doble clic,

imagen-20230720142946458

Use la línea de comando de Windows para ingresar el .ssh en

imagen-20230720143006885

Use el comando [more id_rsa.pub] para obtener el contenido, la siguiente cadena es su clave (puede copiarla).

imagen-20230720143020001

Agregar clave en Git

1) Pegue la clave que acaba de copiar en el cuadro [Clave pública], y usted mismo podrá crear el título.

Supongo que te gusta

Origin blog.csdn.net/gjb760662328/article/details/131840450
Recomendado
Clasificación