J'ai donc effectué quelques travaux dans le référentiel et lorsque je suis sur le point de valider, je me rends compte que je ne suis actuellement sur aucune branche.
Cela se produit souvent lorsque je travaille avec des sous-modules et je suis capable de le résoudre, mais le processus est fastidieux et je pensais qu'il devait y avoir un moyen plus simple de le faire.
Existe-t-il un moyen simple de revenir dans une succursale tout en conservant les modifications?
Si vous n'avez pas commis:
git stash
git checkout some-branch
git stash pop
Si vous avez commis et n'avez rien changé depuis:
git log --oneline -n1 # this will give you the SHA
git checkout some-branch
git merge ${commit-sha}
Si vous avez commis puis effectué du travail supplémentaire:
git stash
git log --oneline -n1 # this will give you the SHA
git checkout some-branch
git merge ${commit-sha}
git stash pop
cela m'a aidé
git checkout -b newbranch
git checkout master
git merge newbranch
git branch -d newbranch
git checkout master
C'est un résultat qui ressemble à ceci:
Warning: you are leaving 2 commits behind, not connected to
any of your branches:
1e7822f readme
0116b5b returned to clean Django
If you want to keep them by creating a new branch, this may be a good time to do so with:
git branch new_branch_name 1e7822f25e376d6a1182bb86a0adf3a774920e1e
Alors faisons-le:
git merge 1e7822f25e376d6a1182bb86a0adf3a774920e1e
Partir d'une autre manière ici
git branch newbranch
git checkout master
git merge newbranch
Vous pouvez également configurer vos sous-modules de manière à extraire une branche plutôt que de rester dans leur état par défaut de la tête détachée.
Modifié pour ajouter:
Une solution consiste à extraire une branche particulière du sous-module lorsque vous l'ajoutez avec l'indicateur -b:
git submodule add -b master <remote-repo> <path-to-add-it-to>
Une autre façon consiste simplement à aller dans le répertoire du sous-module et à le vérifier
git checkout master
J'ai récemment rencontré ce problème à nouveau. Cela fait un moment que je n'ai pas travaillé pour la dernière fois avec des sous-modules et, après en avoir appris plus sur git, j'ai réalisé que le simple fait de vérifier la branche sur laquelle vous souhaitez vous engager est suffisant. Git gardera l'arbre de travail même si vous ne le cachez pas.
git checkout existing_branch_name
Si vous souhaitez travailler sur une nouvelle branche, cela devrait fonctionner pour vous:
git checkout -b new_branch_name
L'extraction échouera si vous avez des conflits dans l'arborescence de travail, mais cela devrait être assez inhabituel et si cela se produit, vous pouvez simplement la cacher, la fermer et résoudre le conflit.
Par rapport à la réponse acceptée, cette réponse vous épargnera l'exécution de deux commandes, qui ne prennent pas vraiment longtemps à s'exécuter de toute façon. Par conséquent, je n'accepterai pas cette réponse, à moins qu'elle obtienne miraculeusement plus de votes positifs (ou tout au moins près) que la réponse actuellement acceptée.
La méthode suivante peut fonctionner:
git rebase HEAD master
git checkout master
Ceci va rebaser vos HEAD changements actuels au dessus du master. Ensuite, vous pouvez changer de branche.
Une autre façon est de vérifier la branche en premier:
git checkout master
Ensuite, Git doit afficher SHA1 de vos commits détachés, vous pouvez ensuite les sélectionner, par exemple.
git cherry-pick YOURSHA1
Ou vous pouvez également fusionner le dernier:
git merge YOURSHA1
Pour voir tous vos commits de différentes branches (pour vous assurer de les avoir), exécutez: git reflog
.
Je sais que j'ai dit à babay en 2012 que je pensais qu'il était peu probable que quelqu'un réalise qu'il ne se trouve pas sur une branche et commet une erreur. Cela m'est juste arrivé, alors je suppose que je dois admettre que je me suis trompé, mais étant donné qu'il a fallu attendre 2016 pour que cela se produise, vous pourriez soutenir que c'est en fait improbable.
Quoi qu'il en soit, créer une nouvelle branche est excessif à mon avis. Tout ce que tu dois faire est:
git checkout some-branch
git merge commit-sha
Si vous n'avez pas copié le commit-sha avant de vérifier l'autre branche, vous pouvez le trouver facilement en exécutant:
git reflog
Une façon de se retrouver dans cette situation consiste à effectuer une nouvelle base depuis une branche distante. Dans ce cas, les nouveaux commits sont signalés par HEAD
mais master
ne les désigne pas - ils indiquent l'endroit où ils se trouvaient avant que vous ayez rebasé l'autre branche.
Vous pouvez faire en sorte que cela commette votre nouvelle master
en faisant:
git branch -f master HEAD
git checkout master
Ceci met forcément à jour master
pour qu'il pointe vers HEAD
(sans vous mettre sur master
) puis passe à master
.