Disons que j'ai des modifications non validées dans mon répertoire de travail. Comment puis-je créer un patch à partir de ceux-ci sans avoir à créer de commit?
Disons que j'ai des modifications non validées dans mon répertoire de travail. Comment puis-je créer un patch à partir de ceux-ci sans avoir à créer de commit?
Réponses:
git diff
pour les modifications non mises en scène. git diff --cached
pour les changements par étapes.
git format-patch
comprend également des différences binaires et quelques méta-informations. En fait, ce serait le meilleur pari pour créer un patch, mais afaik, cela ne fonctionne que pour les sources / modifications enregistrées, non?
git diff --relative
Si vous n'avez pas encore validé les modifications, alors:
git diff > mypatch.patch
Mais parfois, il arrive qu'une partie des choses que vous faites sont de nouveaux fichiers qui ne sont pas suivis et ne seront pas dans votre git diff
sortie. Donc, une façon de faire un patch est de tout mettre en scène pour un nouveau commit ( git add
chaque fichier, ou juste git add .
) mais ne faites pas le commit, puis:
git diff --cached > mypatch.patch
Ajoutez l'option «binaire» si vous souhaitez ajouter des fichiers binaires au patch (par exemple des fichiers mp3):
git diff --cached --binary > mypatch.patch
Vous pouvez ensuite appliquer le patch:
git apply mypatch.patch
Remarque: Vous pouvez également utiliser --staged
comme synonyme de --cached
.
git diff --no-color
. Sinon, cela ressemble à un problème d'encodage.
git diff
et git apply
fonctionnera pour les fichiers texte, mais ne fonctionnera pas pour les fichiers binaires.
Vous pouvez facilement créer un patch binaire complet, mais vous devrez créer un commit temporaire. Une fois que vous avez effectué vos validations temporaires, vous pouvez créer le patch avec:
git format-patch <options...>
Après avoir créé le correctif, exécutez cette commande:
git reset --mixed <SHA of commit *before* your working-changes commit(s)>
Cela annulera vos validations temporaires. Le résultat final laisse votre copie de travail (intentionnellement) sale avec les mêmes modifications que vous aviez à l'origine.
Côté réception, vous pouvez utiliser la même astuce pour appliquer les modifications à la copie de travail, sans avoir l'historique de validation. Appliquez simplement le (s) patch (s) et git reset --mixed <SHA of commit *before* the patches>
.
Notez que vous devrez peut-être être bien synchronisé pour que cette option fonctionne. J'ai vu des erreurs lors de l'application de correctifs alors que la personne qui les fabriquait n'avait pas supprimé autant de modifications que moi. Il y a probablement des moyens de le faire fonctionner, mais je n'y suis pas allé bien loin.
Voici comment créer les mêmes correctifs dans Tortoise Git (pas que je recommande d'utiliser cet outil):
Tortoise Git
->Create Patch Serial
Since
: FETCH_HEAD
fonctionnera si vous êtes bien synchronisé)Tortise Git
->Show Log
reset "<branch>" to this...
Mixed
optionEt comment les appliquer:
Tortoise Git
->Apply Patch Serial
Tortise Git
->Show Log
reset "<branch>" to this...
Mixed
optionPour créer un patch avec à la fois des fichiers modifiés et nouveaux (par étapes), vous pouvez exécuter:
git diff HEAD > file_name.patch
git diff --cached > mypatch.patch
ne fonctionne pas.
file_name.patch
être utilisé par la patch
commande? Sont-ils compatibles entre eux?
J'aime:
git format-patch HEAD~<N>
où <N>
est le nombre de dernières validations à enregistrer en tant que correctifs.
Les détails sur l'utilisation de la commande se trouvent dans le DOC
UPD
Ici, vous pouvez trouver comment les appliquer ensuite.
UPD Pour ceux qui n'ont pas eu l'idée d' format-patch
ajouter un alias:
git config --global alias.make-patch '!bash -c "cd ${GIT_PREFIX};git add .;git commit -m ''uncommited''; git format-patch HEAD~1; git reset HEAD~1"'
Ensuite, dans n'importe quel répertoire de votre référentiel de projet, exécutez:
git make-patch
Cette commande créera 0001-uncommited.patch
dans votre répertoire actuel. Le correctif contiendra toutes les modifications et les fichiers non suivis qui sont visibles pour la commande suivante:
git status .
Nous pourrions également spécifier les fichiers, pour inclure uniquement les fichiers avec des changements relatifs, en particulier lorsqu'ils s'étendent sur plusieurs répertoires ex
git diff ~/path1/file1.ext ~/path2/file2.ext...fileN.ext > ~/whatever_path/whatever_name.patch
J'ai trouvé que cela n'était pas spécifié dans les réponses ou les commentaires, qui sont tous pertinents et corrects, j'ai donc choisi de l'ajouter. Explicite vaut mieux qu'implicite!