Umbenennen des Master-Zweigs für lokale und entfernte Git-Repositories

Question

Ich habe den Zweig master die den entfernten Zweig verfolgt origin/master .

Ich möchte sie umbenennen in master-old sowohl lokal als auch auf der Gegenstelle. Ist dies möglich?

Für andere Nutzer, die Folgendes verfolgt haben origin/master (und die immer ihre lokalen master Abzweigung über git pull ), was würde passieren, nachdem ich den entfernten Zweig umbenannt habe?
Würden ihre git pull immer noch funktionieren, oder würde es eine Fehlermeldung ausgeben, dass es nicht gefunden werden konnte origin/master mehr?

Anschließend möchte ich eine neue master Zweigstelle (sowohl lokal als auch remote). Nachdem ich dies getan habe, was würde nun passieren, wenn die anderen Benutzer git pull ?

Ich vermute, dass all dies zu einer Menge Ärger führen würde. Gibt es einen sauberen Weg, um zu bekommen, was ich will? Oder sollte ich einfach die master und erstellen Sie einen neuen Zweig master-new und dort einfach weiterarbeiten?

Answer 1

Dies ist die einfachste und "lesbarste" Methode, die ich kenne:

Verschieben" des lokalen Zweigs mit -m

git branch -m my_old_branch_name my_new_branch_name

Schieben Sie den "verschobenen" Zweig auf die entfernte Seite, setzen Sie "upstream" mit -u

git push origin -u my_new_branch_name

Das Setzen von 'upstream' verbindet im Wesentlichen Ihren lokalen Zweig mit dem entfernten, so dass Dinge wie fetch, pull und push funktionieren werden.

Löschen Sie den alten Zweig aus dem entfernten

git push origin -D <old_name>

Ihre lokale Zweigstelle ist bereits verschwunden, weil Sie sie im ersten Schritt "verschoben" haben.

Answer 2

Sie können Folgendes tun:

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

Es ist jedoch keine gute Idee, die Veröffentlichung zu erzwingen, wenn andere Personen dieses Repository gemeinsam nutzen. Force Push wird dazu führen, dass ihre Revisionshistorie mit der neuen in Konflikt gerät.

Answer 3

Folgendes kann im Shell-Skript gespeichert werden, um die Aufgabe zu erledigen:

Zum Beispiel:

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

Bitte beachten Sie, dass hier der Standard-Fernmeldename "origin" fest programmiert ist. Sie können das Skript erweitern, um es konfigurierbar zu machen!

Dann kann dieses Skript z.B. mit Bash-Alias, Git-Alias oder in verwendet werden, Quellennachweis benutzerdefinierte Aktionen.

Answer 4

Gehen Sie zu github.com oder wo auch immer, klicken Sie auf branch, und benennen Sie es um. Führen Sie diese dann lokal aus:

git branch -m <old-branch-name> <new-branch-name>
git fetch origin
git branch -u origin/<new-branch-name> <new-branch-name>

Answer 5

Ich glaube, der Schlüssel ist die Erkenntnis, dass man eine doppelt umbenennen: master a master-old und auch master-new a master .

Aus all den anderen Antworten habe ich diese zusammengefasst:

doublerename master-new master master-old

wobei wir zunächst die doublerename Bash-Funktion:

# 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
}

Dies ist vergleichbar mit einer geschichtsverändernden git rebase dass der Inhalt der Verzweigung ganz anders ist, aber es unterscheidet sich dadurch, dass die Kunden immer noch sicher vorspulen können mit git pull master .