Comment puis-je faire pour revenir à un commit spécifique dans la base de données de l'entreprise ? git ?
La meilleure réponse que l'on ait pu me donner était d'utiliser git revert X fois jusqu'à ce que je parvienne à l'engagement souhaité.
Donc disons que je veux revenir à un commit qui date de 20 commits, je dois l'exécuter 20 fois.
Existe-t-il un moyen plus simple de procéder ?
Je ne peux pas utiliser reset car ce dépôt est public.
Essayez ça :
git checkout [revision] .où [revision] est le hachage du commit (par exemple : 12345678901234567890123456789012345678ab ).
N'oubliez pas le . à la fin, très important. Cela appliquera les changements à l'ensemble de l'arbre. Vous devez exécuter cette commande dans la racine du projet git. Si vous êtes dans un sous-répertoire, cette commande ne modifie que les fichiers du répertoire courant. Ensuite, faites un commit et tout devrait bien se passer.
Vous pouvez annuler cela en
git reset --hard qui supprimera toutes les modifications du répertoire de travail et de la zone de transit.
@AlexReisner Ce point à la fin pointe vers le répertoire dans lequel vous vous trouvez actuellement, ce qui n'est pas nécessairement le projet git entier, correct ? Si vous vouliez appliquer les changements à l'ensemble du projet, utiliseriez-vous plutôt ':/' comme dans 'git add :/', si vous n'étiez pas actuellement dans la racine du projet git ?
Note : si vous avez ajouté de nouveaux fichiers à votre projet depuis, cela ne les supprimera pas. Ainsi, lorsque vous allez construire (en fonction de votre plate-forme), vous pouvez encore obtenir des erreurs. Supprimez les nouveaux fichiers et c'est bon.
@MSpreij Vous devez exécuter cette commande dans la racine du projet git. Si vous êtes dans un sous-répertoire, cette commande ne modifie que les fichiers du répertoire courant.
La seule différence entre cette approche et "git checkout [revision] ." est que cette dernière conserve les révisions.
Cette réponse est erronée car le PO indique spécifiquement "Je ne peux pas utiliser reset car ce repo est public".
Si le dépôt est public, je pense qu'il n'y a pas de moyen de revenir en arrière sans utiliser force push (git push -f) car cela affecterait les personnes qui ont apporté les changements avant le retour en arrière. Ainsi, la réinitialisation peut être utilisée dans le bac à sable local d'un dépôt public également.
Eh bien, je suppose que la question est, qu'est-ce que vous voulez dire par "retour en arrière" ? Si vous ne pouvez pas reset parce que c'est public et que vous voulez garder l'historique des commit intact, voulez-vous dire que vous voulez juste que votre copie de travail reflète un commit spécifique ? Utilisez git checkout et le hash de validation.
Edit : Comme il a été souligné dans les commentaires, l'utilisation de git checkout sans spécifier de branche vous laissera dans un état "sans branche". Utilisez git checkout <commit> -b <branchname> pour effectuer un checkout dans une branche, ou git checkout <commit> . pour effectuer un checkout dans la branche courante.
Cela ne vous place-t-il pas dans l'état bizarre "Pas actuellement sur une branche" ? Comment valider les changements pour terminer le retour en arrière ?
Eh bien, je suggère simplement l'utilisation de git checkout -- il est libre de partir dans n'importe quelle branche (actuelle ou nouvelle) qu'il souhaite. Je vais mettre à jour ma réponse pour qu'elle ne soit pas ambiguë.
J'ai essayé ceci mais je ne pense pas que ce soit la bonne façon de faire car cela laisse des fichiers stagnants. Cela ne supprime pas les fichiers qui n'étaient pas dans la dernière livraison.
L'affiche originale déclare :
La meilleure réponse que l'on ait pu me donner était d'utiliser
git revertX fois jusqu'à ce que je atteigne l'engagement souhaité.Donc disons que je veux revenir à un commit qui date de 20 commits, j'aurais l'exécuter 20 fois.
Existe-t-il un moyen plus simple de procéder ?
Je ne peux pas utiliser reset car ce repo est public.
Il n'est pas nécessaire d'utiliser git revert X fois. git revert peut accepter un comme argument, de sorte que vous n'avez besoin de l'utiliser qu'une seule fois pour inverser une gamme de commits. Par exemple, si vous voulez revenir sur les 20 derniers commits :
git revert --no-edit HEAD~20..La gamme des engagements HEAD~20.. est le diminutif de HEAD~20..HEAD et signifie "commencer par le 20 th parent du commit HEAD, et renverse tous les commits après lui jusqu'à HEAD".
Cela va inverser les 20 derniers engagements, en supposant qu'aucun d'entre eux ne soit une fusion de fusion. S'il y a des commits de fusion, alors vous ne pouvez pas les inverser tous en une seule commande, vous devrez les inverser individuellement avec la commande
git revert -m 1 <merge-commit>Notez également que j'ai testé l'utilisation d'une gamme avec git revert en utilisant la version 1.9.0 de git. Si vous utilisez une version antérieure de git, l'utilisation d'une plage avec git revert peut ou ne peut pas fonctionner.
Dans ce cas, git revert est préféré à git checkout .
Notez que, contrairement à cette réponse qui dit d'utiliser git checkout , git revert supprimera en fait tous les fichiers qui ont été ajoutés dans l'un des commits que vous que vous inversez ce qui fait que c'est la façon correcte de rétablir une série de révisions.
Note : ceci crée un nouveau commit avec les changements annulés. Parfait pour la question de l'OP. Mais assurez-vous que c'est ce que vous voulez. (Les exemples dans le git-revert Le document dont le lien figure ci-dessus est excellent). Si vous souhaitez plutôt enquêter sur des commits antérieurs (c'est-à-dire avant de choisir vers quel commit revenir), utilisez l'option checkout mentionnée dans d'autres réponses, en gardant à l'esprit les commentaires des autres sur les fichiers supprimés.
Je pense avoir compris vos questions, voici ce que j'ai trouvé pour le résoudre. et il n'y a pas de solution GUI, vous pouvez seulement utiliser la commande pour le résoudre, et c'est vraiment simple.
étape 1 : créez un tag de l'ancien commit que vous voulez revenir en arrière.
like tag v2.0
étape 2 : git checkout v2.2
Voilà, maintenant votre HEAD pointe sur le commit 'v2.0', mais master pointe toujours sur le dernier commit.
C:\Program Archivos \Git\doc\git\html\git -checkout.html ce document peut vous aider
ou tapez git help < checkout >
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
1 votes
Git revert <commit> ne fonctionne pas ?
9 votes
Comme indiqué dans ma question, cela ne m'aide pas vraiment si je veux revenir à quelque chose qui date de 20 commits.
8 votes
La réponse à cette question a été très bien faite ici stackoverflow.com/questions/4114095/
6 votes
Ce que vous entendez par "rolling back" n'est pas clair. Est-ce que cela signifie que vous voulez basculer temporairement votre copie de travail vers une révision particulière ? Ou que vous voulez rétablir de façon permanente l'historique de votre référentiel à une certaine révision ?
2 votes
Vous devriez accepter une réponse, et éventuellement voter pour les autres réponses qui vous plaisent.
0 votes
En rapport : Revenir à un commit précédent dans le repo Git . Notez que cette question n'a pas la contrainte que le repo est public.