It is common for work teams that are not used to working simultaneously on the development of a Drupal project to end up constantly overwriting their code because they do not have a flow of publishing changes in a centralized environment.
Below we list the process we recommend for a publication flow:
Introduction
Let's assume that the team is working on the same branch because their work is on different components and they could have conflicts only at the configuration level.
In larger work teams, it is most likely that they will work on independent branches based on functionality, but in the end all these developments must converge to the same branch such as the master.
Required prior knowledge
- Drush.
- Composer.
- Git.
- Configuration management in Drupal.
Instructions
1. Export configurations.
We use Drush for this task, the files are exported to the directory defined in settings.php, usually in config/sync but it could be another one.
drush cex
2. Add the files to commit via Git.
With the following command add all the files that have changed in the directory from the directory where you are located, if you run it in the root folder of the repository you will be able to add all the files that have undergone changes such as the configurations or code that you have created or modified.
git add.
3. Committing files with Git.
At this point you have saved all the changes you have made, both configurations and code created or modified.
git commit -m ''
4. Bring changes from remote repository to local repository.
We must keep in mind that while we are working on our functionalities in our local environment, the team is also working on other tasks and it is very likely that we will coincide in the code files or configurations, so we must bring them to our local environment, so that we can identify these possible conflicts beforehand.
git pull origin
5. Conflict resolution if any.
As we mentioned in the previous step, it is very likely that when bringing changes we will encounter conflicts, this is the step to take care of that task, perhaps you already have experience in that task so just keep some tips in mind.
- Identify conflicting files.
- Analyze each case individually and make sure to thoroughly validate the changes you are going to accept.
- If you don't know whether or not to accept some code that isn't yours, contact the developer who built the lines you have conflicts with (if possible).
- Once the conflicts are resolved, if it took you a long time, you may want to consider doing a pull again to ensure that the latest remote changes do not have additional conflicts.
6. Execute any changes that Composer may have.
Except for rare cases, Composer is the method we use to install modules, libraries or patches. Since we have brought changes made by the team, it is very likely that they have used it, so it is best to get into the habit of always applying it in our environment after a <.
composer install
7. Installing the new configurations.
With the Git pull it is also very likely that we have brought new configurations that the team has worked on, it is very important that we import them into our local environment so that the next time we export configurations, they are included, if we do not do this, it is very likely that we will end up overwriting our colleagues' configurations with our outdated configurations.
This exercise will also be very useful to confirm that when the configurations are imported into the remote environment we will not encounter any unexpected surprises.
drush cim
8. Sending commits to repository and remote environment.
Now we are ready, we can confidently push our settings to the remote repository.
git push origin
9. Clear cache in local environment.
Drupal is a tool that works with the cache activated by default, it is likely that once you have completed all this task, it is better to clean the cache in case there are new directories that need to be read or information in the database that needs to be renewed .
drush cr
These steps that have been described solve most of the possible inconveniences when working on several functionalities at the same time, however, there could be scenarios where the error is caused by poor conflict resolution or lack of team communication.
Original contribution to the SeeD team by William Bautista.