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

Comment est-ce que je peux le faire dans git:

Ma twig actuelle est la twig 1 et j’ai apporté quelques modifications locales. Cependant, je me rends compte maintenant que je voulais réellement appliquer ces modifications à branch2. Existe-t-il un moyen d’appliquer / fusionner ces modifications pour qu’elles deviennent des modifications locales sur branch2 sans les valider sur branch1?

Comme vos fichiers ne sont pas encore branch1 dans branch1 :

 git stash git checkout branch2 git stash pop 

ou

 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 

Comme commenté par benjohn (voir la page de manuel de git stash ):

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

 git stash -u 

Le stockage, les commits temporaires et le rebasage peuvent être excessifs. Si vous n’avez pas encore ajouté les fichiers modifiés à l’index, vous pourrez peut-être simplement extraire l’autre twig.

 git checkout branch2 

Cela fonctionnera tant qu’aucun fichier en cours de modification n’est différent entre branch1 et branch2. Il vous laissera sur branch2 avec vos changements de travail préservés. S’ils sont différents, vous pouvez spécifier que vous souhaitez fusionner vos modifications locales avec les modifications introduites en changeant de twig avec l’option -m .

 git checkout -m branch2 

Si vous avez ajouté des modifications à l’index, vous devez d’abord annuler ces modifications avec une réinitialisation. (Cela préservera votre copie de travail, il supprimera simplement les modifications par étapes).

 git reset 

Voici une alternative plus courte à l’approche de cache mentionnée précédemment:

Déplacer temporairement les modifications dans une réserve.

git stash

Créez et basculez vers une nouvelle twig, puis placez-y le cache en une seule étape.

git stash branch new_branch_name

Puis add et commit les modifications sur cette nouvelle twig.

AVERTISSEMENT: pas pour les débutants git.

Cela vient assez dans mon stream de travail que j’ai presque essayé d’écrire une nouvelle commande git pour cela. Le stream de git stash habituel de git stash est la voie à suivre mais est un peu gênant. Je commence généralement par faire un nouveau commit car si j’ai regardé les changements, toutes les informations sont fraîches dans mon esprit et il vaut mieux commencer par git commit -ing ce que j’ai trouvé (généralement un bug appartenant à master que je découvre en travaillant) sur une twig) immédiatement.

Il est également utile – si vous rencontrez des situations comme celle-ci – d’avoir un autre répertoire de travail à côté de votre répertoire actuel, qui a toujours la twig principale extraite.

Donc, comment j’y parviens comme suit:

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

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

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

Eventuellement (toujours asynchrone), vous pouvez ensuite rebaser (ou fusionner) votre twig de fonctionnalités pour obtenir la correction de bogue, généralement lorsque vous êtes sur le sharepoint soumettre un PR et que vous avez déjà nettoyé votre twig de fonctionnalité et WD:

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

De cette façon, je peux continuer à travailler sur la fonctionnalité sans interruption et ne pas avoir à me soucier de rien, ni devoir nettoyer mon WD avant une git checkout (puis vérifier à nouveau la twig de fonctionnalités) et avoir toutes mes corrections de bugs. va au master au lieu d’être caché dans ma twig.

IMO git stash and git checkout est une véritable PIA lorsque vous êtes en train de travailler sur une fonctionnalité importante.

S’il s’agissait de modifications validées, vous devriez jeter un oeil à git-rebase, mais comme le fait remarquer VonC dans ses commentaires, alors que vous parlez de modifications locales, git-stash serait certainement le bon moyen d’y parvenir.

Les réponses données jusqu’à présent ne sont pas idéales car elles nécessitent beaucoup de travail inutile pour résoudre les conflits de fusion, ou elles font trop d’hypothèses souvent fausses. C’est comment le faire parfaitement. Le lien est sur mon propre site.

Comment s’engager dans une twig différente de git

Vous avez des modifications non validées sur my_branch que vous souhaitez engager pour master , sans valider toutes les modifications de 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 twig, car vous devrez le faire de toute façon, et c’est le meilleur moment pour résoudre les conflits.

L’option -u (aka --include-untracked ) de git stash -u vous évite de perdre des fichiers non suivis lorsque vous exécuterez git clean -f -d dans master plus tard.

Après git checkout master il est important que vous ne fassiez pas de git stash pop , car vous aurez besoin de ce cache plus tard. Si vous my_branch créé dans my_branch et que vous le my_branch dans master , vous provoquerez des conflits de fusion inutiles lorsque vous appliquerez ultérieurement ce my_branch dans my_branch .

git reset désactive tout ce qui résulte de git stash apply . Par exemple, les fichiers modifiés dans le cache mais qui n’existent pas dans master sont mis en scène comme des conflits “supprimés par nous”.

git checkout . et git clean -f -d efface tout ce qui n’est pas commis: toutes les modifications apscopes aux fichiers suivis et tous les fichiers et répertoires non suivis. Ils sont déjà enregistrés dans le cache et s’ils sont laissés dans le master ils provoqueraient des conflits de fusion inutiles lors du retour à my_branch .

Le dernier git stash pop sera basé sur l’original my_branch et ne causera donc aucun conflit de fusion. Cependant, si votre stash contient des fichiers non suivis que vous avez commis en tant que fichiers maîtres, git se plaindra de ce qu’il “ne puisse pas restaurer les fichiers non suivis depuis les caches”. Pour résoudre ce conflit, supprimez ces fichiers de votre arborescence de travail, puis git stash pop , git add . , et git reset .