Cette question est un peu A/B, car vous n'avez pas expliqué il y a longtemps le scénario de suppression de l'enregistrement de commit, ce qui est très important car cela affectera le choix ultérieur d'utiliser Git. Par exemple :
Si je souhaite supprimer les soumissions de l'historique qui ont été soumises avant l'examen, mais qu'il reste encore de nombreuses soumissions qui doivent être conservées plus tard, alors :
1.2 Si les enregistrements historiques à supprimer sont dispersés, vous pouvez envisager un Rebase interactif, une sélection/fusion par vous-même, etc. Tel que git rebase -i <ref>
1.1 Si les enregistrements historiques à supprimer sont continus, par exemple, tous les enregistrements du début à un certain moment peuvent être supprimés ou une section au milieu peut être supprimée, vous pouvez envisager Sur Rebase, tel comme git rebase --onto <ONTO_BASE_ref> <START_ref> <END_ref>, où START La partie entre END est la partie qui doit être conservée, et ONTO_BASE est le dernier point de base en d'autres termes, les enregistrements historiques entre ONTO_BASE et START seront être supprimé.
Si je souhaite supprimer beaucoup d'enregistrements historiques et en conserver très peu (par exemple, conserver simplement le plus récent, je n'en veux plus), alors je peux simplement créer une branche orpheline pour reconstituer l'historique. Par exemple, git checkout --orphan new_start, cette commande créera une branche appelée new_start. Cette branche n'a aucun historique, mais tous les fichiers existeront intacts et vous pourrez commencer à soumettre à nouveau en conséquence. Une fois terminé, vous pouvez même supprimer directement l’ancienne branche. De plus, vous pouvez également spécifier le point de départ de la nouvelle branche. La valeur par défaut est bien sûr à partir de HEAD.
Vous pouvez également diviser l'historique en deux (ou plusieurs) parties, dont certaines sont complètes, dont certaines sont simplifiées, etc. Pour plus de détails, veuillez vous référer à ce document sur git replace : http://git -scm.com/2010/03/17/replace.html
En fait, de nombreux scénarios peuvent être envisagés. L'utilisation de Git est très flexible. Même si vous ne l'utilisez pas temporairement, cela vaut la peine de le lire attentivement pour savoir quel genre de choses il peut faire, et. alors vous pouvez le déduire par vous-même lorsque vous rencontrez divers scénarios complexes. Il existe une solution.
En tant que responsable de Repo, la chose la plus courante est de le conserver d'une certaine référence à HEAD, puis de supprimer l'historique précédent. Parce que cette tâche est relativement courante, voici un script shell à partager avec vous :
est utilisé comme ceci (par exemple, le script est enregistré sous git-detach) : git-detach <ref>, où <ref> est le point de départ de l'enregistrement historique que vous souhaitez conserver.
Il convient de noter que ce script ne fait que "séparer" l'enregistrement de l'historique, et qu'ensuite certains d'entre eux n'ont aucune référence visible et ne sont pas visibles dans l'enregistrement de l'historique. Cependant, leur objet git existe toujours ( En d'autres termes, vous pouvez toujours récupérer et vérifier git-reflog par vous-même). Si vous voulez vraiment jeter complètement cet historique (afin de perdre du poids pour le repo), vous pouvez utiliser git gc --prune, et vous n'obtiendrez jamais. il revient.
P.S. Ce script dépend de Orphan Branch, qui n'est pas pris en charge par les versions inférieures de Git (probablement < v1.7.x). Si vous avez une alternative, veuillez la rechercher vous-même.
Cette question est un peu A/B, car vous n'avez pas expliqué il y a longtemps le scénario de suppression de l'enregistrement de commit, ce qui est très important car cela affectera le choix ultérieur d'utiliser Git. Par exemple :
1.2 Si les enregistrements historiques à supprimer sont dispersés, vous pouvez envisager un Rebase interactif, une sélection/fusion par vous-même, etc. Tel que
git rebase -i <ref>
1.1 Si les enregistrements historiques à supprimer sont continus, par exemple, tous les enregistrements du début à un certain moment peuvent être supprimés ou une section au milieu peut être supprimée, vous pouvez envisager Sur Rebase, tel comme
git rebase --onto <ONTO_BASE_ref> <START_ref> <END_ref>
, oùSTART
La partie entreEND
est la partie qui doit être conservée, etONTO_BASE
est le dernier point de base en d'autres termes, les enregistrements historiques entreONTO_BASE
etSTART
seront être supprimé.git checkout --orphan new_start
, cette commande créera une branche appeléenew_start
. Cette branche n'a aucun historique, mais tous les fichiers existeront intacts et vous pourrez commencer à soumettre à nouveau en conséquence. Une fois terminé, vous pouvez même supprimer directement l’ancienne branche. De plus, vous pouvez également spécifier le point de départ de la nouvelle branche. La valeur par défaut est bien sûr à partir deHEAD
.git replace
: http://git -scm.com/2010/03/17/replace.htmlEn fait, de nombreux scénarios peuvent être envisagés. L'utilisation de Git est très flexible. Même si vous ne l'utilisez pas temporairement, cela vaut la peine de le lire attentivement pour savoir quel genre de choses il peut faire, et. alors vous pouvez le déduire par vous-même lorsque vous rencontrez divers scénarios complexes. Il existe une solution.
En tant que responsable de Repo, la chose la plus courante est de le conserver d'une certaine référence à HEAD, puis de supprimer l'historique précédent. Parce que cette tâche est relativement courante, voici un script shell à partager avec vous :
est utilisé comme ceci (par exemple, le script est enregistré sous
git-detach
) :git-detach <ref>
, où<ref>
est le point de départ de l'enregistrement historique que vous souhaitez conserver.Il convient de noter que ce script ne fait que "séparer" l'enregistrement de l'historique, et qu'ensuite certains d'entre eux n'ont aucune référence visible et ne sont pas visibles dans l'enregistrement de l'historique. Cependant, leur objet git existe toujours ( En d'autres termes, vous pouvez toujours récupérer et vérifier
git-reflog
par vous-même). Si vous voulez vraiment jeter complètement cet historique (afin de perdre du poids pour le repo), vous pouvez utilisergit gc --prune
, et vous n'obtiendrez jamais. il revient.P.S. Ce script dépend de Orphan Branch, qui n'est pas pris en charge par les versions inférieures de Git (probablement < v1.7.x). Si vous avez une alternative, veuillez la rechercher vous-même.