La guia de platanus
  • README
  • Acuerdos
    • Guía de Estilo
      • Ejemplo: Módulo para variables de entorno
  • Stack
    • Getting Started
    • Nuestro MVC extendido
    • Ruby/Rails
      • Power Types
        • General
        • Patrones
          • Commands
          • Utils
          • Services
          • Values
          • Observers
      • Potassium
      • Power API
      • Active Admin
        • General
        • Active Admin Addons
      • Pundit
      • Shrine
        • General
        • Manejo y procesamiento de imágenes
      • Pry
      • Strong Migrations
      • Data Migrate
      • Active Job
      • Gems
      • Engines - Modularización en Rails
    • JavaScript
      • Vue
        • General
        • Testing
      • AlpineJS
    • CSS
    • Mobile
      • Expo
      • React Navigation
      • Redux
        • Crear y conectar una slice en Redux
      • Styling
        • Usando Tailwind en React Native
      • Recursos
    • Resolviendo problemas (debugging)
    • Machine Learning
  • Setup
    • Configuración de tu entorno local
      • Instalación Base
        • OSX
        • Windows
        • Linux
      • Tecnologías
        • Ruby
        • Docker
        • Node
      • Herramientas
        • Linters
        • Editores
          • IDE/Editores de Código
            • Visual Studio Code
            • Sublime Text
        • Git
    • Configuración de proyectos
      • Getting Started
      • Heroku
      • Rails
      • Circle CI
      • Vue
      • Apple App Store
      • Google Play
      • Expo
      • S3
      • Git
      • Cloudflare
      • Sendgrid
      • Dominio + Mailing
      • Google Tag Manager, Analytics, Search Console, etc.
        • Google Tag Manager
          • Configurar Google Tag Manager
        • Google Analytics
        • Indexación en Google
        • Google Ads
      • Crear un bucket de S3
      • SlackBot
      • Google BigQuery
  • Deployment
    • Rails
    • Ruby Gems
    • Browser and Node (Open Source)
    • Mobile
      • Mobile Resources
      • Apple App Storage
      • Google Play
  • Upgrades
    • Upgrade de Vue 2 a Vue 3
    • Migración Hound → reviewdog
    • Upgrade de Postgresql
Con tecnología de GitBook
En esta página
  • Commits
  • Tipo
  • Contexto
  • Descripción
  • Branches y Pull-requests
  • Ejemplo
  • Rebase
  1. Setup
  2. Configuración de proyectos

Git

AnteriorS3SiguienteCloudflare

Última actualización hace 1 año

Utilizamos para el control de versiones junto con

Commits

Los mensajes de commit:

  • siempre los hacemos en inglés

  • normalmente tienen una sola línea (aunque sabemos que más podría ser mejor)

  • la primera línea se forma de un tipo, un contexto y una descripción

    tipo(contexto): descripción

La línea no debiera tener más de 100 caracteres para que se lea bien en Github.

Tipo

El tipo nos ayuda a clasificar los commits. Los tipos que usamos son:

  • feat: Un nuevo feature

  • fix: La corrección de un bug

  • docs: Cambios en la documentación

  • style: Cambios que no afectan el significado del código (espacios, indentación, etc.)

  • refactor: Un cambio en el código que no agrega una funcionalidad ni corrige un bug

  • perf Cambios en el código que sólo mejoran la performance

  • test: Agrega, corrige o tests

  • chore: Cambios al proceso de build y herramientas auxiliares

Contexto

El contexto es una palabra que hace referencia al lugar del código o funcionalidad que afecta el commit. Debe escribirse usando kebab-case, por ejemplo: user-signup

De manera opcional, se puede agregar información sobre el componente específico del código afectado. Si se agrega esta información:

  • Debe ir después del contexto, separado usando un slash (/). Por ejemplo: api/LoginService

  • El nombre del componente modificado debe estar en el mismo formato en el que aparece en el código (por ejemplo en CamelCase si es una clase ruby).

Descripción

  • usamos el verbo imperativo en inglés: "change" no "changed" ni "changes"

  • separado por un espacio del contexto

  • sin mayúscula al principio

  • sin punto (.) al final

Branches y Pull-requests

Los features los hacemos en un nuevo branch y hacemos un pull-request hacia master.k

Ejemplo

Como ejemplo de estas recomendaciones el siguiente commit soluciona un bug en el componente/clase SignUpForm del frontend de una aplicación, en el cual no se estaba entregando feedback de la validación sobre si el nombre de usuario estaba disponible o no:

fix(ui/SignUpForm): validate username availability

The `SignUpForm` component wasn´t validating the availability of the `username` field and only displayed a `couldn´t create account` error on submit.

This commit adds an asynchronous validation when typing on the field so the user will know if the username is available before completing further fields.

Rebase

Nota: Esto es un extracto/traducción de , que es más completo, pero que por el momento no es una práctica que sigamos completamente en Platanus

Para ordenar un poco los commits, usamos fixups y rebase. puedes leer sobre rebase y cómo lo usamos para mantener la historia limpia. También revisa sobre fixup, otra herramienta del rebase que usamos para esto.

git
github
este documento
En este post de nuestro blog
este post