Cet article vous apporte des connaissances pertinentes sur la conservation des enregistrements Gitcommit propres, y compris les problèmes liés à "git commit –amend", "git rebase -i" et "rebase".
Étude recommandée : "Tutoriel Git"
Tout le monde a appris à écrire du code de manière standardisée et concise, mais peu apprennent à soumettre du code de manière standardisée et concise. De nos jours, tout le monde utilise essentiellement Git comme outil de gestion de code source. Git offre une grande flexibilité. Nous soumettons/fusionnons du code selon différents workflows. Si cette flexibilité n'est pas bien contrôlée, cela posera également de nombreux problèmes
. l'historique désordonné des journaux git, qui est vraiment un enveloppement de pied de vieille dame, malodorant et long, personnellement, je n'aime pas ce genre de journal
La cause première de ce problème est la soumission de code aléatoire.
Le code a été soumis, existe-t-il un moyen de le sauvegarder ? Trois astuces peuvent parfaitement résoudre le problème
Le document d'aide de cette commande est décrit ainsi :
--amend amend previous commit
En d'autres termes, cela peut nous aider à modifier le dernier commit
Nous peut modifier le message que nous avons soumis, et nous pouvons modifier le fichier que nous avons soumis, et enfin remplacer le dernier commit-id
Nous pouvons manquer un certain fichier lors de la soumission, et lorsque nous soumettons à nouveau, il peut y avoir plusieurs erreurs. -id, tout le monde fait ça, et le journal git deviendra progressivement trop compliqué pour suivre la fonction complète
Supposons que nous ayons une telle information de journal
* 98a75af (HEAD -> feature/JIRA123-amend-test) feat: [JIRA123] add feature 1.2 * 119f86e feat: [JIRA123] add feature 1.1 * 5dd0ad3 feat: [JIRA123] add feature 1 * c69f53d (origin/main, origin/feature/JIRA123-amend-test, origin/HEAD, main) Initial commit
Supposons que nous voulions modifier le dernier message du journal, nous pouvons utiliser ce qui suit Commande :
git commit --amend -m "feat: [JIRA123] add feature 1.2 and 1.3"
Regardons à nouveau les informations du journal. Nous pouvons constater que nous avons remplacé l'ancien commit-id 98a75af par le nouveau commit-id 5e354d1, modifié le message et n'avons pas ajouté de nœuds
* 5e354d1 (HEAD -> feature/JIRA123-amend-test) feat: [JIRA123] add feature 1.2 and 1.3 * 119f86e feat: [JIRA123] add feature 1.1 * 5dd0ad3 feat: [JIRA123] add feature 1 * c69f53d (origin/main, origin/feature/JIRA123-amend-test, origin/HEAD, main) Initial commit
Maintenant les fichiers. dans notre dépôt sont comme ceci :
. ├── README.md └── feat1.txt 0 directories, 2 files
Supposons que nous ayons oublié un fichier de configuration config.yaml lors de la soumission de la fonctionnalité 1.3 et que nous ne souhaitions pas modifier le journal ou ajouter un nouvel identifiant de validation, alors la commande suivante est très facile à utiliser
echo "feature 1.3 config info" > config.yaml git add . git commit --amend --no-edit
git commit --amend --no-edit est l'âme Jetons un coup d'œil au fichier repo actuel :
. ├── README.md ├── config.yaml └── feat1.txt 0 directories, 3 files
Jetons un coup d'œil au git log
* 247572e (HEAD -> feature/JIRA123-amend-test) feat: [JIRA123] add feature 1.2 and 1.3 * 119f86e feat: [JIRA123] add feature 1.1 * 5dd0ad3 feat: [JIRA123] add feature 1 * c69f53d (origin/main, origin/feature/JIRA123-amend-test, origin/HEAD, main) Initial commit
Connaissant cette technique, nous pouvons nous assurer que chacun. de nos soumissions contiennent des informations valides. Une image décrivant le processus ressemble à ceci :
Avec le bonus buff de --no-edit, c'est plus puissant
Vous pouvez consulter le journal ci-dessus. Nous développons la fonctionnalité 1. Avant de fusionner la branche de fonctionnalité dans la branche principale, nous devons continuer à fusionner les nœuds de validation du journal. Ceci est utilisé
git rebase -i HEAD~n
où n représente les derniers commits. Ci-dessus, nous avons trois validations pour la fonctionnalité 1, donc vous. peut utiliser :
git rebase -i HEAD~3
Après l'exécution, un éditeur vim s'affichera avec le contenu suivant :
1 pick 5dd0ad3 feat: [JIRA123] add feature 1 2 pick 119f86e feat: [JIRA123] add feature 1.1 3 pick 247572e feat: [JIRA123] add feature 1.2 and 1.3 4 5 # Rebase c69f53d..247572e onto c69f53d (3 commands) 6 # 7 # Commands: 8 # p, pick <commit> = use commit 9 # r, reword <commit> = use commit, but edit the commit message 10 # e, edit <commit> = use commit, but stop for amending 11 # s, squash <commit> = use commit, but meld into previous commit 12 # f, fixup <commit> = like "squash", but discard this commit's log message 13 # x, exec <command> = run command (the rest of the line) using shell 14 # d, drop <commit> = remove commit 15 # l, label <label> = label current HEAD with a name 16 # t, reset <label> = reset HEAD to a label 17 # m, merge [-C <commit> | -c <commit>] <label> [# <oneline>] 18 # . create a merge commit using the original merge commit's 19 # . message (or the oneline, if no original merge commit was 20 # . specified). Use -c <commit> to reword the commit message. 21 # 22 # These lines can be re-ordered; they are executed from top to bottom. 23 # 24 # If you remove a line here THAT COMMIT WILL BE LOST. 25 # 26 # However, if you remove everything, the rebase will be aborted. 27 # 28 # 29 # Note that empty commits are commented out</commit></oneline></label></commit></commit></label></label></commit></command></commit></commit></commit></commit></commit>
Les identifiants de validation fusionnés les plus couramment utilisés sont squash et fixup. Le premier contient le message de validation et le second n'utilise pas de correction. ici, et puis :wq Exit
1 pick 5dd0ad3 feat: [JIRA123] add feature 1 2 fixup 119f86e feat: [JIRA123] add feature 1.1 3 fixup 247572e feat: [JIRA123] add feature 1.2 and 1.3
Regardons à nouveau le log, c'est très clair
* 41cd711 (HEAD -> feature/JIRA123-amend-test) feat: [JIRA123] add feature 1 * c69f53d (origin/main, origin/feature/JIRA123-amend-test, origin/HEAD, main) Initial commit
La fonctionnalité ci-dessus1 a été entièrement développée, la branche principale a également été mise à jour par d'autres, puis fusionnez la fonctionnalité avec la branche principale. Avant, en cas de conflits de code, vous devez d'abord fusionner le contenu de la branche principale dans la fonctionnalité. Si vous utilisez la commande de fusion, il y aura un nœud de fusion supplémentaire, et là. sera aussi un point d'inflexion dans l'historique du log, qui n'est pas linéaire, donc ici on peut utiliser la commande rebase sur la branche feature
git pull origin main --rebase
La commande pull nous aide automatiquement à faire la fusion, mais ici sous la forme de rebase, jetons un coup d'œil au journal
* d40daa6 (HEAD -> feature/JIRA123-amend-test) feat: [JIRA123] add feature 1 * 446f463 (origin/main, origin/HEAD) Create main.properties * c69f53d (origin/feature/JIRA123-amend-test, main) Initial commit
Le nœud de soumission de notre fonction feature1 au-dessus de main, ou maintenons la linéarité, puis vous pouvez pousser le code, puis soumettre un PR et fusionner votre fonctionnalité avec la branche principale
Une description simple de la différence entre la fusion et le rebase est la suivante :
J'utilise git pull origin main --rebase ici pour omettre le processus de changement de main et d'extraction du dernier contenu, puis de retour en arrière. Cela se fait en une seule étape. Le principe derrière cela est celui indiqué dans l'image ci-dessus. est une règle d'or à suivre lors de l'utilisation de rebase. , je l'ai déjà dit, donc je ne le répéterai plus
Résumé
Apprentissage recommandé : "
Tutoriel GitCe qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!