git-rebase - En ligne dans le Cloud

PROGRAMME:

Nom

git-rebase - Forward-port local commits à la tête en amont mise à jour

SYNOPSIS

jet rebasement [-je | --interactive] [options] [--exec ] [--sur ]
[ [ ]]
jet rebasement [-je | --interactive] [options] [--exec ] [--sur ]
--racine [ ]
jet rebasement --continuer | --ignorer | --avorter | --edit-à faire

DESCRIPTION

Si est spécifié, jet rebasement effectuera un git checkout automatique
avant de faire autre chose. Sinon, il reste sur la branche courante.

Si n'est pas spécifié, l'amont configuré dans la branche. .à distance et
branche. Les options .merge seront utilisées (voir git-config(1) pour plus de détails) et le
L'option --fork-point est supposée. Si vous n'êtes actuellement dans aucune succursale ou si le
branche n'a pas d'amont configuré, le rebase avortera.

Toutes les modifications apportées par les commits dans la branche actuelle mais qui ne sont pas dans sont sauvés
dans une zone temporaire. C'est le même ensemble de commits qui serait affiché par git log
..DIRIGER; ou par git log 'fork_point'..HEAD, si --fork-point est actif (voir le
description sur --fork-point ci-dessous); ou par git log HEAD, si l'option --root est spécifiée.

La branche actuelle est réinitialisée à , ou si l'option --onto a été fournie.
Cela a exactement le même effet que git reset --hard (ou ). ORIG_HEAD est
réglé pour pointer à l'extrémité de la branche avant la réinitialisation.

Les commits précédemment enregistrés dans la zone temporaire sont ensuite réappliqués au
branche actuelle, une par une, dans l'ordre. Notez que tous les commits dans HEAD qui introduisent le
mêmes changements textuels qu'un commit dans HEAD. sont omis (c'est-à-dire un patch déjà
accepté en amont avec un message de validation différent ou un horodatage sera ignoré).

Il est possible qu'un échec de fusion empêche ce processus d'être complètement
automatique. Vous devrez résoudre un tel échec de fusion et exécuter git rebase --continue.
Une autre option consiste à contourner le commit qui a causé l'échec de la fusion avec git rebase
--sauter. Pour vérifier l'original et supprimez les fichiers de travail .git/rebase-apply,
utilisez plutôt la commande git rebase --abort.

Supposons que l'historique suivant existe et que la branche actuelle soit "topic" :

Sujet A---B---C
/
D---E---F---G maître

À partir de ce point, le résultat de l'une des commandes suivantes :

git rebase maître
sujet principal git rebase

serait:

Sujet A'--B'--C'
/
D---E---F---G maître

NOTE: Cette dernière forme n'est qu'un raccourci du sujet git checkout suivi de git rebase
Maître. Lorsque rebase quitte le sujet, le sujet restera la branche extraite.

Si la branche amont contient déjà une modification que vous avez apportée (par exemple, parce que vous avez envoyé un
patch qui a été appliqué en amont), alors ce commit sera ignoré. Par exemple, courir
git rebase master sur l'historique suivant (dans lequel A' et A introduisent le même ensemble de
changements, mais ont des informations de commiter différentes):

Sujet A---B---C
/
D---E---A'---F maître

aura pour résultat:

Sujet B'---C'
/
D---E---A'---F maître

Voici comment transplanter une branche thématique basée sur une branche à une autre, pour prétendre
que vous avez dérivé la branche thématique de cette dernière branche, en utilisant rebase --onto.

Supposons d'abord que votre sujet est basé sur la branche next. Par exemple, une fonctionnalité développée dans
sujet dépend de certaines fonctionnalités qui se trouvent dans next.

o---o---o---o---o maître
\
o---o---o---o---o suivant
\
o---o---o sujet

Nous voulons faire sujet bifurqué de la branche maître; par exemple, parce que la fonctionnalité sur
qui sujet depend a été fusionné dans le plus stable maître branche. Nous voulons que notre arbre
ressemble à ca:

o---o---o---o---o maître
| \
| o'--o'--o' sujet
\
o---o---o---o---o suivant

Nous pouvons l'obtenir en utilisant la commande suivante :

git rebase --onto master prochain sujet

Un autre exemple d'option --onto consiste à rebaser une partie d'une branche. Si nous avons ce qui suit
situation:

H---I---J sujetB
/
E---F---G sujetA
/
A---B---C---D maître

puis la commande

git rebase --onto master topicA topicB

se traduirait par :

H'--I'--J' topicB
/
| E---F---G sujetA
|/
A---B---C---D maître

Ceci est utile lorsque topicB ne dépend pas de topicA.

Une plage de commits peut également être supprimée avec rebase. Si nous avons la situation suivante :

E---F---G---H---I---J sujetA

puis la commande

git rebase --onto sujetA~5 sujetA~3 sujetA

entraînerait la suppression des commits F et G :

E---H'---I'---J' topicA

Ceci est utile si F et G étaient défectueux d'une manière ou d'une autre, ou ne devraient pas faire partie du topicA. Noter
que l'argument de --onto et le Le paramètre peut être n'importe quel commit valide.

En cas de conflit, jet rebasement s'arrêtera au premier commit problématique et quittera
marqueurs de conflit dans l'arbre. Vous pouvez utiliser jet diff pour localiser les marqueurs (<<<<<<) et faire
modifications pour résoudre le conflit. Pour chaque fichier que vous modifiez, vous devez indiquer à Git que le
conflit a été résolu, généralement cela se ferait avec

git ajouter

Après avoir résolu le conflit manuellement et mis à jour l'index avec la résolution souhaitée,
vous pouvez continuer le processus de rebasage avec

git rebase --continuer

Alternativement, vous pouvez annuler le jet rebasement avec

git rebase --abort

CONFIGURATION

rebase.stat
Indique s'il faut afficher un diffstat de ce qui a changé en amont depuis le dernier rebase. Faux par
défaut.

rebase.autoSquash
Si défini sur true, activer --autosquash option par défaut.

rebase.autoStash
Si défini sur true, activer --autostash option par défaut.

rebase.missingCommitsCheck
Si défini sur "warn", affiche des avertissements sur les commits supprimés en mode interactif. Si réglé sur
"error", imprimez les avertissements et arrêtez le rebase. Si défini sur "ignorer", aucune vérification n'est
terminé. "ignorer" par défaut.

rebase.instructionFormatrebase.instructionFormat
Format de liste de commits personnalisé à utiliser lors d'un --interactif rebaser.

OPTIONS

--sur
Point de départ auquel créer les nouveaux commits. Si l'option --onto n'est pas
spécifié, le point de départ est . Peut être n'importe quel commit valide, et pas seulement un
nom de la succursale existante.

Comme cas particulier, vous pouvez utiliser "A...B" comme raccourci pour la base de fusion de A et B si
il y a exactement une base de fusion. Vous pouvez omettre au plus un de A et B, dans lequel
cas, la valeur par défaut est HEAD.


Branche en amont à comparer. Peut être n'importe quel commit valide, pas seulement un commit existant
Nom de la filiale. La valeur par défaut est configurée en amont pour la branche actuelle.


Branche de travail ; par défaut HEAD.

--Continuez
Redémarrez le processus de rebase après avoir résolu un conflit de fusion.

--avorter
Abandonnez l'opération de rebase et réinitialisez HEAD sur la branche d'origine. Si était
fourni lorsque l'opération de rebase a commencé, alors HEAD sera réinitialisé à .
Sinon, HEAD sera réinitialisé à l'endroit où il se trouvait lorsque l'opération de rebase a commencé.

--garder-vide
Conservez les commits qui ne changent rien de ses parents dans le résultat.

--sauter
Redémarrez le processus de rebasage en sautant le patch actuel.

--edit-à faire
Modifiez la liste de tâches lors d'un rebase interactif.

-m, --merge
Utilisez des stratégies de fusion pour rebaser. Lorsque la stratégie de fusion récursive (par défaut) est utilisée,
cela permet à rebase d'être au courant des changements de nom du côté amont.

Notez qu'une fusion de rebase fonctionne en rejouant chaque commit à partir de la branche de travail en haut
du branche. Pour cette raison, lorsqu'un conflit de fusion se produit, le côté
signalé comme le nôtre est la série rebasée jusqu'à présent, commençant par , et les leurs is
la branche de travail. En d'autres termes, les côtés sont inversés.

-s , --stratégie=
Utilisez la stratégie de fusion donnée. S'il n'y a pas d'option -s jet fusion-récursif est utilisé
au lieu. Cela implique --merge.

Parce que jet rebasement rejoue chaque commit de la branche de travail au-dessus du
branche en utilisant la stratégie donnée, en utilisant le le nôtre la stratégie rejette simplement
tous les correctifs de la , ce qui n'a pas beaucoup de sens.

-X , --strategy-option=
Passe le jusqu'à la stratégie de fusion. Cela implique --merge et, si
aucune stratégie n'a été spécifiée, -s récursif. A noter le renversement de le nôtre et les leurs as
indiqué ci-dessus pour l'option -m.

-S[ ], --gpg-signe[= ]
Les commits du signe GPG. L'argument keyid est facultatif et par défaut le committer
identité; si spécifié, il doit être collé à l'option sans espace.

-q, --calme
Soyez silencieux. Implique --no-stat.

-v, --verbeux
Soyez verbeux. Implique --stat.

--stat
Afficher un diffstat de ce qui a changé en amont depuis le dernier rebase. Le diffstat est également
contrôlé par l'option de configuration rebase.stat.

-n, --no-stat
Ne pas afficher un diffstat dans le cadre du processus de rebase.

--pas de vérification
Cette option contourne le hook de pré-rebase. Voir également crochets (5).

--Vérifier
Permet au hook de pré-rebase de s'exécuter, ce qui est la valeur par défaut. Cette option peut être utilisée pour
override --no-verify. Voir également crochets (5).

-C
Assurez-vous au moins les lignes du contexte environnant correspondent avant et après chaque changement.
Lorsqu'il existe moins de lignes de contexte environnant, elles doivent toutes correspondre. Par défaut non
le contexte est toujours ignoré.

-f, --force-rebase
Forcer un rebase même si la branche actuelle est à jour et la commande sans
--force reviendrait sans rien faire.

Vous pouvez trouver ceci (ou --no-ff avec un rebase interactif) utile après avoir rétabli un
la fusion de la branche thématique, car cette option recrée la branche thématique avec de nouveaux commits afin qu'elle
peut être refusionné avec succès sans avoir besoin de "rétablir la réversion" (voir le
annuler-une-fusion-défectueuse How-To[1] pour plus de détails).

--fork-point, --no-fork-point
Utilisez reflog pour trouver un meilleur ancêtre commun entre et lorsque
calculer quels commits ont été introduits par .

Lorsque --fork-point est actif, fourche_point sera utilisé à la place de à
calculer l'ensemble des commits à rebase, où fourche_point est le résultat de git
merge-base --fork-point commande (voir git-merge-base(1)). Si
fourche_point finit par être vide, le sera utilisé comme solution de repli.

Si soit ou --root est donné sur la ligne de commande, alors la valeur par défaut est
--no-fork-point, sinon la valeur par défaut est --fork-point.

--ignore-whitespace, --whitespace=
Ces drapeaux sont transmis au jet vous inscrire programme (voir git-appliquer(1)) qui applique le
pièce. Incompatible avec l'option --interactive.

--committer-date-est-la-date-de-l'auteur, --ignore-date
Ces drapeaux sont transmis à jet am pour changer facilement les dates des commits rebasés
(voir git-suis(1)). Incompatible avec l'option --interactive.

-i, --interactif
Faites une liste des commits qui sont sur le point d'être rebasés. Laisser l'utilisateur modifier cette liste
avant de rebaser. Ce mode peut également être utilisé pour diviser les commits (voir SPLITTING COMMITS
ci-dessous).

Le format de la liste de validation peut être modifié en définissant l'option de configuration
rebase.instructionFormat. Un format d'instruction personnalisé aura automatiquement le
hachage de validation long ajouté au format.

-p, --preserve-merges
Recréez les commits de fusion au lieu d'aplatir l'historique en rejouant les commits d'une fusion
commit introduit. Fusionner les résolutions de conflits ou les modifications manuelles pour fusionner les commits
ne sont pas conservés.

Cela utilise la machinerie --interactive en interne, mais en la combinant avec le
--L'option interactive n'est généralement pas une bonne idée à moins que vous ne sachiez ce que vous
font (voir BOGUES ci-dessous).

-X , --exec
Ajouter « exec " après chaque ligne créant un commit dans l'historique final. volonté
être interprété comme une ou plusieurs commandes shell.

Cette option ne peut être utilisée qu'avec l'option --interactive (voir MODE INTERACTIF
ci-dessous).

Vous pouvez exécuter plusieurs commandes en utilisant soit une instance de --exec avec plusieurs
commandes:

git rebase -i --exec "cmd1 && cmd2 && ..."

ou en donnant plus d'un --exec :

git rebase -i --exec "cmd1" --exec "cmd2" --exec ...

Si --autosquash est utilisé, les lignes "exec" ne seront pas ajoutées pour l'intermédiaire
commits, et n'apparaîtra qu'à la fin de chaque série de squash/fixup.

--racine
Rebase tous les commits accessibles depuis , au lieu de les limiter avec un
. Cela vous permet de rebaser le(s) commit(s) root sur une branche. Lorsqu'il est utilisé avec
--onto, il ignorera les changements déjà contenus dans (à la place de )
alors que sans --onto, il fonctionnera à chaque changement. Lorsqu'il est utilisé avec les deux
--onto et --preserve-merges, tous les commits root seront réécrits pour avoir comme
parent à la place.

--autosquash, --no-autosquash
Lorsque le message du journal de validation commence par « squash ! ... » (ou « fixup ! ..."), et qu'il y a
un commit dont le titre commence par le même ..., modifie automatiquement la todo list de
rebase -i pour que le commit marqué pour l'écrasement vienne juste après le commit à être
modifié, et changez l'action du commit déplacé de pick à squash (ou fixup).
Ignore « fixup ! » ou « squash ! » après le premier, au cas où vous auriez fait référence à un
correction/squash antérieur avec git commit --fixup/--squash.

Cette option n'est valide que lorsque le --interactif option est utilisée.

Si la --autosquash l'option est activée par défaut à l'aide de la variable de configuration
rebase.autoSquash, cette option peut être utilisée pour remplacer et désactiver ce paramètre.

--autostash, --no-autostash
Créez automatiquement une cachette temporaire avant le début de l'opération et appliquez-la après
l'opération se termine. Cela signifie que vous pouvez exécuter le rebase sur un arbre de travail sale. Cependant,
à utiliser avec précaution : la dernière application de stockage après un rebase réussi peut entraîner
conflits non négligeables.

--non-ff
Avec --interactive, sélectionnez tous les commits rebasés au lieu d'avancer rapidement
les inchangés. Cela garantit que l'historique complet de la branche rebasée est
composé de nouveaux commits.

Sans --interactive, c'est un synonyme de --force-rebase.

Vous pouvez trouver cela utile après avoir annulé une fusion de branches de rubrique, car cette option
recrée la branche thématique avec de nouveaux commits afin qu'elle puisse être refusionnée avec succès
sans avoir besoin de « revenir sur le retour » (voir le annuler-une-fusion-défectueuse How-To[1] pour
des détails).

FUSIONNER STRATÉGIES

Le mécanisme de fusion (commandes git merge et git pull) permet au backend fusionner les stratégies
à choisir avec l'option -s. Certaines stratégies peuvent également prendre leurs propres options, qui peuvent être
passé en donnant -X arguments pour git merge et/ou git pull.

résoudre
Cela ne peut résoudre que deux têtes (c'est-à-dire la branche actuelle et une autre branche que vous avez tirée
from) en utilisant un algorithme de fusion à 3 voies. Il essaie de détecter soigneusement les fusions croisées
ambiguïtés et est généralement considéré comme sûr et rapide.

récursif
Cela ne peut résoudre que deux têtes à l'aide d'un algorithme de fusion à trois voies. Quand il y a plus de
un ancêtre commun qui peut être utilisé pour la fusion à trois, il crée un arbre fusionné des
ancêtres communs et l'utilise comme arbre de référence pour la fusion à trois. Cela a
a été signalé comme entraînant moins de conflits de fusion sans provoquer des erreurs de fusion par les tests
fait sur les commits de fusion réels tirés de l'historique de développement du noyau Linux 2.6.
De plus, cela peut détecter et gérer les fusions impliquant des changements de nom. C'est la valeur par défaut
stratégie de fusion lors de l'extraction ou de la fusion d'une branche.

Le manuel de formation récursif stratégie peut prendre les options suivantes :

le nôtre
Cette option force les morceaux en conflit à être résolus automatiquement et proprement en privilégiant nos
version. Les changements de l'autre arbre qui n'entrent pas en conflit avec notre côté sont
reflété dans le résultat de la fusion. Pour un fichier binaire, tout le contenu est pris
de notre côté.

Cela ne doit pas être confondu avec le le nôtre stratégie de fusion, qui n'a même pas l'air
à ce que l'autre arbre contient du tout. Il rejette tout ce que l'autre arbre a fait,
déclarant nos l'histoire contient tout ce qui s'y est passé.

les leurs
C'est le contraire de le nôtre.

patience
Avec cette option, fusion-récursif passe un peu plus de temps pour éviter les erreurs de fusion
qui se produisent parfois en raison de lignes d'appariement sans importance (par exemple, des accolades de
les fonctions). Utilisez-le lorsque les branches à fusionner ont divergé énormément. Voir également
git-diff(1) --patience.

diff-algorithm=[patience|minimal|histogramme|myers]
Dit fusion-récursif d'utiliser un algorithme de diff différent, ce qui peut aider à éviter
erreurs de fusion qui se produisent en raison de lignes de correspondance sans importance (comme les accolades de
fonctions distinctes). Voir également git-diff(1) --diff-algorithme.

ignorer-espace-changement, ignorer-tout-espace, ignorer-espace-à-eol
Traite les lignes avec le type de changement d'espace indiqué comme inchangé pour le
dans l'intérêt d'une fusion à trois. Changements d'espaces mélangés avec d'autres changements sur une ligne
ne sont pas ignorés. Voir également git-diff(1) -b, -w et --ignore-space-at-eol.

· Si leur la version introduit uniquement des changements d'espaces sur une ligne, nos la version est
utilisé;

· Si nos la version introduit des changements d'espace mais leur la version comprend un
changement substantiel, leur la version est utilisée ;

· Sinon, la fusion se déroule de la manière habituelle.

renormaliser
Cela exécute une extraction et un archivage virtuels des trois étapes d'un fichier lorsque
résoudre une fusion à trois. Cette option est destinée à être utilisée lors de la fusion de branches
avec différents filtres de nettoyage ou règles de normalisation de fin de ligne. Voir "Fusionner
branches avec des attributs d'archivage/d'extraction différents" dans attributs git(5) pour
détails.

pas de renormalisation
Désactive l'option de renormalisation. Cela remplace le merge.renormalize
variable de configuration.

renommer-seuil=
Contrôle le seuil de similarité utilisé pour la détection de changement de nom. Voir également git-diff(1)
-M.

sous-arbre[= ]
Cette option est une forme plus avancée de sous-arbre stratégie, où la stratégie fait
une estimation de la façon dont deux arbres doivent être déplacés pour correspondre lors de la fusion.
Au lieu de cela, le chemin spécifié est préfixé (ou supprimé depuis le début) pour faire
la forme de deux arbres pour correspondre.

poulpe
Cela résout les cas avec plus de deux têtes, mais refuse de faire une fusion complexe qui
nécessite une résolution manuelle. Il est principalement destiné à être utilisé pour regrouper la branche thématique
tête ensemble. Il s'agit de la stratégie de fusion par défaut lors de l'extraction ou de la fusion de plus de
une branche.

le nôtre
Cela résout n'importe quel nombre de têtes, mais l'arbre résultant de la fusion est toujours celui
de la tête de branche actuelle, ignorant effectivement tous les changements de toutes les autres branches.
Il est destiné à être utilisé pour remplacer l'ancien historique de développement des branches secondaires. Noter
que cela est différent de l'option -Xours à la récursif stratégie de fusion.

sous-arbre
Il s'agit d'une stratégie récursive modifiée. Lors de la fusion des arbres A et B, si B correspond à
un sous-arbre de A, B est d'abord ajusté pour correspondre à la structure arborescente de A, au lieu de
lire les arbres au même niveau. Cet ajustement est également effectué sur le commun
arbre ancêtre.

Avec les stratégies qui utilisent la fusion à trois (y compris la stratégie par défaut, récursif), si un changement
est effectué sur les deux branches, mais plus tard annulé sur l'une des branches, ce changement sera
présent dans le résultat fusionné ; certaines personnes trouvent ce comportement déroutant. Cela se produit parce que
seules les têtes et la base de fusion sont prises en compte lors de l'exécution d'une fusion, pas la
engagements individuels. L'algorithme de fusion considère donc le changement inversé comme non
changer du tout, et remplace la version modifiée à la place.

NOTES

Vous devez comprendre les implications de l'utilisation jet rebasement sur un référentiel que vous partagez.
Voir également RÉCUPÉRATION À PARTIR D'UN REBASE EN AMONT ci-dessous.

Lorsque la commande git-rebase est exécutée, elle exécute d'abord un hook "pré-rebase" si un
existe. Vous pouvez utiliser ce crochet pour effectuer des vérifications de l'intégrité et rejeter le rebase si ce n'est pas le cas
approprié. Veuillez consulter le script de hook de pré-rebase du modèle pour un exemple.

À la fin, sera la branche actuelle.

INTERACTIF MODE

Le rebasage interactif signifie que vous avez la possibilité de modifier les commits qui sont rebasés.
Vous pouvez réorganiser les commits et vous pouvez les supprimer (en éliminant les erreurs ou autres
correctifs indésirables).

Le mode interactif est destiné à ce type de workflow :

1. avoir une idée merveilleuse

2. pirater le code

3. préparer une série à soumettre

4. soumettre

où le point 2. consiste en plusieurs instances de

a) utilisation régulière

1. terminer quelque chose digne d'un commit

2. s'engager

b) correction indépendante

1. se rendre compte que quelque chose ne fonctionne pas

2. corrigez cela

3. le commettre

Parfois, la chose fixée en b.2. ne peut pas être modifié pour le commit pas tout à fait parfait
correctifs, car ce commit est profondément enfoui dans une série de correctifs. C'est exactement ce que
le rebase interactif est pour : l'utiliser après beaucoup de "a" et de "b", en réarrangeant et
éditer les commits et écraser plusieurs commits en un seul.

Démarrez-le avec le dernier commit que vous souhaitez conserver tel quel :

git rebase -i

Un éditeur sera lancé avec tous les commits de votre branche actuelle (en ignorant la fusion
commits), qui viennent après le commit donné. Vous pouvez réorganiser les commits dans cette liste pour
le contenu de votre coeur, et vous pouvez les supprimer. La liste ressemble plus ou moins à ceci :

pick deadbee La ligne unique de ce commit
pick fa1afe1 La ligne du prochain commit
...

Les descriptions en une ligne sont purement pour votre plaisir ; jet rebasement ne les regardera pas
mais aux noms de commit ("deadbee" et "fa1afe1" dans cet exemple), donc ne supprimez pas ou
modifier les noms.

En remplaçant la commande « pick » par la commande « éditer », vous pouvez dire jet rebasement pour arrêter
après avoir appliqué ce commit, afin que vous puissiez éditer les fichiers et/ou le message de commit,
modifiez le commit et continuez à rebaser.

Si vous voulez juste éditer le message de commit pour un commit, remplacez la commande "pick" par
la commande « reformuler ».

Pour supprimer un commit, remplacez la commande "pick" par "drop", ou supprimez simplement la correspondance
ligne.

Si vous souhaitez regrouper deux ou plusieurs commits en un seul, remplacez la commande "pick" pour le
le deuxième commit et les suivants avec « squash » ou « fixup ». Si les commits étaient différents
auteurs, le commit replié sera attribué à l'auteur du premier commit. Les
le message de commit suggéré pour le commit replié est la concaténation des messages de commit
du premier commit et de ceux avec la commande "squash", mais omet les messages de commit
des commits avec la commande "fixup".

jet rebasement s'arrêtera lorsque "pick" a été remplacé par "edit" ou lorsqu'une commande échoue en raison
pour fusionner les erreurs. Lorsque vous avez terminé de modifier et/ou de résoudre les conflits, vous pouvez continuer
avec git rebase --continue.

Par exemple, si vous souhaitez réorganiser les 5 derniers commits, de sorte que ce qui était HEAD~4 devienne
la nouvelle TÊTE. Pour y parvenir, vous appelleriez jet rebasement comme ça:

$ git rebase -i HEAD~5

Et déplacez le premier patch à la fin de la liste.

Vous voudrez peut-être conserver les fusions, si vous avez un historique comme celui-ci :

X
\
A---M---B
/
---o---O---P---Q

Supposons que vous souhaitiez rebaser la branche latérale en commençant par "A" vers "Q". Assurez-vous que le
HEAD actuel est "B", et appelez

$ git rebase -i -p --onto QO

La réorganisation et la modification des commits créent généralement des étapes intermédiaires non testées. Vous voudrez peut-être
pour vérifier que votre édition d'historique n'a rien cassé en faisant un test, ou au moins
recompilation à des points intermédiaires de l'historique en utilisant la commande "exec" (raccourci "x").
Vous pouvez le faire en créant une liste de tâches comme celle-ci :

choisir deadbee Mettre en œuvre la fonctionnalité XXX
fixup f1a5c00 Correction de la fonctionnalité XXX
l'exécutif
pick c0ffeee La ligne du prochain commit
edit deadbab La seule ligne du commit après
sous-répertoire cd exec; faire un test
...

Le rebase interactif s'arrêtera lorsqu'une commande échoue (c'est-à-dire qu'elle sort avec un statut non-0) pour
vous donner l'occasion de résoudre le problème. Vous pouvez continuer avec git rebase --continue.

La commande "exec" lance la commande dans un shell (celui spécifié dans $SHELL, ou le
shell par défaut si $SHELL n'est pas défini), vous pouvez donc utiliser les fonctionnalités du shell (comme "cd", ">", ";"
...). La commande est exécutée à partir de la racine de l'arbre de travail.

$ git rebase -i --exec "faire un test"

Cette commande permet de vérifier que les commits intermédiaires sont compilables. La liste des tâches
devient comme ça :

choisissez 5928aea un
exec faire le test
choisissez 04d0fda deux
exec faire le test
choisissez ba46169 trois
exec faire le test
choisissez f4593f9 quatre
exec faire le test

SCISSION ENGAGE

En mode interactif, vous pouvez marquer les commits avec l'action "éditer". Cependant, cela ne
signifie nécessairement que jet rebasement s'attend à ce que le résultat de cette modification soit exactement un commit.
En effet, vous pouvez annuler le commit, ou vous pouvez ajouter d'autres commits. Cela peut être utilisé pour diviser un
s'engager en deux :

· Démarrer un rebase interactif avec git rebase -i ^, où est l'engagement
vous voulez diviser. En fait, n'importe quelle plage de commit fera l'affaire, tant qu'elle contient cela
s'engager.

· Marquez le commit que vous souhaitez diviser avec l'action « éditer ».

· Lorsqu'il s'agit d'éditer ce commit, exécutez git reset HEAD^. L'effet est que le
HEAD est rembobiné d'un, et l'index emboîte le pas. Cependant, l'arbre de travail reste
le même.

· Ajoutez maintenant les modifications à l'index que vous souhaitez avoir dans le premier commit. Vous pouvez
utilisez git add (éventuellement de manière interactive) ou jet gui (ou les deux) pour le faire.

· Validez l'index actuel avec le message de validation approprié maintenant.

· Répétez les deux dernières étapes jusqu'à ce que votre arbre de travail soit propre.

· Continuez le rebase avec git rebase --continue.

Si vous n'êtes pas absolument sûr que les révisions intermédiaires sont cohérentes (elles
compiler, passer la suite de tests, etc.), vous devez utiliser jet planque pour ranger le
modifications non encore validées après chaque validation, test et modification de la validation si des correctifs sont apportés
nécessaire.

RÉCUPÉRATION De EN AMONT REBASER

Rebaser (ou toute autre forme de réécriture) une branche sur laquelle d'autres ont basé leur travail est un mauvais
idée : toute personne en aval est obligée de corriger manuellement son historique. Cette section
explique comment faire le correctif du point de vue de l'aval. La vraie solution, cependant,
serait d'éviter de rebaser l'amont en premier lieu.

Pour illustrer, supposons que vous soyez dans une situation où quelqu'un développe un sous-système branche,
et vous travaillez sur un sujet qui dépend de cela sous-système. Vous pourriez vous retrouver avec
une histoire comme la suivante :

o---o---o---o---o---o---o---o---o maître
\
o---o---o---o---o sous-système
\
*---*---* sujet

If sous-système est rebasé contre maître, il se passe ce qui suit :

o---o---o---o---o---o---o---o maître
\ \
o---o---o---o---o o'--o'--o'--o'--o' sous-système
\
*---*---* sujet

Si vous continuez maintenant le développement comme d'habitude, et éventuellement fusionnez sujet à sous-système, un
s'engage de sous-système restera dupliqué pour toujours :

o---o---o---o---o---o---o---o maître
\ \
o---o---o---o---o o'--o'--o'--o'--o'--M sous-système
\ /
*---*---*-..........-*--* sujet

De tels doublons sont généralement mal vus car ils encombrent l'histoire, la rendant
plus difficile à suivre. Pour nettoyer les choses, vous devez transplanter les commits sur sujet à la
nouvelle sous-système astuce, c'est-à-dire rebase sujet. Cela devient un effet d'entraînement : toute personne en aval
grâce au sujet est obligé de rebaser aussi, et ainsi de suite !

Il existe deux types de correctifs, décrits dans les sous-sections suivantes :

Cas facile : Les changements sont littéralement les mêmes.
Cela se produit si le sous-système rebase était un simple rebase et n'avait aucun conflit.

Cas dur : Les changements ne sont pas les mêmes.
Cela se produit si le sous-système rebase avait des conflits, ou utilisé --interactive pour omettre,
modifier, écraser ou corriger les commits ; ou si l'amont en a utilisé un de commit --amend, reset,
ou filtre-branche.

Le manuel de formation facile maisons
Ne fonctionne que si les changements (ID de patch basés sur le contenu du diff) sur sous-système sommes-nous
littéralement le même avant et après le rebase sous-système fait.

Dans ce cas, la solution est simple car jet rebasement sait ignorer les changements qui sont déjà
présent dans le nouvel amont. Donc, si vous dites (en supposant que vous êtes sur sujet)

$ git rebase sous-système

vous vous retrouverez avec l'historique fixe

o---o---o---o---o---o---o---o maître
\
sous-système o'--o'--o'--o'--o'
\
*---*---* sujet

Le manuel de formation dur maisons
Les choses se compliquent si le sous-système les changements ne correspondent pas exactement à ceux
avant le rebasage.

Note
Alors qu'une « récupération facile des dossiers » semble parfois réussir, même dans les
cas, cela peut avoir des conséquences inattendues. Par exemple, un commit qui a été supprimé via
git rebase --interactive sera ressuscité!

L'idée est de dire manuellement jet rebasement "où l'ancien sous-système terminé et votre sujet
a commencé", c'est-à-dire quelle était l'ancienne base de fusion entre eux. Vous devrez trouver un moyen de
nommer le dernier commit de l'ancien sous-système, Par exemple:

· Avec le sous-système reflog : après jet rapporter, la vieille pointe de sous-système est à
sous-système@{1}. Les récupérations suivantes augmenteront le nombre. (Voir git-reflog(1).)

· Par rapport à la pointe de sujet: sachant que votre sujet a trois commits, l'ancien conseil
of sous-système doit être le sujet~3.

Vous pouvez ensuite transplanter l'ancien sous-système..sujet vers le nouveau conseil en disant (pour le reflog
cas, et en supposant que vous êtes sur sujet déjà):

$ git rebase --onto sous-système sous-système@{1}

L'effet d'entraînement d'une récupération "hard case" est particulièrement mauvais : tout le monde en aval de
sujet devra désormais également effectuer une récupération "hard case" !

Utilisez git-rebase en ligne en utilisant les services onworks.net