Relocating ticket Work via GIT

Backdrop

I recently made the mistake of referencing the wrong ticket number from our ticket management system (we were using Jira) when I made the ticket and 3 commits to the feature. One of my coworkers alerted me to my mistake when someone else tried to pick up the ticket that I was incorrectly cross-referencing in my work. I had not merged in the work yet, so there was no harm to our environment branches nor the core master. This was still quite early in the process, so I decided to quickly relocate the branch and commit references from the ticket I was not working to the one I was.

Process Overview

Here’s how I managed this transfer:

1. Renamed the branch on my local GIT repo

2. Pushed that change to origin by the same name

3. Confirmed the new branch had my code on it (check for silly mistakes)

4. Deleted the wrongly named branch from origin (already changed in local from #1)

5. Renamed each commit on the new branch using interactive rebase to the correctly named branch references

Note: this process is universal, the tool of choice I used when I did this was SourceTree. Any GIT compatible process can perform the same overall process.

Process Breakdown

Identifying the Problem

The beginning of the problem is that while the work was valid, it was referenced to the wrong branch. When my coworker alerted me to this, I went to the wrong ticket, which had no work performed on its behalf yet, and found this:

Sure enough, the branch had my ticket number on it and the description of the ticket I was actually working on. That was my core mistake. Each commit also had valid working notes with this, the wrong ticket, as the ticket reference. One of Jira’s convenient features is that it automatically joins valid ticket references to the tickets they are referencing. In this case, I had mistaken my ticket reference consistently so as to incorrectly assign all my work references to this, presently unworked ticket.

Relocating the Branch

GIT allows us to rename branches locally. In SourceTree, you can right-click the branch of interest and use the following right-click menu option:

I’m using generically named environment branches for this example. I was not accidentally working a branch named “dev”, when it really should have been “master”. But the process is exactly the same. If I select the Rename… option from this menu, I am directed to a modal that asks me for the new intended name. After selecting that I needed to push, selecting the same name for the origin (actual repo, not local) reference. This successfully renames the branch, ensures there’s an origin branch of the same name, and links the two.

Only remaining part for the branch work is to delete the origin reference to the wrong branch. This formerly utilized branch serves no practical purpose once we have successfully renamed and pushed to origin a branch by the same name (previous step). Because we have confirmed the newly named branches both exist and are linked, this previously utilized branch is now both junk for our purposes and problematic to the ticket it is linked to. Delete it.

Still Got Problems

The branch is successfully renamed, linked, and the old branch is removed. However, the work we’ve already performed, committed, and likely pushed has the wrong ticket references on it also. In my case, the ticket I was not working still had the commit references on it. That’s not good. So, we still have cleanup with the commit messages for the now correctly named feature branch.

Interactively Rebasing Commit Messages

As terrifying as rebasing is to newer GIT developers, there’s something even scarier: interactive rebase. As bad as it sounds, in this case, it’s quite useful. With interactive rebase, we can target commit messages and rename them on our feature branch.

In SourceTree, you can access the interactive rebase from the commit history viewport.

Example:

Every GIT compatible process has access to this feature in their own way.

For SourceTree, this opens a modal window that allows the user to interact with each commit in an interactive fashion. Squashing commits is done here. But for this process, we are interested in this feature:

Edit message opens a modal with the presently designated commit message pre-populated. We can rewrite or edit that commit message in the modal.

Selecting “OK”. Saves it to memory.

Updating History

After the commit messages have been adjusted appropriately, we have to update the history. We’ll see dual references in our branches history until we perform a force push to update all the commit history with our manually edited commit name values. This is the final cleanup, the force push to origin after the interactive rebase of the commit messages.

Results

Always good to perform a silly mistake check, especially on a process that had so much adjustment and deletion involved. I confirmed the branch was in the state I wanted, I confirmed the commits on the branch matched what I wanted. Last check: we’re using Jira, so I need to check how each ticket is referencing work done to it.

Ticket I am not working:

This is good! No work referenced on this ticket yet. Now the other developer can pick it up and only that developer’s work will be reflected here.

My ticket:

Also good! If you scroll back up to the “Identifying The Problem” header, you’ll see that this was the association made on the wrong ticket at the beginning. This means that my branch and all three of my commits have been appropriately relocated to the correct Jira ticket reference.

Silly Mistakes

Mis-referencing work on branches and feature branches happens. GIT provides renaming and history-altering tools to help us fix our silly mistakes. This entire process took me no more than five minutes to perform and saved our team a significant amount of confusion. It’s always worth the effort to put work in the right place and reference it appropriately.