J'ai un référentiel Git dans lequel tout mon code est dans la branche principale, et j'ignorais auparavant tous les fichiers Drupal, de sorte que je gardais une séparation stricte entre le code que j'ai écrit (ou modifié ou pourrait modifier) et le code qui pourrait être généré avec Drush ou autre.
Cela semblait être une bonne stratégie jusqu'à ce que je doive mettre à jour Drupal. J'ai réalisé que je voulais pouvoir revenir en arrière si les choses allaient mal, et quel meilleur outil à utiliser que Git pour le faire. Je me suis dit que ce serait la situation parfaite pour une branche de fonctionnalité, alors j'ai créé une drupal-7.14branche, lui ai donné la sienne .gitignorepour ignorer tous mes fichiers de code et de paramètres et faire attention aux seuls fichiers qui font partie de l'installation Drupal que je ne voudrais pas. t toucher. J'ai fait une mise à niveau à la main (télécharger, décompresser, décompresser, copier), triant les cas limites comme robots.txt et .htaccess, et écrasant le .gitignore de Drupal avec le mien. J'ai corrigé certains paramètres qui fonctionnaient avec 7.14 mais pas avec 7.15, pour récupérer d'une erreur 500, puis tout semblait parfait. J'ai renommé la succursale drupal-7.15et j'allais continuer mon chemin avec bonheur.
Jusqu'à ce que je réalise ce que j'avais fait par inadvertance: les fichiers qui n'étaient pas suivis auparavant par ma branche principale mais laissés dans le répertoire de travail étaient maintenant supprimés du répertoire de travail lorsque j'ai extrait master, car ils n'étaient plus des fichiers non suivis! Oh!
Si je fusionne la drupal-7.15branche avec master, je perdrai la séparation du code.
Il existe probablement un moyen de convertir une branche en sous-module. En supposant que c'est possible, cela pourrait être la meilleure stratégie. Je savais avant de faire cela que les sous-modules étaient la «bonne» solution, mais comme je ne me rendais pas compte de l'effet secondaire de l'utilisation de branches pour des fichiers non suivis auparavant, j'ai décidé de couper les coins ronds et de suivre cette voie. (De plus, toutes les approches que j'ai vues pour utiliser des sous-modules avec Drupal supposent que vous démarrez un nouveau projet et Drupal sera la branche principale. Il n'est pas souhaitable pour moi de faire du code de quelqu'un d'autre la branche principale, et j'avais déjà un repo avec une branche master. Il semblait que ce serait inutilement compliqué juste de faire une mise à jour.)
Il y a peut-être une autre solution à laquelle je n'ai pas pensé.
Comment puis-je m'en remettre au mieux avec le moins d'inconvénients possibles?
MISE À JOUR : Ceci est en cours de développement (dans une machine virtuelle Linux sur mon ordinateur portable) et n'est pas encore en production. Au moment où nous irons en production, je prévois de tout emballer dans des modules de fonctionnalités, mais ce n'est pas encore en place.
MISE À JOUR 2 : Les sous - modules peuvent ne pas fonctionner. Selon Pro Git , "les sous-modules vous permettent de conserver un référentiel Git en tant que sous-répertoire d'un autre référentiel Git". Drupal n'offre pas une séparation aussi agréable. Au lieu que tout le code Drupal soit dans un sous-répertoire, la relation est plus ou moins inversée, mais il n'y a toujours pas de séparation nette, car vous pouvez modifier votre .htaccess et robots.txt, donc votre code et le dépôt Drupal sont mélangés. Je recherche une solution à ce problème .