Pour supprimer une branche, je connais au moins ces commandes:
git branch oldbranch -d git branch oldbranch -D
La première supprime la branche si elle a été complètement fusionnée, la seconde la supprime dans tous les cas. p >
Considérons maintenant un flux de travail dans lequel une branche a été rebasée en maître, pas fusionnée. La première commande ne supprimera pas la branche (elle n'a pas été fusionnée). Le second supprimera la branche, mais il le fera dans tous les cas (même si le rebase n'a pas encore été fait). Je me demande s'il existe un moyen plus sûr de supprimer la branche, ce qui peut être:
Connaissez-vous une telle commande?
3 Réponses :
Peu de façons de marquer quel commit a été sélectionné pendant cherry-pick
cherry-pick -x Vous pouvez utiliser cherry-pick -x afin que vous ayez le commit original qui a été choisi pour le cherry-pick
git notes h3 > Utilisez git notes pour ajouter des notes (les notes ne font pas partie du SHA-1) et peuvent être supprimées ou modifiées sans affecter l'ID de validation
Une fois que vous avez les commits originaux, vous pouvez utiliser un script pour vérifier que tous les commits sont dans la branche de destination avec le
git branch --contains <commit>
Vous pouvez utiliser git-log pour savoir s'il y a des correctifs sur une branche qui n'ont pas d'équivalents sur l'autre:
git log --no-merges --cherry-pick --left-only oldbranch...master
C'est un différence symétrique avec trois points. --cherry-pick trouve les commits "cherry-pickable", ceux qui n'ont pas d'équivalent sur l'autre branche. La différence symétrique montrerait normalement les commits de l'une ou l'autre branche qui n'ont pas d'équivalents sur l'autre; --left-only lui dit de n'afficher que les commits de la branche gauche ( oldbranch , dans ce cas).
Si vous ne vous souciez pas pour voir les commits, vous pouvez remplacer git rev-list --count par git log .
Dans le cas
- dans un meilleur cas (puisque le maître peut avoir d'autres nouveaux commits) "supprimer si le maître contient des commits qui sont ~ égaux aux commits de cette branche depuis sa création" (bien sûr, il peut y avoir des problèmes avec le bit "égal" dans certains cas, mais pour les plus simples ..)
if [[ `git rev-parse master:` = `git rev-parse oldbranch:` ]]; then
echo '`oldbranch` tip identical to master tip, not bothering with rebase, deleting'
git checkout master &&
git branch -D oldbranch
else
git rebase master oldbranch &&
git checkout master &&
git branch -d oldbranch && echo oldbranch completely merged, deleting
fi
devrait le faire, rebase identifie et ignore les commits que vous avez déjà recherchés, et si ce sont tous les master et oldbranch sera le même commit, c'est-à-dire que oldbranch est déjà fusionné et que la suppression réussit.
Mais cas
- dans le pire des cas, "supprimer si la différence entre la branche actuelle et le maître est vide"
se distingue, il est possible d’être arrivé au même résultat mais avec des étapes individuelles différentes, où ce n’est que l’effet cumulatif qui correspond. La question ici est, à quoi voulez-vous que votre historique des résultats ressemble? Vous devez utiliser différentes commandes pour obtenir des résultats différents.
La séquence la plus triviale que je puisse trouver pour atteindre toutes vos desiderata est
git rebase master oldbranch git checkout master git branch -d oldbranch
et le cas qui n'est pas traité ici est de savoir si les deux bouts de branche sont arrivés à des différences cumulatives partiellement superposées et ont divisé les changements différemment, et pour cela, il vous suffit de décider quel enregistrement historique sera le plus utile. Je viens de fusionner.
ok, cela fonctionne, mais seulement si git branch --set-upstream-to = master est fait avant le rebasage. Cela fait 4 commandes; est-il possible de créer un alias en utilisant git lui-même?
Je suis désolé, je ne comprends rien à cela. Je pense qu'il serait peut-être préférable de poser une nouvelle question sur votre tentative de mise en œuvre, en faisant référence à celle-ci et en montrant exactement ce que vous regardez et en quoi son comportement diffère de ce que vous voulez et attendez, car je ne vois pas en quoi quoi que ce soit pourrait dépendre du réglage en amont ici.
Oui, vous avez probablement raison, cela mérite peut-être une nouvelle question. C'est juste sans configurer en amont que j'ai eu une erreur similaire à celle-ci stackoverflow.com/q/32056324/3995261 , mais en aliasing un ensemble des commandes est en effet un problème distinct
cette question porte sur les résultats d'une commande différente, avec des arguments différents, dans une situation différente. Veuillez publier (de préférence sous la forme d'une question distincte) des détails concrets, y compris les commandes réelles que vous émettez, montrant les résultats réels que vous obtenez, de manière à ce que d'autres puissent reproduire la situation. Les caractérisations ne sont pas des faits. "une erreur similaire à" est tout simplement l'opposé de utile.