Comment appliquer les différences de validation Git à différents fichiers
Git est un puissant système de contrôle de version qui permet de multiples versions de branchement de votre projet avec fusion automatique. C’est très bien, mais parfois cela se brise lorsque les fichiers sont renommés ou ne sont pas au bon endroit. Heureusement, vous pouvez appliquer manuellement des correctifs à différents fichiers.
Le problème
Lors de l’utilisation de branches Git, il est souvent nécessaire d’appliquer les modifications d’une branche à l’autre. Un cas d’utilisation courant est celui des branches versionnées. Si vous disposez d’une ancienne version LTS, vous souhaiterez peut-être appliquer le correctif occasionnel à une ancienne version. Ou peut-être que vous fournissez deux versions de logiciels ciblant des chaînes d’outils ou des environnements différents et que vous devez les synchroniser.
Si vos branches ont la même disposition, vous pouvez utiliser git cherry-pick, qui peut copier des commits individuels d’une branche à une autre. Par exemple, extraire un commit d’une branche de fonctionnalité sur master avant que le tout ne soit fusionné :
EN RELATION: À quoi sert Git Cherry Pick et quand devriez-vous l’utiliser ?
Cependant, les logiciels ne sont pas toujours propres et, au cours du processus de refactorisation, vous pouvez rencontrer des cas où des fichiers ont été déplacés ou renommés. Git fonctionne à partir des chemins de répertoire, donc cela casse complètement git cherry-pick, car Git ne peut pas appliquer de modifications aux fichiers qui n’existent pas.
Git a des outils pour résoudre ce problème, donc lorsque la fusion normale échoue, vous pouvez manuellement corriger les fichiers avec les mises à jour en utilisant git patch.
Utilisation des différences et des correctifs Git
Pour montrer cela, nous allons créer un référentiel vide avec un seul fichier : Old.java. Une nouvelle succursale, old-version, est fait avec ce fichier, plus quelques modifications. Ce fichier est renommé avec quelques modifications ultérieures sur master branche à New.java, rompant la compatibilité entre les branches.
Et voici à quoi ressemble l’historique de la branche, montré dans le programme GUI Git Fork :
Dans cet exemple, nous devons déplacer le commit « Ajouter plus de code » sur le old-version branche. Pour ce faire, vous devrez obtenir l’ID de ce commit dans le journal de référence :
git reflog
Ensuite, exécutez format-patch avec la pièce d’identité et -1 flag, qui créera un fichier de correctif :
git format-patch 82176b5 -1
Cela générera un fichier de correctif dans le répertoire actuel. Vous voudrez peut-être le déplacer dans un autre dossier qui se trouve dans le .gitignore config, il n’est donc pas affecté par le changement de branches.
Ensuite, consultez le old-version branche, et appliquez les changements de correctif à l’aide de Linux patch utilitaire. Git a ses propres outils, git apply et git am, qui peut le gérer, mais à moins d’éditer manuellement le fichier de correctif, ils n’ont pas d’options pour modifier le fichier cible en cas de renommage/déplacement.
Vous pouvez passer le nom de fichier avec le -p1 paramètre et transmettez le fichier de correctif avec -i.
patch -l -p1 old -i Patches/0001-Add-more-code.patch
Cela devrait éditer le fichier et ajouter les modifications, que vous devrez valider. Un inconvénient de patch par rapport à git am c’est que cela ne préserve pas les informations de commit, bien que vous puissiez trouver cela dans le .patch fichier si vous souhaitez conserver le message d’origine.
Cependant, des conflits de fusion peuvent toujours se produire si la branche cible est modifiée entre-temps, et si c’est le cas, vous serez bloqué avec l’édition manuelle, car git merge ne peut pas résoudre ce problème pour vous. patch produira des fichiers contenant les différences, que vous devrez corriger manuellement.
Alternativement, vous pouvez déplacer le fichier cible vers le répertoire cible attendu par Git, permettant à Git de cherry-pick et appliquer les modifications. Ensuite, copiez le fichier à l’emplacement d’origine et supprimez le fichier temporaire.
Le correctif peut également avoir des problèmes avec les fins de saut de ligne (LF) par rapport au retour chariot (CRLF) qui peuvent résulter de l’édition Windows. Vous devrez peut-être passer à LF dans votre éditeur de texte pour que le correctif s’applique correctement.
