Version control
  • Structure your Git repository with at least three branches, being one master, one for development and one for tests. You can also have a different branch for production.
  • Changes should always be done on the branch "develop", and later moved to the branch “test".
  • It’s also interesting to work with tags to control releases, which can be major, minor or patches. In this scenario, for each release the branch master can be updated and a tag for that release can be created.
  • If there are multiple people working on the project, it’s more interesting to work with pull requests to the develop branch, instead of having everyone working on the same branch. This will avoid conflicts and unnecessary merge requests.
  • For future releases of eDirectory, it’s possible to create a different repository with the latest version, add it as a remote repository on the existing repository, and merge it to the development branch. Manual conflicts solving will be probably necessary.
  • Try to describe your commits with short and accurate messages. It’s also interesting to avoid one commit with a long list of changes. Several smaller commits are better and might be helpful on the future to investigate possible issues.
  • Be careful with files that should not be committed. Remember to keep your gitignore file updated.
  • For layout changes on the frontend, duplicate the twig file on the folder app/Resources/custom, following the folder structure from the original folder. The system will automatically load this new file instead of the original one on the theme folder. This practice will be helpful to avoid conflicts and tricky merges on future upgrades.
  • Every change on the database should be done using Migrations (first you change the entity, generate a migration and execute it). Do not make any change directly on the database.
  • Be careful with changes on files that are ignored, and only their “sample/dist” version are versioned. (Htaccess for example).
  • Be careful with changes on the htaccess files.
  • Third-party libraries should be always loaded using Composer.
  • Don’t make changes on the folder vendor.
  • Be careful upgrading any of the system requirements (PHP and it’s packages, MySQL, Elasticsearch and third-party libraries loaded via Composer.

For more details please chech the PDF file attached.