|
|
|
# Todo gestionado por GIT - Bitbucket
|
|
|
|
|
|
|
|
La herramienta Bitbucket nos permite gestionar diferentes ramas desde la rama principal llamada Main, la cual contiene el proyecto en su estado final con sus diferentes versiones. En la imagen, podemos observar un ejemplo que parte desde la versión v0.1 y continúa hasta la última versión mejorada v1.0.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Estás ramas nos permiten llevar un control de código de versiones, para que las nuevas actualizaciones no afecten los elementos funcionales de la rama principal.
|
|
|
|
|
|
|
|
## Tipos de ramas
|
|
|
|
|
|
|
|
**Main**: Rama principal que contiene las diferentes versiones del proyecto. En esta rama NO se desarrolla el código, sólo contiene los elementos finalizados.
|
|
|
|
|
|
|
|
|
|
|
|
**Develop**: Se crea desde la rama Main, contiene el código de desarrollo de la siguiente versión planificada.
|
|
|
|
|
|
|
|
|
|
|
|
**Hotfix**: Cuando se detecta un error o bug en la rama Master, se genera una rama tipo Hotfix, realizando un guardado del error. Una vez corregido este error se realiza un “Pull Request”, para revisar el desarrollo con el equipo de trabajo y luego un merge que permitirá unir el código a la rama principal Main y generar una nueva versión. (Revisaremos mayor detalle de “Pull Request” y merge en el punto 6 de la sección “Comandos GIT para el uso de ramas” )
|
|
|
|
|
|
|
|
|
|
|
|
**Release**: Se genera a partir de la rama Develop. Nos permite estandarizar o cortar una serie de código que ha estado desarrollándose, para luego depurar y realizar un respectivo “Pull Request” y luego un merge a la rama principal Main con una nueva versión.
|
|
|
|
|
|
|
|
|
|
|
|
**Feature**: Cuando se genera una nueva característica o requisito para nuestro proyecto en el desarrollo de una rama tipo Develop, se genera una rama tipo Feature, que permite trabajar en estos nuevos requerimientos sin afectar lo desarrollado en la rama Develop.
|
|
|
|
|
|
|
|
|
|
|
|
## Comandos GIT para el uso de ramas
|
|
|
|
|
|
|
|
**1. Creación de ramas**
|
|
|
|
|
|
|
|
Para la creación de una rama específica se ejecuta el siguiente comando:
|
|
|
|
|
|
|
|
- ```git checkout -b [nombre_de_rama]```
|
|
|
|
|
|
|
|
|
|
|
|
Ejemplos :
|
|
|
|
- ```git checkout -b feature/nombre-nueva-funcionalidad```
|
|
|
|
- ```git checkout -b hotfix/descripción-del-error```
|
|
|
|
- ```git checkout -b feature/solución-del-error```
|
|
|
|
|
|
|
|
**2. Guardado de archivos localmente**
|
|
|
|
|
|
|
|
Para guardar un nuevo archivo o una actualización de un archivo localmente, se ejecuta el siguiente comando:
|
|
|
|
|
|
|
|
```git add [nombre_de_archivo.extensión]```
|
|
|
|
|
|
|
|
Ejemplo :
|
|
|
|
```git add benchmarks.rb```
|
|
|
|
|
|
|
|
**3. Preparando el archivo a subir con “commit”**
|
|
|
|
|
|
|
|
Luego de realizar un guardado de un archivo localmente, es importante realizar un commit antes de realizar un pull hacia una rama.
|
|
|
|
|
|
|
|
```git commit -m "[descripción_de_lo_realizado]"```
|
|
|
|
|
|
|
|
|
|
|
|
Ejemplo :
|
|
|
|
- ```git commit -m "Configura múltiples roles"```
|
|
|
|
- ```git commit -m "Añade funcionalidad de Geoprocesos"```
|
|
|
|
|
|
|
|
|
|
|
|
**Algunas buenas prácticas del commit:**
|
|
|
|
1. Escribir el mensaje en imperativo.
|
|
|
|
|
|
|
|
2. No uses punto final ni puntos suspensivos en tus mensajes.
|
|
|
|
|
|
|
|
3. Usa máximo 50 carácteres para tu mensaje de commit.
|
|
|
|
4. Añade todo el contexto que sea necesario en el cuerpo del mensaje, asegúrate de agregar la información necesaria.
|
|
|
|
5. Inicia con mayúsculas los títulos y cada párrafo del mensaje.
|
|
|
|
6. Especifica el tipo de commit:
|
|
|
|
- **feat**: Nueva característica que agregas a una aplicación en particular.
|
|
|
|
- **fix**: Un parche para un error.
|
|
|
|
- **style**: Características o actualizaciones relacionadas con estilos.
|
|
|
|
- **refactor**: Refactorizar una sección específica de la base de código.
|
|
|
|
- **test**: Todo lo relacionado con pruebas.
|
|
|
|
- **docs**: Todo lo relacionado con documentación.
|
|
|
|
- **chore**: Mantenimiento de código regular.
|
|
|
|
7. **Sigue la convención del mensaje commit definida por tu equipo.**
|
|
|
|
|
|
|
|
**4. Subiendo cambios a una rama**
|
|
|
|
|
|
|
|
Luego de agregar los cambios y realizar el commit correspondiente, se está listo para subir los cambios a una rama, para ello ejecutamos:
|
|
|
|
```git push origin [nombre_de_rama]```
|
|
|
|
|
|
|
|
|
|
|
|
Ejemplo:
|
|
|
|
```git push origin feature/responsive-menu```
|
|
|
|
|
|
|
|
**5. Actualizando nuestro repositorio local**
|
|
|
|
|
|
|
|
Para poder descargar y actualizar el contenido de una rama específica en el repositorio local, se realiza el siguiente comando:
|
|
|
|
```git pull origin [nombre_de_rama]```
|
|
|
|
|
|
|
|
|
|
|
|
Ejemplo:
|
|
|
|
```git pull origin hotfix/problema-al-servir-capas```
|
|
|
|
|
|
|
|
**6. Fusión de ramas con git merge**
|
|
|
|
|
|
|
|
Antes de realizar una fusión de ramas, es importante para el equipo realizar una revisión de la funcionalidad realizada. Para ello se realiza un “Pull Request” con Bitbucket, que permitirá crear una solicitud de incorporación de cambios, para luego combinar las ramas.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Para saber cómo realizar esta acción, revisa la sección “Envía el cambio y crea una solicitud de incorporación de cambios” de la documentación oficial de Bitbucket.
|
|
|
|
Una vez que la instancia ha sido revisada, otra forma de realizar la fusión de la rama actual, con una rama específica, es con el siguiente comando:
|
|
|
|
|
|
|
|
- ```git merge [nombre_de_rama]```
|
|
|
|
|
|
|
|
|
|
|
|
Ejemplo:
|
|
|
|
- ```git merge feature/banner```
|
|
|
|
|
|
|
|
**7. Otros comandos útiles**
|
|
|
|
|
|
|
|
Para descargar el código fuente desde un repositorio remoto, se obtiene el comando a ejecutar a través del botón Clone desde Bitbucket.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Para revisar cuál es la rama actual, realizar el comando ```git branch```, donde se observa marcada con un *(asterístico) la rama que se está utilizando.
|
|
|
|
- Ejemplo:
|
|
|
|
```$ git branch main * feature hotfix```
|
|
|
|
|
|
|
|
Para moverse a una rama específica, utilizar el comando ```checkout```.
|
|
|
|
```git checkout [nombre_de_rama]```
|
|
|
|
|
|
|
|
|
|
|
|
Para conocer el estado de la rama actual, se ejecutar:
|
|
|
|
```git status```
|
|
|
|
|
|
|
|
|
|
|
|
- Se observará si la rama está actualizada
|
|
|
|
|
|
|
|
- Si existe algún cambio para confirmar, enviar o recibir
|
|
|
|
- Si existen archivos en preparación, sin preparación o que no están recibiendo seguimiento
|
|
|
|
- Si existen archivos creados, modificados o eliminados
|
|
|
|
|
|
|
|
## Buenas prácticas con Laravel
|
|
|
|
|
|
|
|
A continuación se indican buenas prácticas de codificación con Laravel, que facilitan la tarea a la hora de trabajar en forma colaborativa. Es importante manejar éstas prácticas para programar código limpio y eficiente que nos ayudará a reducir o eliminar errores de compatibilidad entre las diferentes etapas del desarrollo del proyecto.
|
|
|
|
|
|
|
|
1. Utiliza la convención de nomenclatura de [Laravel PSR](https://www.php-fig.org/psr/psr-2/).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2. Una clase y un método sólo deben ser responsables de una responsabilidad.
|
|
|
|
- Ejemplos:
|
|
|
|
```
|
|
|
|
public function getFullNameAttribute()
|
|
|
|
{
|
|
|
|
return $this->isVerifiedClient() ? $this->getFullNameLong() : $this->getFullNameShort();
|
|
|
|
}
|
|
|
|
|
|
|
|
public function isVerfiedClient()
|
|
|
|
{
|
|
|
|
return auth()->user() && auth()->user()->hasRole('client') && auth()->user()->isVerified();
|
|
|
|
}
|
|
|
|
|
|
|
|
public function getFullNameShort()
|
|
|
|
{
|
|
|
|
return $this->first_name[0] . '. ' . $this->last_name;
|
|
|
|
}
|
|
|
|
```
|
|
|
|
|
|
|
|
3. Todos los modelos creados deben llevar atributo $table.
|
|
|
|
- Ejemplo:
|
|
|
|
```protected $table = 'usuarios_biosoft';```
|
|
|
|
|
|
|
|
|
|
|
|
4. Ser lo más explícito posible al momento de declarar relaciones dentro de los modelos, incluir todas las llaves foráneas y locales
|
|
|
|
.
|
|
|
|
5. Toda traducción debe usarse desde el directorio lang.
|
|
|
|
6. Intenta separar la lógica en controladores, evita tener controladores grandes.
|
|
|
|
7. Revisa la documentación de [Laravel & PHP](https://spatie.be/guidelines/laravel-php) para mayor información.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
