[LINUX] J'ai essayé deux façons de combiner plusieurs commits avec Git

Quand j'ai mis en place un commit avec rebase, j'ai causé une question mineure ou bâclée. On m'a dit que "le patch devrait être utilisé pour refléter plusieurs commits à la fois", mais quand j'ai cherché sur Google, de nombreuses méthodes de combinaison avec rebase ont été introduites. Je n'ai pas compris la différence entre ces deux méthodes, je vais donc l'enregistrer avec ma propre prudence.

Aperçu des deux méthodes en premier lieu

1. Comment appliquer le fichier de correctif

Comment combiner plusieurs commits en un seul diff

• $ git diff -p <branche source> <branche destination >> a.patch Affiche la différence entre les deux branches sous forme de fichier patch.
• Le nom du fichier de patch est arbitraire
• $ patch --dry-run -p1 < a.patch
  Vérifiez le fichier de différence avec un essai à sec (essai).
• $ patch -p1 < a.patch
  Si vous le versez après avoir vérifié la différence, il sera dans l'état avant git add.
• (+ Α) $ git diff <branche source> <branche destination> | patch -p1 De cette manière, vous pouvez également les exécuter tous en même temps sur une seule ligne.

2. Comment assembler avec rebase

• $ git rebase -i HEAD ~ (nombre de commits retournant de HEAD) Depuis le démarrage de vim, modifiez et enregistrez le message de validation et la séquence de validation.
• $ git push -f origin <branch>
  ** Soyez prudent avec les poussées forcées! !! ** **
• • L'historique de validation avant rebase a déjà été poussé, et s'il y a un conflit pendant le rebase, suivez les étapes ci-dessous.
• $ git co --ours(--theirs)
  Si vous ne pouvez pas appliquer uniquement les modifications dans une branche à la fois, vous devez la modifier régulièrement ...?
• $ git add .
• $ git rebase --continue (continuer le rebase après la résolution du conflit) → Une fois terminé, à nouveau $ git push -f origin <branch>

Site de référence

• Combinez plusieurs commits en un seul avec la commande [Git] rebase
• Utilisez git rebase -i pour collecter les commits et nettoyer l'historique!
• Faites attention aux conflits lorsque git pousse l'historique résumé.
• Modifier l'historique des commits git (git rebase) 1/2
• Sort commits avec git rebase

Une petite histoire désordonnée avec rebase

Ce qui a échoué

(@Succursale personnelle) $ git merge develop
$ git rebase -i HEAD~Résumer les commits avec xx
$ git push -f origin <branch>

J'ai suivi les étapes ci-dessus. Que va-t-il se passer? ... Comme dans ce cas, il était mauvais d'utiliser $ git rebase -i HEAD ~ xx quand il y avait un commit par quelqu'un d'autre que vous-même entre les commits que vous essayiez de rassembler. Résumez avec $ git rebase -i HEAD ~ xx et réengagez d'autres personnes. À ce stade, il sera résumé comme votre propre engagement, vous finirez donc par vous engager. Je devais d'abord créer mes propres commits, puis fusionner les branches de développement. (Voir ici)

Résumé

Général

• ** Attention avec $ git push -f origin <branch>! !! ** **
• Lorsque vous rebasez une branche avec les commits distribués et autres Réengagez le commit de quelqu'un d'autre comme le vôtre.
• Comment appliquer le fichier de correctif → Puisqu'il ne modifie pas le journal de commit de la branche personnelle, Ne peut être utilisé que pour appliquer des mises à jour de branche personnelle à la branche de développement en masse = Image de "extraire les différences qui sont uniques aux branches individuelles comme une différence et les attacher au premier commit de la branche de développement"
• À ce stade, le journal de validation de la branche personnelle reste distribué.

approche

• (Si vous tombez dans ce cas) Il n'est pas bon de fusionner tel quel. → Si vous le faites, vous pouvez le gérer en recréant une autre branche et en extrayant vos modifications du commit.
• L'image de changer la racine d'une branche avec $ git rebase.
• Si vos modifications sont dispersées comme cette fois: Il semble qu'il soit rapide de recouper dans une autre branche et de «choisir des cerises» uniquement pour vous-même. → Peut être utilisé comme un effacement lorsque vous faites une erreur dans l'opération git ...
• Si vous pouvez également utiliser $ git reset, il sera plus facile de corriger si vous faites une erreur. → C'est encore mieux si vous connaissez les options --soft, --hard, --mixed.
• Caisse à la succursale à fusionner → Fusionner une branche personnelle qui a altéré le commit de quelqu'un d'autre → Vous pouvez également extraire uniquement les modifications avec $ git reset HEAD ^ sans pousser (Il y a une possibilité de beaucoup de conflits ...)