Переименуйте главную ветку для локальных и удаленных Git-репозиториев.

Question

У меня есть ветка master, которая отслеживает удаленную ветку origin/master.

Я хочу переименовать их в master-old как локально, так и на пульте. Это возможно? Что произойдет после переименования удаленной ветви для других пользователей, которые отслеживали origin/master (и которые всегда обновляли свою локальную ветку master через git pull)? Будет ли их git pull все еще работать или будет выдано сообщение об ошибке, которое он не сможет найти origin/master?

Затем, в дальнейшем, я хочу создать новую ветвь master (как локальную, так и удаленную). Опять же, после того, как я это сделал, что произойдет сейчас, если другие пользователи сделают git pull?

Полагаю, все это приведет к большим неприятностям. Есть ли чистый способ получить то, что я хочу? Или я должен просто оставить master как есть и создать новую ветку master-new и просто работать там дальше?

Answer 1

А как же:

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

Answer 2

Для выполнения этой работы в сценарии оболочки может быть сохранено следующее:

Например:

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

Обратите внимание, что здесь удаленное имя по умолчанию «origin» задано жестко, вы можете расширить сценарий, чтобы сделать его настраиваемым!

Тогда этот скрипт можно использовать с псевдонимами bash, псевдонимами git или, например, в пользовательских действиях на sourcetree.

Answer 3

Вы можете сделать следующее:

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

Но форсирование - плохая идея, если другие люди делятся этим хранилищем. При принудительном нажатии их история изменений вступает в конфликт с новой.

Answer 4

Я считаю, что ключом является осознание того, что вы выполняете double переименование: master до master-old, а также master-new до master.

Из всех других ответов я синтезировал это:

doublerename master-new master master-old

где мы сначала должны определить функцию doublerename 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
}

Это похоже на изменение истории git rebase в том смысле, что содержимое ветки совершенно иное, но отличается тем, что клиенты все еще могут безопасно перемотать вперед с помощью git pull master.

Answer 5

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