J'essaie de sélectionner un commit de master et de l'intégrer à la branche de production actuelle. Cependant, quand j'exécute git cherry-pick <SHA-hash>
, Je viens de recevoir ce message:
# On branch prod_20110801
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
# site/test-result/
nothing added to commit but untracked files present (use "git add" to track)
The previous cherry-pick is now empty, possibly due to conflict resolution.
If you wish to commit it anyway, use:
git commit --allow-empty
Otherwise, please use 'git reset'
Remarque: j'ai essayé d'effectuer une réinitialisation et une réinitialisation - hard HEAD ^, et aucune ne semblait rien changer.
Je ne comprends pas pourquoi cela ne fonctionne pas pour moi.
Toute idée, conseil ou idée sur la façon de résoudre ce problème serait utile ~!
Git résout le choix du cherry comme un no-op - toutes les modifications introduites par ce commit ont été introduites par des commit sur votre branche actuelle. (Ou c'est ce que pense Git, en tout cas.) Vérifiez que le commit que vous choisissez ne fait pas déjà partie d'une fusion, qu'il s'agisse d'un correctif de fusion, de rebase/cherry ou d'un patch à la pièce. (Utilisation git show <commit-id>
voir la diff.)
Dans mon cas, cela me rendait dingue, car il était évident que le commit spécifique que je voulais mettre au premier plan avait été non été fusionné dans ma branche actuelle.
Il s'avère que quelqu'un a déjà choisi le commit une semaine auparavant. Les modifications, mais pas la SHA spécifique, étaient déjà dans ma branche actuelle et je ne les avais pas remarquées.
Vérifiez le (s) fichier (s) que vous essayez de sélectionner. S'ils ont déjà les modifications, une version du commit a déjà été choisie ou ajoutée d'une autre manière. Il n'y a donc pas besoin de chercher à nouveau.
Notez également que l’ajout d’un fichier vide (par exemple, .gitkeep
) à l’arbre est considéré par cherry-pick comme un commit vide.
Alors, voici encore une autre situation déroutante où cela peut se produire: J'ai eu ce qui suit:
J'essayais de choisir 9a7b12e, ce qui n'est apparemment rien - il a même essayé de me dire sur cette ligne dans la sortie du journal git que 4497428 était ce que je voulais vraiment. (Ce que j'ai fait était simplement de rechercher le message de validation et d'attraper le premier hash que j'ai vu qui le contenait). Quoi qu'il en soit, je veux simplement que les gens sachent qu'il existe un autre moyen de se faire piéger en essayant de choisir un non-traitement.