Renommer la branche principale pour les référentiels Git locaux et distants

J'ai la branche masterqui suit la branche distante origin/master.

Je veux les renommer master-oldlocalement et sur la télécommande. Est-ce possible?

Pour les autres utilisateurs qui ont suivi origin/master(et qui ont toujours mis à jour leur masterbranche locale via git pull), que se passerait-il après avoir renommé la branche distante?
Est-ce que cela git pullfonctionnerait encore ou lancerait-il une erreur qu'il ne pourrait plus trouver origin/master?

Ensuite, plus loin, je veux créer une nouvelle masterbranche (à la fois localement et à distance). Encore une fois, après avoir fait cela, que se passerait-il maintenant si les autres utilisateurs le faisaient git pull?

Je suppose que tout cela entraînerait beaucoup de problèmes. Existe-t-il un moyen propre d'obtenir ce que je veux? Ou devrais-je simplement laisser mastertel quel et créer une nouvelle branche master-newet y travailler plus loin?

La chose la plus proche du changement de nom 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 comporte de nombreuses mises en garde. Tout d'abord, aucun retrait existant ne connaîtra le changement de nom - git n'essaie pas de suivre les renommages des branches. Si le nouveau mastern'existe pas encore, git pull sortira en erreur. Si le nouveau mastera été créé. la traction tentera de fusionner masteret 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à vérifié 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 receive.denyDeleteCurrentvaleur de configuration sur warnou ignoresur le référentiel distant . Sinon, si vous êtes prêt à créer un nouveau master immédiatement, sautez l' git push remote :masterétape et passez --forceà l' git push remote masterétape. Notez que si vous ne pouvez 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 masterbranche); toute autre branche peut être supprimée et recréée comme ci-dessus.

En supposant que vous êtes 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

1. Créez d'abord une master-oldbranche dans le originréférentiel, basée sur la mastervalidation dans le référentiel local.
2. Créez une nouvelle branche locale pour cette nouvelle origin/master-oldbranche (qui sera automatiquement configurée correctement en tant que branche de suivi).
3. Pointez maintenant votre section locale mastervers le commit sur lequel vous souhaitez qu'il pointe.
4. Enfin, forcez le changement masterdans le originréférentiel pour refléter votre nouveau local master.

(Si vous le faites d'une autre manière, vous avez besoin d'au moins une étape supplémentaire pour vous assurer qu'il master-oldest correctement configuré pour effectuer le suivi origin/master-old. Aucune des autres solutions publiées au moment de la rédaction de cet article ne comprend cela.)

Avec Git v1.7, je pense que cela a légèrement changé. La mise à jour de la référence de suivi de votre succursale locale vers la nouvelle télécommande est désormais 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 basculer manuellement vers new-branch-nameavant de supprimerold-branch-name

Il existe de nombreuses façons de renommer la branche, mais je vais me concentrer sur le plus gros problème: "comment permettre aux clients d'avancer rapidement et de ne pas avoir à jouer avec leurs branches localement" .

D'abord une image rapide:

C'est quelque chose de facile à faire; mais n'en abusez pas. L'idée repose sur des commits de fusion; car ils permettent une avance rapide et lient les historiques d'une branche à une autre.

renommer la branche:

# rename the branch "master" to "master-old"
# this works even if you are on branch "master"
git branch -m master master-old

création de la nouvelle branche "master":

# create master from new starting point
git branch master <new-master-start-point>

créer un commit de fusion pour avoir un historique parent-enfant:

# 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

et le tour est joué.

git push origin master

Cela fonctionne car la création d'une mergevalidation permet d' avancer rapidement la branche vers une nouvelle révision.

en utilisant un message de validation de fusion sensible:

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 posez toujours la même question que dans votre question précédente . Autrement dit, master-new ne contiendra pas master-old dans son historique. * Si vous appelez master-new "master", vous aurez effectivement réécrit l'historique. Peu importe comment vous entrez dans un état dans lequel le maître n'est pas un descendant d'une position précédente de maître, simplement qu'il est dans cet état.

Les autres utilisateurs qui tentent de tirer alors que le maître n'existe pas verront simplement leurs tirages échouer (aucune référence de ce type sur la télécommande), et une fois qu'il existera à nouveau dans un nouvel emplacement, leurs tirages devront tenter de fusionner leur maître avec le nouveau maître distant, comme si vous avez fusionné master-old et master-new dans votre référentiel. Étant donné ce que vous essayez de faire ici, la fusion entraînerait des conflits. (S'ils étaient résolus et que le résultat était repoussé 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 que parfois il y aura des erreurs dans votre histoire. C'est d'accord. Ça arrive à tout le monde. Il y a des validations annulées dans le référentiel git.git. L'important est qu'une fois que nous publions l'histoire, c'est une chose à laquelle chacun peut faire confiance.

* Si c'était le cas, cela équivaudrait à pousser certains changements sur master, puis à créer une nouvelle branche là où elle était. Aucun problème.

La réponse sélectionnée a échoué lorsque je l'ai essayée. Il renvoie 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 à passer à l'espace réservé juste avant de le pousser vers le référentiel distant. Le reste est explicite, la suppression de la branche principale et la pousser vers le référentiel distant devrait fonctionner maintenant. Extrait d' ici .

Bien. Mes 2 cents. Que diriez-vous de vous connecter au serveur, d'aller dans le répertoire git et de renommer la branche dans le référentiel nu. Cela n'a pas tous les problèmes associés au re-upload de la même branche. En fait, 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 succursale.

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:

'Déplacer' la branche locale en utilisant -m

git branch -m my_old_branch_name my_new_branch_name

Poussez la branche «déplacée» vers la télécommande, définissez «en amont» à l'aide de -u

git push origin -u my_new_branch_name

(définir «en amont» «connecte» essentiellement votre branche locale à la télécommande, de sorte que des choses comme l'extraction, la traction et la poussée fonctionnent)

Supprimer l'ancienne branche de la télécommande

git push origin -D <old_name>

(votre succursale locale a déjà disparu, car vous l'avez "déplacée" lors de la 1ère étape)

OK , renommer une branche à la fois localement et sur la télécommande est assez facile! ...

Si vous êtes en succursale, 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 obtenez une erreur en amont lorsque vous essayez de pousser, faites simplement:

git push --set-upstream origin <your_new_branch>

Je crée également l'image ci-dessous pour montrer les étapes en ligne de commande réelle, suivez simplement les étapes et vous seriez bon:

Vous pouvez effectuer les opérations suivantes:

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 pousser de force est une mauvaise idée si d'autres personnes partagent ce référentiel. La poussée de force entraînera un conflit entre leur 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 "origine" 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.

Je crois que la clé est la réalisation que vous effectuez un double changement de nom: mastervers master-oldet aussi master-newvers master.

De toutes les autres réponses, j'ai synthétisé ceci:

doublerename master-new master master-old

où nous devons d'abord définir la doublerenamefonction Bash:

# doublerename NEW CURRENT OLD
#   - arguments are branch names
#   - see COMMIT_MESSAGE below
#   - the result is pushed to origin, with upstream tracking info updated
doublerename() {
  local NEW=$1
  local CUR=$2
  local OLD=$3
  local COMMIT_MESSAGE="Double rename: $NEW -> $CUR -> $OLD.

This commit replaces the contents of '$CUR' with the contents of '$NEW'.
The old contents of '$CUR' now lives in '$OLD'.
The name '$NEW' will be deleted.

This way the public history of '$CUR' is not rewritten and clients do not have
to perform a Rebase Recovery.
"

  git branch --move $CUR $OLD
  git branch --move $NEW $CUR

  git checkout $CUR
  git merge -s ours $OLD -m $COMMIT_MESSAGE

  git push --set-upstream --atomic origin $OLD $CUR :$NEW
}

Ceci est similaire à un changement d'historique git rebaseen ce que le contenu de la branche est assez différent, mais il diffère en ce que les clients peuvent toujours avancer rapidement en toute sécurité git pull master.

git update-ref newref oldref
git update-ref -d oldref newref