Un commit revert est juste comme n'importe quel autre commit dans git. Ce qui signifie que vous pouvez revenir en arrière, comme dans :
git revert 648d7d808bc1bca6dbf72d93bf3da7c65a9bd746
Cela n'a évidemment de sens qu'une fois que les modifications ont été poussées, et surtout lorsque vous ne pouvez pas forcer la poussée sur la branche de destination (ce qui est une bonne idée pour vos maître ). Si le changement n'a pas été poussé, il suffit de faire un cherry-pick, un revert ou simplement de supprimer le commit revert comme dans les autres posts.
Dans notre équipe, nous avons une règle pour utiliser une revenir à on Renverse les commits qui ont été commis dans la branche principale, principalement pour garder l'historique propre, afin que vous puissiez voir quel commit renverse quoi :
7963f4b2a9d Revert "Revert "OD-9033 parallel reporting configuration"
"This reverts commit a0e5e86d3b66cf206ae98a9c989f649eeba7965f.
...
a0e5e86d3b6 Revert "OD-9055 paralel reporting configuration"
This reverts commit 648d7d808bc1bca6dbf72d93bf3da7c65a9bd746.
...
Merge pull request parallel_reporting_dbs to master* commit
'648d7d808bc1bca6dbf72d93bf3da7c65a9bd746'
De cette façon, vous pouvez retracer l'histoire et comprendre toute l'histoire, et même ceux qui ne connaissent pas l'héritage pourraient le découvrir par eux-mêmes. Alors que, si vous cueillir des cerises ou rebasement Ces informations précieuses sont perdues (à moins que vous ne les incluiez dans le commentaire).
Évidemment, si un commit est inversé et ré-inversé plus d'une fois, cela devient assez désordonné.