Comment copier des commits d'une branche à l'autre?
j'ai deux branches de mon maître:
- v2.1 : (version 2) j'ai travaillé pendant plusieurs mois", 151960920"
- wss : que j'ai créé hier pour ajouter une caractéristique spécifique à mon maître (en production)
Est-il un moyen de copier hier s'engage à partir de wss pour v2.1?
6 réponses
vous devriez vraiment avoir un flux de travail 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 saisir une seule propagation de quelque part et l'appliquer ailleurs est git cherry-pick . Il suffit de vérifier la branche que vous voulez appliquer il est allumé, et exécute git cherry-pick <SHA of commit to cherry-pick> .
Certaines façons de rebase pourrait 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 pouvez 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)
alors vous pouvez fusionner! Si vous vraiment, vraiment, vraiment ne peut pas arriver au point où vous pouvez fusionner, vous pouvez toujours utiliser rebase pour faire efficacement plusieurs choix à 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 il faut un peu de travail supplémentaire pour faire cela est qu'il crée des propagations dupliquées dans votre dépôt. Ce n'est pas vraiment une bonne chose - le but de brancher et fusionner facilement est d'être capable de tout faire en faisant des commits(s) un seul endroit et en les fusionnant là où ils sont nécessaires. Dupliquer s'engage signifie une intention de ne jamais fusionner ces deux branches (si vous décidez que vous voulez plus tard, vous obtiendrez des conflits).
Utiliser
git cherry-pick <commit>
pour appliquer <commit> à votre branche courante .
moi-même je croiserais probablement les commits que je choisis dans gitk et les choisir avec des clics droits sur l'entrée de commit là à la place.
si vous voulez aller plus automatique (avec tous ses dangers) et en supposant tout commet depuis hier s'est produit sur wss vous pourriez 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 ya beaucoup de potentiel) vous êtes en difficulté depuis que cela fonctionne sur la caisse en direct, donc soit faire des sélections manuelles ou utiliser rebase comme suggéré par Jefromi.
vous pouvez créer un patch à partir des commits que vous voulez copier et appliquer le patch à la branche de destination.
git cherry-pick : appliquer les changements introduits par certains commits existants
supposons que nous avons la branche A avec (X, Y, Z) commits. Nous devons ajouter ces commits à la branche B . Nous allons utiliser les opérations cherry-pick .
lorsque nous utilisons cherry-pick , nous devrions ajouter commits on branch B dans le même ordre chronologique que les commits apparaissent dans Branch Un .
cherry-pick ne supporte une gamme de commits, mais si vous avez la fusion commits dans cette gamme, il devient vraiment compliqué
git checkout B
git cherry-pick SHA-COMMIT-X
git cherry-pick SHA-COMMIT-Y
git cherry-pick SHA-COMMIT-Z
exemple de flux de travail:
nous pouvons utiliser cherry-pick avec options
-e ou --edit : Avec cette option, git cherry-pick vous permettra d'éditer le message de propagation avant de le propager.
-n ou --no-commit : en général, la commande crée automatiquement une séquence de commits. Cette option applique les modifications nécessaires pour sélectionner chaque commit dans votre arborescence de travail et dans l'index, sans faire de commit. De plus, lorsque cette option est utilisée, votre index n'a pas à correspondre à la propagation en tête. Le pic à Cerise est fait contre l'état de début de votre index.
voici un intéressant article concernant cherry-pick .
ou si vous êtes un peu moins du côté de l'évangéliste, vous pouvez faire un peu moche de la façon que j'utilise. Dans deploy_template il y a des commits que je veux copier sur mon master en tant que branche déployer
git branch deploy deploy_template
git checkout deploy
git rebase master
cela créera une nouvelle branche deploy (j'utilise-f pour écraser la branche deploy existante) sur deploy_template, puis rebaser cette nouvelle branche sur master, laissant deploy_template intact.
pour le cas simple de copier la dernière propagation de la branche wss vers v2.1, vous pouvez simplement saisir l'ID de propagation ( git log --oneline | head -n 1 ) et faire:
git checkout v2.1
git merge <commit>