Je voudrais rebaser sur un commit spécifique, pas sur un HEAD de l'autre branche:

A --- B --- C          master
 \
  \-- D                topic

à

A --- B --- C          master
       \
        \-- D          topic

au lieu de

A --- B --- C          master
             \
              \-- D    topic

Comment puis-je y parvenir?

Vous pouvez éviter d'utiliser le paramètre --onto en créant une branche temporaire sur le commit que vous aimez, puis en utilisant rebase sous sa forme simple:

git branch temp master^
git checkout topic
git rebase temp
git branch -d temp

Vous pouvez même adopter une approche directe:

git checkout topic
git rebase <commitB>

Utilisez l'option "sur":

git rebase --onto master^ D^ D

Le commentaire de jsz ci-dessus m'a sauvé des tonnes de douleur, alors voici une recette étape par étape basée sur celle-ci que j'ai utilisée pour rebaser / déplacer tout commit par-dessus tout autre commit:

1. Trouvez un point de branchement précédent de la branche à rebaser (déplacer) - appelez-le ancien parent. Dans l'exemple ci-dessus, c'est A
2. Trouvez le commit sur lequel vous voulez déplacer la branche - appelez-le nouveau parent. Dans l'exemple c'est B
3. Vous devez être sur votre agence (celle que vous déménagez):
4. Appliquez votre rebase: git rebase --onto <new parent> <old parent>

Dans l'exemple ci-dessus, c'est aussi simple que:

   git checkout topic
   git rebase --onto B A

Sujet Solution

La commande correcte pour répondre à la question posée peut être l'une des suivantes (en supposant que la branche topicest déjà extraite):

git rebase --onto B master
git rebase --onto master~1 master
git rebase --onto B A
git rebase --onto B C
git rebase --onto B

Si topicn'est pas extrait, vous ajoutez simplement topicà la commande (sauf la dernière) comme suit:

git rebase --onto B master topic

Sinon, vérifiez d'abord la branche avec:

git checkout topic

Rebase toute chaîne de validations vers une validation cible

La forme de base de la commande dont nous avons besoin, tirée de la documentation, est:

git rebase --onto <Target> [<Upstream> [<Branch>]]

<Branch>est facultatif et il ne fait que vérifier la branche spécifiée avant d'exécuter le reste de la commande. Si vous avez déjà extrait la branche que vous souhaitez rebase, vous n'en avez pas besoin. Notez que vous devez avoir spécifié <Upstream>pour spécifier <Branch>ou git pensera que vous spécifiez <Upstream>.

<Target>est le commit auquel nous attacherons notre chaîne de commits. Lorsque vous fournissez un nom de branche, vous spécifiez simplement le commit principal de cette branche. <Target>peut être n'importe quel commit qui ne sera pas contenu dans la chaîne de commits déplacés. Par exemple:

A --- B --- C --- D         master
      \
       \-- X --- Y --- Z    feature

Pour déplacer l'ensemble de la branche de fonction, vous ne pouvez pas sélectionner X, Y, Zou featurecomme <Target>puisque ce sont tous les commits à l' intérieur du groupe déplacé.

<Upstream>est spécial car cela peut signifier deux choses différentes. S'il s'agit d'un commit qui est un ancêtre de la branche extraite, alors il sert de point de coupure. Dans l'exemple que j'ai fourni, ce serait tout ce qui est pas C, Dou master. Tous les commits après<Upstream> jusqu'à ce que la tête de la branche extraite soient ceux qui seront déplacés.

Cependant, si <Upstream>n'est pas un ancêtre, alors git sauvegarde la chaîne à partir du commit spécifié jusqu'à ce que if trouve un ancêtre commun avec la branche extraite (et abandonne s'il n'en trouve pas). Dans notre cas, un <Upstream>de B, C, Dou mastergenerera COMMIT Bservant de point de coupe. <Upstream>est elle-même une commande facultative et si elle n'est pas spécifiée, alors git regarde le parent de la branche extraite, ce qui équivaut à entrermaster .

Maintenant que git a sélectionné les commits qu'il va couper et déplacer, il les applique dans l'ordre <Target>, en ignorant ceux qui sont déjà appliqués à la cible.

Exemples et résultats intéressants

En utilisant ce point de départ:

A --- B --- C --- D --- E         master
            \
             \-- X --- Y --- Z    feature

• git rebase --onto D A feature
  Appliquera commits B, C, X, Y, Zde commettre Det finissent par sauter Bet Cparce qu'ils ont déjà été appliquées.

• git rebase --onto C X feature
  Appliquera les commits Yet Zs'engagera C, supprimant effectivement le commitX

Une solution plus simple est git rebase <SHA1 of B> topic. Cela fonctionne indépendamment de l'endroit où vous vous trouvez HEAD.

Nous pouvons confirmer ce comportement à partir de git rebase doc

<upstream>Branche en amont à comparer. Peut être n'importe quel commit valide , pas seulement un nom de branche existant. Par défaut, l'amont configuré pour la branche actuelle.

git rebase <SHA1 of B> <SHA1 of topic>

Cela fonctionnera également, mais le rebase ne fera pas Topicpointer vers la nouvelle branche ainsi créée et HEADsera à l'état détaché. Donc, à partir de là, vous devez supprimer manuellement l'ancienne Topicet créer une nouvelle référence de branche sur la nouvelle branche créée par rebase.

J'ai utilisé un mélange de solutions décrites ci-dessus:

$ git branch temp <specific sha1>
$ git rebase --onto temp master topic
$ git branch -d temp

J'ai trouvé cela beaucoup plus facile à lire et à comprendre. La solution acceptée m'a conduit à un conflit de fusion (trop paresseux pour être résolu à la main):

$ git rebase temp
First, rewinding head to replay your work on top of it...
Applying: <git comment>
Using index info to reconstruct a base tree...
M       pom.xml
.git/rebase-apply/patch:10: trailing whitespace.
    <some code>
.git/rebase-apply/patch:17: trailing whitespace.
        <some other code>
warning: 2 lines add whitespace errors.
Falling back to patching base and 3-way merge...
Auto-merging pom.xml
CONFLICT (content): Merge conflict in pom.xml
error: Failed to merge in the changes.
Patch failed at 0001 <git comment>
The copy of the patch that failed is found in: .git/rebase-apply/patch

When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort".

Puisque le rebasage est si fondamental, voici une extension de la réponse de Nestor Milyaev . Combinaison des commentaires de jsz et de Simon South à partir de la réponse d' Adam Dymitruk donne cette commande qui fonctionne sur la topicbranche indépendamment du fait qu'elle se branche à partir masterdu commit de la branche Aou C:

git checkout topic
git rebase --onto <commit-B> <pre-rebase-A-or-post-rebase-C-or-base-branch-name>

Notez que le dernier argument est obligatoire (sinon, il rembobine votre branche pour valider B ).

Exemples:

# if topic branches from master commit A:
git checkout topic
git rebase --onto <commit-B> <commit-A>

# if topic branches from master commit C:
git checkout topic
git rebase --onto <commit-B> <commit-C>

# regardless of whether topic branches from master commit A or C:
git checkout topic
git rebase --onto <commit-B> master

Donc, la dernière commande est celle que j'utilise généralement.

Il existe une autre façon de le faire ou si vous souhaitez revenir à plus d'un seul commit.

Voici un exemple pour revenir au nnombre de commits:

git branch topic master~n

Pour répondre à cette question, cela peut également être fait:

git branch topic master~1

La commande fonctionne parfaitement git version 2.7.4. Je ne l'ai testé sur aucune autre version.