Git Workflow pour garder à jour les logiciels open source modifiés personnalisés?

Question

Notre université fournit un hébergement Web aux départements du campus sur les serveurs que nous gérons. L'installation de programmes tiers en open source nécessite de modifier les autorisations de fichiers et le code dans le programme avant son exécution. (Nous utilisons SUEXEC, si vous êtes familier.)

Nous proposons actuellement WordPress via un script d'installation. L'utilisateur télécharge la nouvelle version stable et exécute un script PHP côté serveur via SSH. Ce script PHP modifie les autorisations de fichiers de tous les fichiers / dossiers, Ajoute / supprime du code dans divers fichiers et crée quelques nouveaux fichiers. Ce script d'installation est un acte d'équilibrage lourd lorsqu'une nouvelle version stable est publiée.

Je souhaite commencer à utiliser le contrôle de version (spécifiquement GIT) pour suivre nos modifications personnalisées au lieu de compter sur un script pour apporter les modifications, mais je ne suis pas sûr du flux de travail à utiliser. Je connais la ramification et la fusion, mais je ne sais pas comment intégrer nos anciens changements lorsqu'une nouvelle version est publiée.

Que devrait être mon flux de travail GIT pour intégrer les nouveaux changements du noyau WordPress, mais également préserver nos anciens changements personnalisés?

Answer 1

Je suggère de garder vos changements dans une branche et de reprendre cette branche contre le dernier de WordPress chaque fois que vous mettez à jour. Dans une chronologie approximative ...

              +-- WordPress 1.0
              v
[master] --*--*
               \
[custom]        *--*--*     <- your customizations

Lorsque vous souhaitez mettre à jour WordPress, passez à Master et faites un nouvel engagement avec le dernier SOUCE (ou utilisez Git-Svn pour garder Master en synchronisation):

              +-- WordPress 1.0
              |     +-- WordPress 1.1
              v     v
[master] --*--*--*--* 
               \
[custom]        *--*--*     <- your customizations

Maintenant, vous pouvez faire un git rebase master custom Pour rejouer vos modifications contre les dernières personnes, résolvant tout conflit en cours de route. Votre chronologie ressemblerait alors à ceci:

              +-- WordPress 1.0
              |     +-- WordPress 1.1
              v     v
[master] --*--*--*--* 
                     \
[custom]              *--*--*     <- your customizations

Mise à jour: Pour fournir un peu de justification ... j'aime cette approche pour ce problème car elle fournit une différenciation claire entre le code de WordPress et vos personnalisations. Lorsque vous obtenez une nouvelle version de WordPress, vous n'êtes vraiment pas intéressé par "l'intégration". Vous souhaitez réappliquer vos personnalisations à la nouvelle version de WordPress. À mon avis, cette maîtresse est la plus facile à combler par engagement par une rebase. Tous les conflits signifient qu'une personnalisation est probablement cassée, donc l'ancien engagement de personnalisation est de toute façon - mieux vaut simplement résoudre le problème à sa source et garder l'historique mis à jour propre.

Après master est mis à jour et custom est repoussé et poussé, les collaborateurs réprimanderaient leur travail en cours contre les derniers.

Ce n'est que mon opinion, en tant que promotion de fusion de rébase>. La beauté de Git est qu'il y a rarement une bonne réponse. Continuez simplement à vous ajuster jusqu'à ce que vous trouviez quelque chose qui fonctionne pour vous.

Answer 2

Mon approche générale est d'avoir deux branches, upstream et master. Créez votre référentiel (qui vous commencera dans le master branche), vérifiez la dernière copie du code en amont que vous utilisez, puis créez le upsteram se ramifier avec git branch upstream. Créez également une balise indiquant la version en amont que vous avez importée, comme git tag wordpress-1.0. J'utilise généralement des balises légères pour cela (celles sans annotations, juste un pointeur vers une révision).

[wordpress-1.0]               Key: [tag]
v                                  branch
* <- upstream                      * commit
^- master 

Maintenant, pendant que vous êtes toujours dans le master branchez, copiez vos modifications et vérifiez-les. Vous avez maintenant deux branches, upstream qui contient la source en amont vierge, et master qui contient vos modifications, l'histoire montrant les modifications que vous avez apportées upstream.

[wordpress-1.0]
v
* <- upstream
 \
  +--* <- master 

Apporter toutes vos modifications dans le master bifurquer.

[wordpress-1.0]
v
* <- upstream
 \
  +--*--*--* <- master 

Lorsqu'une nouvelle version du code en amont arrive, consultez votre upstream bifurquer (git checkout upstream), efface tout sauf le .git Répertoire et copier dans la nouvelle version en amont. Utilisation git add -A Pour mettre en scène tous les changements dans la version en amont, commettez-le et étiquetez-le.

[wordpress-1.0]
|  [wordpress-1.1]
v  v
*--* <- upstream
 \
  +--*--*--* <- master 

Maintenant, découvrez master, et fusionner dans vos changements en amont. À ce stade, vous pouvez choisir comment fusionner, comme prendre la nouvelle version en amont, prendre votre version ou prendre des changements fusionnés, tout comme vous le faites dans une fusion normale.

[wordpress-1.0]
|  [wordpress-1.1]
v  v
*--*--------+ <- upstream
 \           \
  +--*--*--*--* <- master 

Donc, tous vos modifications se produisent sur master, et toutes les versions en amont sont engagées exactement telles quelles upstream. Cela vous permettra de voir le plus facilement exactement comment votre code diffère de la version en amont, cela aidera à suivre les modifications que vous avez déjà fusionnées avec la version en amont, etc.

[wordpress-1.0]
|  [wordpress-1.1]
|  |           [wordpress-2.0]
v  v           v
*--*--------+--*-+ <- upstream
 \           \    \ 
  +--*--*--*--*----*--* <- master 

J'espère que cela aide, faites-moi savoir si vous avez d'autres questions.