Question Comment copier commet d'une branche à l'autre?


J'ai deux branches de mon maître:

  • v2.1: (version 2) Je travaille depuis plusieurs mois
  • wss: que j'ai créé hier pour ajouter une fonctionnalité spécifique à mon maître (en production)

Y a-t-il un moyen de copier les commits d'hier de wss à v2.1?


501
2018-03-19 00:51


origine


Réponses:


Vous devriez vraiment avoir un workflow qui vous permet de faire tout cela en fusionnant:

- x - x - x (v2) - x - x - x (v2.1)
           \
            x - x - x (wss)

Donc tout ce que vous avez à faire est git checkout v2.1 et git merge wss. Si pour une raison quelconque vous ne pouvez vraiment pas faire cela, et vous ne pouvez pas utiliser git rebase pour déplacer votre branche wss au bon endroit, la commande pour attraper un seul commit de quelque part et l'appliquer ailleurs est Git cerise. Vérifiez la branche sur laquelle vous voulez l'appliquer et exécutez git cherry-pick <SHA of commit to cherry-pick>.

Certains des moyens de rebase pourraient vous sauver:

Si votre histoire ressemble à ceci:

- x - x - x (v2) - x - x - x (v2.1)
           \
            x - x - x (v2-only) - x - x - x (wss)

Vous pourriez utiliser git rebase --onto v2 v2-only wss pour déplacer wss directement sur v2:

- x - x - x (v2) - x - x - x (v2.1)
          |\
          |  x - x - x (v2-only)
           \
             x - x - x (wss)

Ensuite, vous pouvez fusionner! Si vraiment, vraiment, vraiment ne peut pas arriver au point où vous pouvez fusionner, vous pouvez toujours utiliser rebase pour effectuer efficacement plusieurs choix de cerises à la fois:

# wss-starting-point is the SHA1/branch immediately before the first commit to rebase
git branch wss-to-rebase wss
git rebase --onto v2.1 wss-starting-point wss-to-rebase
git checkout v2.1
git merge wss-to-rebase

Note: la raison pour laquelle cela demande un travail supplémentaire pour cela est que cela crée des commits en double dans votre référentiel. Ce n’est pas vraiment une bonne chose - l’intérêt de la création de succursales et de fusions est de pouvoir tout faire en regroupant les engagements et en les fusionnant là où ils sont nécessaires. Les commits en double signifient une intention de ne jamais fusionner ces deux branches (si vous décidez que vous voulez plus tard, vous aurez des conflits).


419
2018-03-19 00:59



Utilisation

git cherry-pick <commit>

appliquer <commit> à ton branche actuelle.

Je vérifierais probablement moi-même les commits que je choisis gitk et choisissez-les avec un clic droit sur l'entrée de validation à la place.


Si vous voulez aller plus automatique (avec tous ses dangers) et en supposant que tous les commits depuis hier sont sur wss, vous pouvez générer la liste des commits en utilisant git log avec (--pretty suggéré par Jefromi)

git log --reverse --since=yesterday --pretty=%H

donc tout ensemble en supposant que vous utilisez bash

for commit in $(git log --reverse --since=yesterday --pretty=%H);
do
    git cherry-pick $commit
done

Si quelque chose se passe mal ici (il y a beaucoup de potentiel), vous avez des problèmes car cela fonctionne sur le checkout en direct, donc faites des choix de cerises ou utilisez rebase comme suggéré par Jefromi.


645
2018-03-19 01:22



Vous pourriez créer un patch des commits que vous voulez copier et appliquer le patch à la succursale de destination.


12
2018-03-19 00:55



Ou si tu es un peu moins du côté de l'évangéliste Tu peux faire un peu la mauvaise route que j'utilise. Dans deploy_template, il y a des commits que je veux copier sur mon maître en tant que déploiement de branche

git branch deploy deploy_template
git checkout deploy
git rebase master

Cela créera un nouveau déploiement de branche (j'utilise -f pour écraser la branche de déploiement existante) sur deploy_template, puis rebase cette nouvelle branche sur master, en laissant plaqué deploy_template.


8
2017-12-14 22:18