0

My local branch is mapped to a remote one:

fetch = +refs/heads/release/old_branch:refs/remotes/origin/release/old_branch

I'd like to rename both local and remote old_branch into new_branch. w3docs recommends this:

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

However, there are a couple other developers who are also working on the same remote old_branch as I do. Is the above recommendation safe in collaborative environment? If their .git/config has lines similar to mine above, wouldn't this sequence confuse their fetch references?

Michael
  • 5,775
  • 2
  • 34
  • 53
  • 3
    why not just create new branch from old, public it, and work with this new one? – VelikiiNehochuha Oct 02 '19 at 21:31
  • @VelikiiNehochuha, makes sense: if somebody keeps using old_branch and the branches diverge I'll just merge the changes to new_branch. Thanks, will do. – Michael Oct 02 '19 at 21:44
  • Create new (via `git push -u origin new_branch`) before deleting old. In some cases this doesn't matter; in other cases, where it does matter, it makes the "create new" operation significantly more efficient. You might wonder when (and why) it is more efficient: the answer is, if deleting the old name triggers a server side `git gc` that throws out commits reachable from the old name, your subsequent push to create the new name must re-send all the commits the `git gc` just threw away. If you create first, all the commits are retained. – torek Oct 03 '19 at 05:59

2 Answers2

0

Given your stated goal to rename the branch on local and remote - taking that to mean that locally and on the remote there should, at the end, be anew_branch pointing to where old_branch previously pointed, and there should no longer be an old_branch - then the procedure you listed is as good as any.

This is because when another developer fetch's, their repo won't "know" / be affected by what commands were used to get to that end state. They will simply see that old_branch is gone and that there is a new branch called new_branch.

Now, such repos won't automatically delete their origin/old_branch ref; by default they'll keep it where it is unless/until using fetch with the --prune option. That also means they could potentially re-push it (without ever realizing you'd deleted it).

In other words, you won't confuse git, but you could confuse teammates - so you need to communicate with the team to make sure people know what's going on.

Mark Adelsberger
  • 42,148
  • 4
  • 35
  • 52
-1

I recommend creating a new_branch and informing the other developers to use the new branch (and deleting the old_branch).

In case a developer keeps using the old branch you can just merge their commits to the new_branch until he switches to the new_branch.

tymtam
  • 31,798
  • 8
  • 86
  • 126