2

I had a git branch. It was merged and deleted by gitlab. Now, an error was found and I want to continue working on this branch. I renamed it but it still tracks the deleted branch (it doesn't know that gitlab deleted the branch). Now I'm curious, what do I do in this situation.

  • What happens if I push the way it is?
  • How can I detach the branch from that origin?
  • Maybe it's just simpler to make a new branch?
Mykola Tetiuk
  • 157
  • 3
  • 9

2 Answers2

4

Before getting to your specific questions, I'd like to point out a minor detail in the way your question is worded:

I had a git branch. It was merged and deleted by GitLab. Now, an error was found and I want to continue working on this branch.

Conceptually I think it makes more sense to say:

Now, an error was found and I want to fix it.

Since the bug is already merged into the main codebase, the branch you developed that code on is no longer relevant, and this is why the typical action would be to delete it once it's merged. Suppose you wanted to fix a bug that was introduced a year ago; you wouldn't try to find a year old branch and start working on the fix from there, instead you would create a branch off of the latest main (or whatever your default branch is called), and then go fix the bug. Conceptually this is what you should do for this case too. That being said, it's normally OK if the new branch you create happens to have the same name as a branch you previously used. That's true whether the branch name was last used a year ago, or a few minutes ago. If you do re-use the same named branch, you probably would want to reset it to the latest, e.g. main first. There are multiple ways to do that:

# Get the latest code before any of these
git fetch

# Delete the branch and re-create it:
git switch any-other-branch-name
git branch -d my-fav-branch-name-i-want-to-reuse # delete it
git switch -c my-fav-branch-name-i-want-to-reuse origin/main --no-track # create it again from main

# OR faster

# Just force switch to the same branch name:
git switch -C my-fav-branch-name-i-want-to-reuse origin/main --no-track

# OR faster if already checked out

# Just reset if branch is already checked out
git reset origin/main

The takeaway here is that the branch name is not sacred, and you can re-use a branch if you want to, or use another name. If I'm fixing a bug I might be more inclined to name my branch something like user/ttt/fix-blah-blah-blah.

So, given this information, now let's answer your questions. Your setup scenario is that the remote branch has been merged and deleted, and you have renamed your local branch, but it's still tracking the old upstream branch name.

What happens if I push the way it is?

If you git push, it will simply re-create the old branch name on the remote. If you hadn't renamed your branch this would likely be fine assuming you intended to re-use the same branch name, but since you renamed your branch, this is undesirable. It would be less confusing to set the upstream to the new name.

How can I detach the branch from that origin?

git branch --unset-upstream

Maybe it's just simpler to make a new branch?

Notice in the example commands I used above, when creating a new branch from the switch command, I used the --no-track option to prevent it from tracking origin/main. I wouldn't say it's "simpler" to make a new branch, but it enables you to delete the old one which is nice since the remote tracking info goes away too. In a repo I work out of daily, I typically have anywhere from 5-50 local branches at any time, so I like to name my branches in such a way that I can be pretty sure what unmerged commits are sitting on them just by reading the branch name. Ultimately, re-using the same branch again, or not, really comes down to personal preference. In one of my regular repos that uses Git Flow, I always make a branch named user/ttt/merge-master-into-develop and re-use the same name every time I perform that merge. But for regular work, my branch name is typically unique and descriptive to the task I'm working on.

TTT
  • 22,611
  • 8
  • 63
  • 69
  • 1
    In some cases, it *does* make sense to track down the original commit and fix the problem there (usually you'll create a branch for this purpose). You can then merge that fix into every downstream release. See https://devblogs.microsoft.com/oldnewthing/20180323-01/?p=98325 – torek Nov 24 '21 at 01:27
  • @torek Right, specifically if you're patching an older release. – TTT Nov 25 '21 at 04:16
2

You can keep using that old branch if you want but in my experience using a new branch keeps things cleaner.

Be sure you update the remote target branch locally (probably master/main I'm guessing) and then merge it into your local branch. Things can get a little messy if you squash commits and/or depending on your merge strategy. It would look something like this:

  1. You push a branch to gitlab
  2. You create and merge an MR (with delete source branch) in GitLab to master
  3. While in your branch locally, git pull origin master to pull the latest changes and merge them into your branch
  4. git push -u <branch-name> will push this branch to GitLab. (See https://stackoverflow.com/a/6232535/2264411 for details on this syntax)
    • This step is really important because you won't be able to git push this branch to GitLab anymore. Since it was deleted, it's effectively a new branch, and you have to push it upstream to GitLab.
luxdvie
  • 902
  • 8
  • 16