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.
-
Make your code changes.
-
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 |
- 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 |
-
Crear un pull request para la rama que acabás de pushear
-
Agregar al menos una persona como reviewer
-
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.lockfile 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 ? :)