J'ai la branche master
qui suit la branche distante Origin/master
.
Je veux les renommer en master-old
localement et sur la télécommande. Est-ce possible? Pour les autres utilisateurs ayant suivi Origin/master
(et ayant toujours mis à jour leur branche master
locale via git pull
), que se passerait-il après le changement de nom de la branche distante? Est-ce que leur git pull
fonctionnerait toujours ou si cela signifiait qu'il ne pourrait plus trouver Origin/master
?
Ensuite, je souhaite créer une nouvelle branche master
(localement et à distance). Encore une fois, après avoir fait cela, que se passerait-il maintenant si les autres utilisateurs faisaient git pull
?
Je suppose que tout cela créerait beaucoup de problèmes. Existe-t-il un moyen propre d'obtenir ce que je veux? Ou devrais-je simplement laisser master
en l'état et créer un nouveau code master-new
et y travailler plus loin?
La chose la plus proche de renommer est la suppression puis la recréation sur la télécommande. Par exemple:
git branch -m master master-old
git Push remote :master # delete master
git Push remote master-old # create master-old on remote
git checkout -b master some-ref # create a new local master
git Push remote master # create master on remote
Cependant, cela a beaucoup de mises en garde. Tout d’abord, aucune extraction existante n’aura connaissance du changement de nom - git fait pas tente de suivre les renommements de branche. Si la nouvelle master
n'existe pas encore, git pull affichera une erreur. Si la nouvelle master
a été créée. le pull tentera de fusionner master
et master-old
. C'est donc généralement une mauvaise idée, sauf si vous avez la coopération de tous ceux qui ont déjà consulté le référentiel.
Remarque: les versions plus récentes de git ne vous permettront pas de supprimer la branche principale à distance par défaut. Vous pouvez remplacer cela en définissant la valeur de configuration receive.denyDeleteCurrent
sur warn
ou ignore
sur le référentiel remote . Sinon, si vous êtes prêt à créer un nouveau maître immédiatement, ignorez l'étape git Push remote :master
et passez --force
à l'étape git Push remote master
. Notez que si vous ne parvenez pas à modifier la configuration de la télécommande, vous ne pourrez pas supprimer complètement la branche principale!
Cette mise en garde ne s'applique qu'à la branche actuelle (généralement la branche master
); toute autre branche peut être supprimée et recréée comme ci-dessus.
En supposant que vous soyez actuellement sur master
:
git Push Origin master:master-old # 1
git branch master-old Origin/master-old # 2
git reset --hard $new_master_commit # 3
git Push -f Origin # 4
master-old
dans le référentiel Origin
, à partir de la validation master
dans le référentiel local.Origin/master-old
(qui sera automatiquement configurée correctement en tant que branche de suivi).master
locale vers la validation sur laquelle vous voulez qu'elle pointe.master
dans le référentiel Origin
afin de refléter votre nouveau master
local.(Si vous le faites de toute autre manière, vous avez besoin d'au moins une étape supplémentaire pour vous assurer que master-old
est correctement configuré pour suivre Origin/master-old
. Aucune des autres solutions publiées au moment de la rédaction de cet article n'inclut cela.)
Avec Git v1.7, je pense que cela a légèrement changé. Mettre à jour la référence de suivi de votre agence locale vers la nouvelle télécommande est maintenant très facile.
git branch -m old_branch new_branch # Rename branch locally
git Push Origin :old_branch # Delete the old branch
git Push --set-upstream Origin new_branch # Push the new branch, set local branch to track the new remote
git checkout -b new-branch-name
git Push remote-name new-branch-name :old-branch-name
Vous devrez peut-être passer manuellement à new-branch-name
avant de supprimer old-branch-name
Il existe de nombreuses façons de renommer la branche, mais je vais me concentrer sur le problème le plus important: "Comment permettre aux clients d’avancer rapidement sans avoir à manipuler leurs branches localement".
C'est quelque chose de vraiment facile à faire; mais n'abusez pas de cela… .. Toute l'idée repose sur la fusion des commits; car ils permettent d’avancer rapidement et de lier l’historique d’une branche à une autre.
# rename the branch "master" to "master-old"
# this works even if you are on branch "master"
git branch -m master master-old
# create master from new starting point
git branch master <new-master-start-point>
# now we've got to fix the new branch...
git checkout master
# ... by doing a merge commit that obsoletes
# "master-old" hence the "ours" strategy.
git merge -s ours master-old
git Push Origin master
Cela fonctionne car la création d'un commit merge
permet à fast-forwarding de relier la branche à une nouvelle révision.
renamed branch "master" to "master-old" and use commit ba2f9cc as new "master"
-- this is done by doing a merge commit with "ours" strategy which obsoletes
the branch.
these are the steps I did:
git branch -m master master-old
git branch master ba2f9cc
git checkout master
git merge -s ours master-old
Je suppose que vous parlez toujours de la même situation que dans votre question précédente . Autrement dit, maître-nouveau ne contiendra pas ancien-maître dans son historique. * Si vous appelez maître-nouveau "maître", vous aurez effectivement réécrit l’historique. Peu importe comment vous entrez dans un état dans lequel maître n'est pas un descendant d'un poste précédent de maître, mais simplement qu'il se trouve dans cet état.
Les autres utilisateurs qui essaient d'extraire un maître alors que celui-ci n'existe pas auront simplement leur échec (aucune référence de ce type sur la télécommande), et une fois que ce dernier existera à un nouvel endroit, ils devront essayer de fusionner leur maître avec le nouveau maître distant comme si vous aviez fusionné master-old et master-new dans votre référentiel. Compte tenu de ce que vous essayez de faire ici, la fusion engendrerait des conflits. (S'ils étaient résolus et que le résultat était renvoyé dans le référentiel, vous seriez dans un état encore pire: les deux versions de l'historique là-bas.)
Pour répondre simplement à votre question: vous devez accepter le fait que votre histoire comportera parfois des erreurs. C'est d'accord. Ça arrive à tout le monde. Il y a des commits annulés dans le référentiel git.git. L'important est qu'une fois que nous publions notre histoire, tout le monde puisse avoir confiance.
* Si c'était le cas, cela reviendrait à appliquer certaines modifications au maître, puis à créer une nouvelle branche à son emplacement précédent. Aucun problème.
Le réponse sélectionnée a échoué quand je l’ai essayée. Il génère une erreur: refusing to delete the current branch: refs/heads/master
. Je suppose que je posterai ce qui fonctionne pour moi:
git checkout master # if not in master already
git branch placeholder # create placeholder branch
git checkout placeholder # checkout to placeholder
git Push remote placeholder # Push placeholder to remote repository
git branch -d master # remove master in local repository
git Push remote :master # remove master from remote repository.
L'astuce consiste à vérifier dans l'espace réservé juste avant de le placer dans le référentiel distant. Le reste est explicite, supprimer la branche master et le placer dans le référentiel distant devrait fonctionner maintenant. Extrait de ici .
Bien. Mes 2 centimes Que diriez-vous de vous connecter au serveur, d’accéder au répertoire git et de renommer la branche dans le référentiel nu? Cela ne pose pas tous les problèmes associés à la remise en ligne de la même branche. En réalité, les «clients» reconnaîtront automatiquement le nom modifié et changeront leur référence distante. Ensuite (ou avant), vous pouvez également modifier le nom local de la branche.
Qu'en est-il de:
git checkout old-branch-name
git Push remote-name new-branch-name
git Push remote-name :old-branch-name
git branch -m new-branch-name
C'est la manière la plus simple et la plus lisible que je connaisse:
git branch -m my_old_branch_name my_new_branch_name
git Push Origin -u my_new_branch_name
(le réglage "en amont" connecte "essentiellement" votre branche locale à la télécommande, de sorte que des opérations telles que fetch, pull et push fonctionnent)
git Push Origin -D <old_name>
(votre agence locale est déjà partie, car vous l'avez déplacée dans la 1ère étape)
OK, renommer une branche à la fois localement et sur la télécommande est assez facile! ...
Si vous êtes sur la branche, vous pouvez facilement faire:
git branch -m <branch>
ou sinon, vous devez faire:
git branch -m <your_old_branch> <your_new_branch>
Ensuite, poussez la suppression vers la télécommande comme ceci:
git Push Origin <your_old_branch>
Maintenant que vous avez terminé, si vous rencontrez une erreur en amont pendant que vous essayez de Push, procédez simplement:
git Push --set-upstream Origin <your_new_branch>
J'ai également créé l'image ci-dessous pour afficher les étapes en ligne de commande réelle, il suffit de suivre les étapes et vous seriez bon:
Vous pouvez faire ce qui suit:
git -m master master-old #rename current master
git checkout -b master #create a new branch master
git Push -f Origin master #force Push to master
Mais forcer est une mauvaise idée si d'autres personnes partagent ce référentiel. Force Push entraînera un conflit entre l'historique de révision et le nouveau.
Les éléments suivants peuvent être enregistrés dans le script Shell pour effectuer le travail:
Par exemple:
remote="Origin"
if [ "$#" -eq 0 ] # if there are no arguments, just quit
then
echo "Usage: $0 oldName newName or $0 newName" >&2
exit 1
Elif
[ "$#" -eq 1 ] # if only one argument is given, rename current branch
then
oldBranchName="$(git branch | grep \* | cut -d ' ' -f2)" #save current branch name
newBranchName=$1
else
oldBranchName=$1
newBranchName=$2
fi
git branch -m $oldBranchName $newBranchName
git Push $remote :$oldBranchName #delete old branch on remote
git Push --set-upstream $remote $newBranchName # add new branch name on remote and track it
Veuillez noter qu'ici le nom distant par défaut "Origin" est codé en dur, vous pouvez étendre le script pour qu'il soit configurable!
Ensuite, ce script peut être utilisé avec des alias bash, des alias git ou, par exemple, dans des actions personnalisées sourcetree.