我有一个分支主机,它跟踪远程分支源/主机。

我想在本地和远程将它们重命名为master old。这可能吗?

对于跟踪origin/master(并且总是通过git pull更新本地主分支)的其他用户,在我重命名远程分支后会发生什么?他们的git pull是否仍然有效,或者它是否会抛出一个错误,即无法再找到原始/主文件?

接下来,我想创建一个新的主分支(本地和远程)。再次,在我这样做之后,如果其他用户执行git pull,现在会发生什么?

我想这一切都会带来很多麻烦。有没有一种干净的方法可以得到我想要的东西?还是我应该让master保持原样,创建一个新的分支master,然后继续工作?


当前回答

我假设你仍然在问与你之前的问题相同的情况。也就是说,master new在其历史中不会包含master old。*如果您将master new称为“master”,则实际上您已经改写了历史。不管你如何进入一个状态,在这个状态中,主人不是先前主人地位的后代,只是它处于那个状态。

当master不存在时,其他尝试拉取的用户只会导致其拉取失败(远程上没有这样的引用),一旦它在新的位置再次存在,他们的拉取将不得不尝试将其master与新的远程master合并,就像您在存储库中合并了旧master和新master一样。考虑到您在这里试图做的事情,合并可能会发生冲突。(如果解决了这些问题,并且结果被推回到存储库中,那么你的状态会更糟——这两个版本都是历史。)

简单地回答你的问题:你应该接受在你的历史中有时会有错误。这没关系。这发生在每个人身上。git.git存储库中有还原的提交。重要的是,一旦我们公布了历史,这是每个人都可以信任的。

*如果这样做了,这就相当于将一些更改推到master上,然后在原来的位置创建一个新的分支。没问题。

其他回答

关于:

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

有很多方法可以重命名分支机构,但我将重点放在更大的问题上:“如何让客户快速前进,而不必在本地处理分支机构”。

首先是一张快速图片:

这实际上很容易做到;但不要滥用它。整个想法取决于合并提交;因为它们允许快进,并将分支的历史与另一分支的历史联系起来。

重命名分支:

# 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

这是因为创建合并提交允许将分支快速转发到新修订。

使用合理的合并提交消息:

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

我相信关键是你意识到你正在执行一个双重重命名:从主到主,从主到新。

从所有其他答案中,我综合了这一点:

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快速前进。

我假设你仍然在问与你之前的问题相同的情况。也就是说,master new在其历史中不会包含master old。*如果您将master new称为“master”,则实际上您已经改写了历史。不管你如何进入一个状态,在这个状态中,主人不是先前主人地位的后代,只是它处于那个状态。

当master不存在时,其他尝试拉取的用户只会导致其拉取失败(远程上没有这样的引用),一旦它在新的位置再次存在,他们的拉取将不得不尝试将其master与新的远程master合并,就像您在存储库中合并了旧master和新master一样。考虑到您在这里试图做的事情,合并可能会发生冲突。(如果解决了这些问题,并且结果被推回到存储库中,那么你的状态会更糟——这两个版本都是历史。)

简单地回答你的问题:你应该接受在你的历史中有时会有错误。这没关系。这发生在每个人身上。git.git存储库中有还原的提交。重要的是,一旦我们公布了历史,这是每个人都可以信任的。

*如果这样做了,这就相当于将一些更改推到master上,然后在原来的位置创建一个新的分支。没问题。

这是我所知道的最简单、最“可读”的方式:

使用-m“移动”本地分支

git branch -m my_old_branch_name my_new_branch_name

将“已移动”分支推到远程,使用-u设置“上游”

git push origin -u my_new_branch_name

设置“upstream”实际上是将本地分支“连接”到远程,这样像fetch、pull和push这样的操作就可以工作了。

从远程删除旧分支

git push origin -D <old_name>

您的本地分支已经不存在了,因为您在第一步中“移动”了它。