Je suis nouveau à la fois dans git et dans le contrôle de version, donc j'essaie de comprendre ce qu'est un patch et en quoi est-il différent du reste des activités que je fais dans git?
Quand dois-je appliquer un patch? Cela arrive-t-il à chaque fois que je m'engage?
Réponses:
Vous pouvez voir dans cet article de blog comment créer un correctif (collection de modifications que vous souhaitez communiquer et appliquer à un autre dépôt)
(photo du billet de blog 2008 " Bioruby with git: comment ça marche? ", publié par Jan AERTS )
Voir aussi Contribuer aux rails avec Git comme autre exemple concret.
De nos jours, la requête d'extraction GitHub facilite grandement application de correctifs sur les dépôts GitHub, ce qui est utile lorsque vous n'êtes pas un contributeur direct (c'est-à-dire que vous n'avez pas le droit de pousser directement vers un dépôt).
En fait, assez récemment, GitHub a introduit " Better Pull Request Emails " pour améliorer la notification des nouveaux correctifs.
Patch est un programme Unix qui met à jour les fichiers texte selon les instructions contenues dans un fichier séparé, appelé fichier patch.
Donc, en d'autres termes, cela peut signifier le fichier avec des instructions ou un programme qui traite ce fichier et l'applique à quelque chose.
Maintenant, qu'est-ce qu'un fichier patch? Disons que vous avez un fichier texte avec 2 lignes:
This is line A.
This is line B, or otherwise #2.
Ensuite, vous modifiez la première ligne, et maintenant votre fichier ressemble à ceci:
This is SPARTA.
This is line B, or otherwise #2.
Comment décririez-vous la modification du contenu du fichier? Vous pouvez dire que la première ligne "Ceci est la ligne A." a été remplacé par "Ceci est SPARTA.", ou même le dernier mot "A" de la première ligne remplacé par un autre mot "SPARTA". Et c'est exactement ce que diff nous dit. Disons que j'ai deux versions de ce fichier, une appelée file1.txt et une autre file2.txt, puis je lance diff et obtient ceci:
$ diff -u file1.txt file2.txt
--- file1.txt 2011-11-26 11:07:03.131010360 -0500
+++ file2.txt 2011-11-26 11:07:13.171010362 -0500
@@ -1,2 +1,2 @@
-This is line A.
+This is SPARTA.
This is line B, or otherwise #2.
Ayant une description des modifications, vous pouvez l'appliquer à un contenu initial et obtenir un contenu modifié. Et ces changements, mis dans un format unifié que les programmes de type «patch» peuvent comprendre, s'appellent un fichier de patch. C'est comme au lieu d'obtenir un poisson de quelqu'un, ils vous apprennent à pêcher, afin que vous puissiez creuser vous-même ce poisson hors des eaux. Maintenant, appliquons notre patch à file1.txt pour le faire ressembler exactement à file2.txt:
$ cat file1.txt
This is line A.
This is line B, or otherwise #2.
$ cat file2.txt
This is SPARTA.
This is line B, or otherwise #2.
$ diff -u file1.txt file2.txt > changes.patch
$ cat changes.patch
--- file1.txt 2011-11-26 11:09:38.651010370 -0500
+++ file2.txt 2011-11-26 11:07:13.171010362 -0500
@@ -1,2 +1,2 @@
-This is line A.
+This is SPARTA.
This is line B, or otherwise #2.
$ patch < changes.patch
patching file file1.txt
$ cat file1.txt
This is SPARTA.
This is line B, or otherwise #2.
$
Vous pensez peut-être qu'il est plus facile de n'avoir que deux versions de ce fichier. Eh bien, dans ce cas simple, c'est vrai. Mais lorsque vous avez beaucoup de fichiers et que ces fichiers sont très volumineux, il est beaucoup plus efficace d'avoir quelques lignes de modifications plutôt que deux copies de l'ensemble.
En termes de git, le fichier patch signifie toujours la même chose, mais utiliser diff + patch vous-même serait un cauchemar. Par exemple, vous devrez toujours extraire deux versions du fichier (ou même l'ensemble du référentiel) afin de les comparer. Ça ne sonne pas si bien, n'est-ce pas? Donc git s'occupe de tout le travail dur pour vous - il compare votre fichier local avec ce qui se trouve dans le référentiel avec lequel vous travaillez, et peut vous le montrer comme un "diff", ou appliquer ce "diff" comme un patch aka validez vos modifications, ou vous permet même d'appliquer un fichier de correctif que vous avez déjà. Sans entrer dans les détails, en ce sens, git est absolument le même que d'autres systèmes de contrôle de version comme SVN, ou même CVS ou perforce.
J'espère que ça aide!
patchprogramme intégré . Je pensais que git avait sa propre implémentation.
Un correctif est un petit fichier qui indique les modifications apportées dans un référentiel. Il est généralement utilisé lorsqu'une personne extérieure à votre équipe dispose d'un accès en lecture seule mais dispose d'un bon changement de code. Il crée ensuite un patch et vous l'envoie. Vous l'appliquez et le poussez vers le référentiel git. Tout le monde profite alors de la version mise à jour et l'auteur du patch n'a pas besoin d'un accès en lecture / écriture.
C'est vraiment principalement une question de sécurité (du moins, c'est pour cela que les gens l'utilisent).
git diffaffiche les modifications sous forme de correctifs par défaut, git applyvous permet d'appliquer un correctif, etc.).
Un fichier de correctif représente un ensemble unique de modifications qui peuvent être appliquées à n'importe quelle branche, dans n'importe quel ordre. En utilisant patch, vous obtiendrez des différences entre un ou plusieurs fichiers. Et plus tard, vous pouvez appliquer les différences (patch) pour obtenir les modifications sur les nouveaux fichiers. Il existe de nombreuses utilisations d'un patch dans Git. Si vous avez des modifications non validées dans votre répertoire de travail et que vous avez besoin de les appliquer ailleurs, créez simplement un patch et appliquez le patch.
git diff > mypatch.patch
Si vous avez de nouveaux fichiers dans votre référentiel (non suivis), vous devez alors préparer le fichier avant de créer un correctif (ne pas valider) et utiliser la commande suivante
git diff --cached > mypatch.patch
Vous pourrez ensuite appliquer le patch:
git apply mypatch.patch
Si vous souhaitez apporter des modifications à un référentiel git, que vous n'avez pas d'autorisation d'écriture, apportez simplement les modifications et créez un patch entre les deux, et envoyez le patch à quelqu'un qui a l'autorisation d'appliquer le patch, par ceci vos modifications doivent être ajoutées à ce référentiel git.
git format-patch <base_commit_or_branch_name>= encapsulez tous les commits à partir de maintenant vers <base_commit_or_branch_name> dans des fichiers agréables et soignés contenant le diff ainsi que les messages de commit, pour un envoi facile (ex: par e-mail) à quelqu'un d'autre qui veut les patcher leur base de code. Ensuite, le destinataire corrige son système avec votre fichier:cat *.patch | git am
Un patch est un ensemble de différences entre un ou plusieurs fichiers, pour montrer ce qui est différent entre eux. Vous ne générez généralement un patch que pour montrer à quelqu'un ce que vous avez changé. Un exemple de cas où vous pourriez faire cela est lorsque vous trouvez et corrigez un bogue dans une application open source, puis publiez le correctif sur leur outil de suivi des bogues.