Pull request en GitLab son las merge request

En Git Lab podemos gestionar

• Proyectos
Repositorios de código(software)
Tiene dos subsecciones:
Activity: te ofrece toda la actividad, de una
manera estadística

Cycle Analytics: informa del tiempo que se
tarda en realizar una funcionalidad, desde que
tienes la idea hasta que se incorpora al software

Overview: listado de todo el proyecto. Te da el
resumen del repositorio, archivos, commits, etc.
○
"Files": donde se puede navegar por los
directorios y archivos, cuyo código podemos ver,
e incluso editar los ficheros. Está disponible una
visualización por ramas y dispone de utilidades
diversas para poder hacer cosas relacionadas
con el repositorio remoto, ahorrando la necesidad
de lanzar comandos. Tiene un buscador de
archivos muy potente.

"Commits": encontramos un listado de todos los
commits realizados contra el repositorio, junto
con datos específicos de cada uno de ellos.

Las ramas "Branches" sirven para ver las ramas
que tenemos en el repositorio

"Tags": es el mecanismo disponible en Git para
definir puntos del estado del código,
correspondientes a cada release.

"Locked files": permite bloquear un fichero para
que solo ciertas personas lo puedan editar.

Repository: Dentro de la sección "Repository"
tenemos varias opciones diversas que afectan al
repositorio del proyecto.
○
Issues: permite definir cualquier problema que se
detecta en el software y darle seguimiento. GitLab,
por medio de la gestión de las Issues, es capaz
actualizar el estado de las tareas, permitiendo
visualizar su evolución por medio de los tableros.
○
Merge Request: Son como las Pull Request de
GitHub. Te permiten controlar todas las solicitudes
de combinación o unión de código de distintas ramas
o forks. Es muy importante que los merges se
resuelvan mediante la interfaz gráfica, ya que nos
ofrece muchas posibilidades interesantes, como
automatización de tests, la posibilidad de revisión de
los cambios por parte de componentes del equipo,
implementar diversas políticas de control sobre el
código del proyecto, etc.
○
CI/CD: herramienta sencilla y muy útil para los
procesos de integración continua y despliegue
○
Dentro de los proyectos es donde están la mayoría de
funcionalidades
Resumen GitLab y GitFlow
jueves, 24 de febrero de 2022 11:53
GITLAB página 1
procesos de integración continua y despliegue
continuo.
○
Explicación TAGS
Se suelen utilizar para definir las versiones. El tag se debe
pushear hacia el origen y crea un release en gitlab
• Señalizadores
Crea un comprimido en GitLab para poder descargar
como esa versión de código
•
Funcionan de dos formas
GitFlow: es una forma de trabajo con ramas organizado
Gitflow es uno de esos flujos de trabajo y se basa en cinco
palabras clave durante la construcción de una aplicación y
sus respectivas entregas de valor.
Master
Es la rama principal de proyecto , donde va el código para
generar la aplicación en entornos de producción. Sobre ella
no se debería desarrollar.
Hotfix
Este tipo de rama se crea para la solución de un incidente.
Debe ser generada a partir de Master. También se relaciona
con el término “cambios en caliente”.
Hotfix se utiliza en ambientes en producción para resolver
incidentes.
Develop
En esta rama se tienen las nuevas funcionalidades de la
aplicación. No es aconsejable hacer commit (guardar
cambios) directamente sobre ella, excepto si son cambios
GITLAB página 2
cambios) directamente sobre ella, excepto si son cambios
pequeños y que no afecten la lógica, por ejemplo, cambiar
un texto.
Feature
Rama generada a partir de la rama develop. Sobre ella se
harán los desarrollos de nuevas funcionalidades. Una vez
esté desarrollada la funcionalidad la rama feature podrá ser
mezclada con Develop para que los cambios queden allí
sincronizados, y finalmente se procede a borrar la rama
feature. Es aconsejable tener esta rama sincronizada con los
cambios que se agreguen a la rama develop para evitar
conflictos.
Release
Esta rama utiliza para las entregas a producción o ambiente
real. Su propósito es habilitar que en ella se hagan las
pruebas del cliente y propender por la calidad de la entrega.
Una vez se termine con las pruebas y sean exitosas se
mezcla con la rama master. Y se sale a producción.
Es decir que esta rama se crea para hacer el release, y se
borra al tenerla integrada con Master.
Empresas y usuarios con sus permisos
Grupos
Pedazos de código que puedes dejar para hacer
cualquier cosa
Snippets