Skip to content

Archivo Trans

Git Workflow

Commiting code

Overview

We are using master branch as our base branch. So we create our PR’s against that branch.

  1. Make your code changes.

  2. If besides code you are adding config changes, export your config.

1
lando drush cex

And remember to add config dir yml’s files to your commit.

1
git add config/sync
  1. Add files + create new branch + commit + push

always merge base branch in case there were changes!!

1
2
3
4
5
git pull origin master
git add path/to/changed/files
git checkout -b feature/AMT-123
git commit -m 'Mis cambios maravillosos en tal cosa'
git push origin feature/AMT-123
  1. Crear un pull request para la rama que acabás de pushear

  2. Agregar al menos una persona como reviewer

  3. Avisale a esa persona que chequeé sus mails :p

Some useful reminders

  • When committing code related to Composer packages (ie: adding a new drupal module, adding a composer patch, etc…) remember to always add your composer.lock file to the commit.

  • Remember to always merge your branch with the base branch from origin to get the latest changes and avoid merge conflicts :)

  • Remember that Devs are Humans capable to communicate, also, with other humans. Don’t forget that wonderful tool we have and if you have doubts or you can’t decide what to keep/discard when solving merge conflicts please please please share that with your work mates ;)

Branch Naming convention

The idea is to use feature and fix as keywords, so:

Change Type Branch Name example
New work feature/AMT-123
Hotfix fix/AMT-123

Important NOTE: Branch names must be short. Verify they do not exceed 25 chars.

Process

When your PR gets reviewed and approved that commit will trigger the automated-tests and build deployment process.

When that happens, you can check your chnages in Dev.

@todo: Could we add here a nice flow driagram to illustrate the entire deploy process ? :)