Maison >outils de développement >git >3 gestes pour y parvenir ! Gardez un enregistrement de commit Git propre

3 gestes pour y parvenir ! Gardez un enregistrement de commit Git propre

WBOY
WBOYavant
2022-02-22 18:01:301604parcourir

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".

3 gestes pour y parvenir ! Gardez un enregistrement de commit Git propre

É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

3 gestes pour y parvenir ! Gardez un enregistrement de commit Git propre

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

Faites bon usage de git commit –amend

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 :

3 gestes pour y parvenir ! Gardez un enregistrement de commit Git propre

Avec le bonus buff de --no-edit, c'est plus puissant

Faites bon usage de git rebase -i

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

Faites bon usage de rebase

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

3 gestes pour y parvenir ! Gardez un enregistrement de commit Git propre

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 :

3 gestes pour y parvenir ! Gardez un enregistrement de commit Git propre

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é

Avec ces trois conseils, je pense que le journal git de tout le monde est extrêmement clair. Si vous ne le savez pas, vous pouvez certainement le promouvoir. Ce type de dépôt aura l'air plus sain

Apprentissage recommandé : "

Tutoriel Git

".

Ce 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!

Déclaration:
Cet article est reproduit dans:. en cas de violation, veuillez contacter admin@php.cn Supprimer