DEV Community: jesusfhohs

Git flow, feature branches :)

jesusfhohs — Thu, 21 Apr 2022 04:29:19 +0000

Hello! 😎 👽

Una vez dominando los términos generales de Git e aquí recomendaciones para trabajar con ramas, cabe mencionar que existen diferentes métodos para realizarlo...

Dependiendo de los ambientes que se tengan pueden ser:

Development (dev)
QA/Test (test)
Staging (staging)

Partiendo desde main o master.

Podemos iniciar ya sea con master o bien con main

Jesús Fonseca@DESKTOP-BD5A9L MINGW64 /c/ (main)
$ git branch
* main

(En este caso main será nuestra rama principal)

Creando nueva rama

Se pueden optar por 2 métodos uno:

git branch (nombre de la rama)

git branch feat-new-feature

y posteriormente pasar a la rama creada con git switch

git switch feat-new-feature

o bien crearla y pasar a la rama con un solo comando

git switch -c feat-new-feature
Switched to a new branch 'feat-new-feature'

Para saber en que rama te encuentras puedes checarlo con git branch, o bien si requieres conocer tus ramas remotas y locales con git branch -a

$ git branch -a
  main
* feat-new-feature
  remotes/origin/HEAD -> origin/main
  remotes/origin/main

Una vez que realices tus cambios en la rama creada es momento de subirlos a tu repositorio remoto

$ git status
On branch feat-new-feature
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)
        modified:   index.php
no changes added to commit (use "git add" and/or "git commit -a")

$ git commit -am "feature: rama de ejemplo"
[new-feature 94fb72d] feature: rama de ejemplo
 1 file changed, 1 insertion(+), 1 deletion(-)

(una vez teniendo tu commit listo solo es mandarlo a tu repositorio remoto, la primera vez tendrás que crear tu rama)
con git push --set-upstream origin (nombre-rama)

git push --set-upstream origin new-feature
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 4 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 302 bytes | 75.00 KiB/s, done.
Total 3 (delta 2), reused 0 (delta 0)

Ya sea que te encuentres en GitLab o Github, podras hacer (si ya finalizaste tus cambios y realizado la cantidad necesaria de commits) la unión de tu rama via Merge Request o Pull Request respectivamente.

Podrás agregar una descripción e incluso indicar que esa rama se borrará una vez aceptada la petición de unión.

Quien se encargue de realizar la revisión aceptará o bien dará observaciones para poder hacerlo.

Una vez unido y si la opción fue eliminar la rama los cambios se encontrarán en main

Notarán que ya está unida y la rama no existe en el remoto

Pero de manera local quedará así que... para borrar una rama de manera local, primero se debe de estar en una rama distinta

git switch main

Posteriormente se puede eliminar con el comando git branch -d (nombre de la rama)

git branch -d feat-new-feature

Notarás que si consultas tus ramas locales y remotas se podrán visualizar

git branch -a
* main
  remotes/origin/main
  remotes/origin/feat-new-feature

Así que para que se descarten las ramas que ya no son necesarias se puede ocupar el comando git remote prune origin

$ git remote prune origin
Pruning origin
URL: https://gitlab.com/tuusuario/tuproyecto.git
 * [pruned] origin/feat-new-feature

De esta manera quedará limpio con las ramas únicamente activas

$ git branch -a
* main
  remotes/origin/main

Convención de mensajes para tus commits en Git que puedes emplear en tu proyecto

jesusfhohs — Fri, 15 Oct 2021 00:46:00 +0000

Hello! ☺️ ✌️

Esta es una sugerencia de mensajes para tus commits en Git, basada en convenciones o estándares ocupados actualmente para llevar un mejor control y vista de los mismos, cabe destacar que a si mismo es un conjunto de diferentes fuentes, adecuado a mi experiencia de trabajo, de esta manera se puede navegar de una manera más fluida entre el historial de Git.

Formato del mensaje:

<type>(<scope>): <subject>
<body>
<footer>

Donde:

`<type>`

Es el tipo de commit que haremos, las descripciones recomendadas para este punto son:

feat: (feature) Se agrega una nueva característica ó se realiza alguna actualización a un feature que ya se había realizado y no necesariamente sea arreglar un bug
fix: Se corrige un bug
refactor: Refactorización
build: Cambios relacionados con dependencias a ocupar (como: npm related/ o dependencias externas o bien en caso de que se generen bundles de producción llevar el control de los archivos que cambien)
chore: Cambios que el usuario no verá, relacionados con configuraciones de git, o alguna herramienta que se esté ocupando en modo desarrollo (ejemplo: cambios a .gitignore o configuración en .prettierrc)
docs: Se hacen cambios a los archivos de documentación como al README
style: Principalmente cuando se realizan cambios de vista como formato, comas y puntos faltantes, etc. que no tenga cambios en el código.

`<scope> [opcional]`

`<subject>`

Preferentemente no debe contener mas de 50 caracteres, debe iniciar con una letra mayúscula y no terminar con un punto.

Se debe de ser imperativo al momento de redactar nuestro commit (como por ejemplo usar change en lugar de "changed" o "changes") y a su vez se tiene que ser objetivos en lo que se realiza con ese commit, posteriormente será mejor acostumbrarnos a escribirlos en Inglés esto sería una mejor práctica que podemos tener en nuestros commits.

`<body> [opcional]`

No todos los commits requieren de un cuerpo, por eso es opcional y se usan en caso de que el commit requiera una explicación amplia y/o contexto.

`<footer> [opcional]`

El pie también es opcional, pero este es usado para el seguimiento de los IDs con incidencias (Como de Jira o algún Id con referencia de un sprint asignado)

Ejemplo:

feat: Summarize changes, around 50 characters or less

Wrap it to about 72 characters or less

Closes #12

¿Cómo quedaría el commit haciéndolo en Git?

git commit -am "feat: Summarize changes, around 50 characters or less" -m "Wrap it to about 72 characters or less" -m "Closes #12"

(considerando que -am lo estoy usando por que se que mis archivos ya se encuentran en el stage)

En caso de ser un commit corto, sin body y no se requiere ser tan específico, pero si hacer la referencia al Id se podría poner de manera directa, algo como:

git commit -am "feat: Summarize changes, around 50 characters or less Closes #12"

🙋 Por ultimo, recomiendo no abusar del "git add ." cuando en todo caso se tiene que separar el commit, en algunas ocasiones tal vez puedas agregar al stage archivos en específico como:

git add  index.html example.hmtl

o tal vez se necesiten agregar todos los archivos js que se modificaron como:

git add js/*.js

(considerando obviamente que se agregarán los que están en la carpeta donde estás ubicado o la que se indique como en el ejemplo)

o tal vez se necesiten agregar un directorio completo:

git add css/

Para que de esta manera se tenga un mayor control en como realizamos nuestros commits.

Visualizando 👀👀

Para verlo de una manera más práctica, a través de un "git log" se pueden agregar características tales como "git log --graph", sin embargo aun sigue mostrándose información y espacios que tal vez al momento de visualizarlo no son necesarios dejo un formato que ocupo para visualizarlo de una manera más compacta:


git log --graph --abbrev-commit --decorate --format=format:'%C(bold blue)%h%C(reset) - %C(bold green)(%ar)%C(reset) %C(white)%s%C(reset) %C(dim blue)- %an%C(reset)%C(bold yellow)%d%C(reset)' --all

Al momento de mostrarlo da el resultado en una sola línea por commit

Pero, ¿Qué pasa si se requiere ver todo el mensaje tanto del body y footer, como en los ejemplos anteriores?, solamente cambiaremos dentro de nuestra instrucción "%s% por %B%

git log --graph --decorate --format=format:'%C(bold blue)%h%C(reset) - %C(bold green)(%ar)%C(reset) %C(white)%B %C(reset) %C(dim #29F914)- %an%C(reset)%C(bold yellow)%d%C(reset)' --all

Mostrando así el body completo de nuestro commit

Y bien... para no escribirlos o copiarlos y pegarlos siempre... les podemos agregar un alias en git para que así los consultemos rápidamente:

git config --global alias.lg "log --graph --abbrev-commit --decorate --format=format:'%C(bold blue)%h%C(reset) - %C(bold green)(%ar)%C(reset) %C(white)%s%C(reset) %C(dim blue)- %an%C(reset)%C(bold yellow)%d%C(reset)' --all"

git config --global alias.lgml "log --graph --decorate --format=format:'%C(bold blue)%h%C(reset) - %C(bold green)(%ar)%C(reset) %C(white)%B %C(reset) %C(blink cyan)- %an%C(reset)%C(bold yellow)%d%C(reset)' --all"

De esta manera los podemos ejecutar como "git lg" ó "git lgml" teniendo los mismos resultados respectivamente.

Extra

Configurar alias para git status

git config --global alias.s "status -sb"

De esta manera quedaría

git s

Referencias

Karma Git Commit Msg
Chris.beams
https://www.conventionalcommits.org/en/v1.0.0/
https://git-scm.com/docs/git-log