Comment fusionner mes modifications locales non validées dans une autre branche Git ?

Question

Comment puis-je faire ce qui suit dans Git ?

Ma branche actuelle est branch1 et j'ai fait quelques changements locaux. Cependant, je me rends compte que je devais en fait appliquer ces modifications à la branche 2. Existe-t-il un moyen d'appliquer/fusionner ces modifications pour qu'elles deviennent des modifications locales sur la branche 2 sans les valider sur la branche 1 ?

Answer 1

Puisque vos fichiers ne sont pas encore livrés dans branch1 :

git stash
git checkout branch2
git stash pop

o

git stash
git checkout branch2
git stash list       # to check the various stash made in different branch
git stash apply x    # to select the right one

Le texte ci-dessus est la version plus longue et plus explicite de rbento 's réponse :

git stash
git stash branch branch2

Il utilise :

git stash branch <branchname> [<stash>]

• Crée et extrait une nouvelle branche nommée <branchname> à partir du commit auquel le <stash> a été créé à l'origine,
• <stash> vers le nouvel arbre de travail et l'index.

Si cela réussit, et <stash> est une référence de la forme stash@{<revision>} il abandonne ensuite la <stash> .

Ceci est utile si la branche sur laquelle vous avez exécuté git stash push a suffisamment changé pour que git stash apply échoue en raison de conflits.
Puisque l'entrée dans la cachette est appliquée par-dessus le commit qui était HEAD à l'époque git stash a été exécuté, il restaure l'état originellement stocké sans conflits.

---

Tel que commenté por benjohn (voir git stash page de manuel ) :

Pour stocker également les fichiers actuellement non suivis (nouvellement ajoutés), ajoutez l'argument -u donc :

git stash -u

Answer 2

La mise en cachette, les commits temporaires et le rebasage peuvent tous être excessifs. Si vous n'avez pas encore ajouté les fichiers modifiés à l'index, vous pouvez vous contenter de vérifier l'autre branche.

git checkout branch2

Cela fonctionnera tant qu'aucun fichier que vous éditez n'est différent entre la branche 1 et la branche 2. Cela vous laissera sur la branche 2 avec vos modifications de travail préservées. S'ils sont différents, vous pouvez alors spécifier que vous voulez fusionner vos changements locaux avec les changements introduits par le changement de branche avec l'attribut -m pour passer à la caisse.

git checkout -m branch2

Si vous avez ajouté des modifications à l'index, vous voudrez d'abord annuler ces modifications avec une réinitialisation. (Cela préservera votre copie de travail, cela supprimera simplement les modifications mises en scène).

git reset

Answer 3

Une alternative plus courte à la réponse acceptée serait :

Déplacez temporairement les modifications dans une cachette.

1. git stash

Créez et passez à une nouvelle branche, puis placez-y la cachette en une seule étape.

2. git stash branch new_branch_name

Ensuite, juste add y commit les changements dans cette nouvelle branche.

Answer 4

AVERTISSEMENT : Pas pour les novices de Git.

Cela se produit souvent dans mon travail et j'ai presque essayé d'écrire une nouvelle commande git pour cela. La commande habituelle git stash le flux est la voie à suivre mais est un peu gênant. J'ai l'habitude de faire un nouveau commit d'abord puisque si j'ai regardé les changements, toutes les informations sont fraîches dans mon esprit et c'est mieux de commencer git commit -envoie immédiatement ce que j'ai trouvé (généralement une correction de bogue appartenant à master que je découvre en travaillant sur une branche de fonctionnalité).

Il est également utile, si vous rencontrez souvent ce genre de situation, d'avoir un autre répertoire de travail à côté de votre actuel qui a toujours le master branche vérifiée.

Voici comment j'y parviens :

1. git commit les changements tout de suite avec un bon message commit.
2. git reset HEAD~1 pour annuler le commit de la branche courante.
3. (facultatif) continuer à travailler sur la fonctionnalité.

Parfois plus tard (de manière asynchrone), ou immédiatement dans une autre fenêtre du terminal :

1. cd my-project-master qui est un autre WD partageant la même .git
2. git reflog pour trouver le correctif que je viens de faire.
3. git cherry-pick SHA1 de l'engagement.

En option (toujours de manière asynchrone), vous pouvez ensuite rebaser (ou fusionner) votre branche de fonctionnalités pour obtenir le correctif, généralement lorsque vous êtes sur le point de soumettre un PR et que vous avez déjà nettoyé votre branche de fonctionnalités et votre WD :

1. cd my-project qui est le principal DEO sur lequel je travaille.
2. git rebase master pour obtenir les corrections de bogues.

De cette façon, je peux continuer à travailler sur la fonctionnalité sans interruption et sans avoir à me soucier de git stash -ou d'avoir à nettoyer mon WD avant une git checkout (et ensuite devoir vérifier la branche des fonctionnalités à nouveau.) et avoir toujours toutes mes corrections de bogues qui vont à master au lieu d'être caché dans ma branche de fonctionnalité.

OMI git stash y git checkout est un véritable casse-tête lorsque vous êtes en train de travailler sur une fonctionnalité importante.

Answer 5

Les réponses données jusqu'à présent ne sont pas idéales parce qu'elles exigent beaucoup de travail inutile pour résoudre les conflits de fusion, ou parce qu'elles font trop d'hypothèses qui sont souvent fausses. Voici comment le faire parfaitement. Le lien renvoie à mon propre site.

Comment s'engager sur une branche différente dans git ?

Vous avez des changements non validés sur my_branch que vous voulez engager master sans valider toutes les modifications apportées par my_branch .

Exemple

git merge master
git stash -u
git checkout master
git stash apply
git reset
git add example.js
git commit
git checkout .
git clean -f -d
git checkout my_branch
git merge master
git stash pop

Explication

Commencez par fusionner master dans votre branche, puisque vous devrez le faire de toute façon, et que c'est le meilleur moment pour résoudre les conflits.

El -u (alias --include-untracked ) en git stash -u vous empêche de perdre des fichiers non suivis lorsque vous faites plus tard git clean -f -d sur master .

Après git checkout master il est important que vous NE git stash pop car vous aurez besoin de cette réserve plus tard. Si vous faites sauter la réserve créée dans my_branch et ensuite faire git stash en master vous provoquerez d'inutiles conflits de fusion lorsque vous appliquerez ultérieurement cette réserve dans le programme my_branch .

git reset déstabilise tout ce qui résulte de git stash apply . Par exemple, les fichiers qui ont été modifiés dans la cachette mais qui n'existent pas dans le fichier master sont mis en scène comme des conflits "supprimés par nous".

git checkout . y git clean -f -d jeter tout ce qui n'est pas validé : toutes les modifications des fichiers suivis, et tous les fichiers et répertoires non suivis. Ils sont déjà sauvegardés dans la cachette et s'ils sont laissés dans le fichier master provoquerait des conflits de fusion inutiles lors du retour à l'application my_branch .

La dernière git stash pop sera basé sur l'original my_branch et ne provoquera donc aucun conflit de fusion. Cependant, si votre stash contient des fichiers non suivis que vous avez commis sur master, git se plaindra qu'il "n'a pas pu restaurer les fichiers non suivis du stash". Pour résoudre ce conflit, supprimez ces fichiers de votre arbre de travail, puis git stash pop , git add . y git reset .