Git rid of old branches :-)

Toss ’em out!

Every so often, I clean up old working branches I don’t need any more.

After I’ve written or revised content, and the pull request has been merged from my fork of the repo into the main branch of the organization’s repo, it’s time to get rid of the old working branches.

TLDR/Copy and paste

Here’s a summary of the commands for you to copy and paste.

cd <repo-directory>/
git checkout <main branch>
git fetch upstream <main branch>
git branch --merged
> Make sure the branch is dead
git branch -D <branch-name>
git push origin :<branch-name>



  • List the merged branches
  • Make sure the working branches are really dead
  • Delete the dead branches
List the merged branches

I start by listing the merged branches in my local repo:

$ cd openshift-docs/       # Change to the project/repo directory
$ git checkout main        # Check out the main or master branch
Already on 'main'
Your branch is up to date with 'upstream/main'.
$ git fetch upstream main  # Fetch information about branches from your upstream repo 
remote: Enumerating objects: 46, done.
remote: Counting objects: 100% (36/36), done.
remote: Compressing objects: 100% (9/9), done.
remote: Total 19 (delta 15), reused 12 (delta 10), pack-reused 0
Unpacking objects: 100% (19/19), 3.11 KiB | 176.00 KiB/s, done.
 * branch                main     -> FETCH_HEAD
   54901a001..b051f3c46  main     -> upstream/main
$ git branch --merged      # List local branches that are merged in the upstream repo
* main
Make sure the working branches are really dead

Early on, when I start a new project, I use the ID of the Jira or GitHub issue to name the working branch and PRs. This makes it simple to know which issue, branch, and PR belong to each other.

When I’ve finished using a working branch, to make sure I don’t need it any more, I search my closed pull requests for the issue ID. I review the pull request to make sure that the PR that was merged into the main branch was also cherry-picked into all relevant release branches. I also look at the issue to make sure its state is “closed.”

When I’ve confirmed that a branch is not only merely dead, but really most sincerely dead, it’s time to…

Delete the dead branches

I return to my terminal and delete the branch by entering:

$ git branch -D <branch-name>

Then I push the deletion to origin by entering:

$ git push origin :<branch-name>


  • Many repos still use master as the name of their primary branch. In this post, I have changed the name to main and will continue to do so in future posts.
  • Please share your comments, questions, and suggestions for improving this post, below!

Job aid: Git cherry-pick a commit and manually resolve a conflict

This post is short version of Git: Cherry-pick a commit into a branch and resolve a merge conflict. Replace `upstream/enterprise-4.8` with whatever your target branch is.

I copy/paste these commands into my terminal.

git checkout master
git branch -D enterprise-4.8
git checkout --track upstream/enterprise-4.8
git status

Verify that “Your branch is up to date with ‘upstream/enterprise-4.8’.”

git cherry-pick <commit hash>

Go to the pull request that has the merge failure (e.g., like this example). Copy the commit hash. In the terminal, replace <commit hash> with the real one. Enter the command.

Ignore “CONFLICT (content): Merge conflict in <path/filename>

In Atom editor (or whatever), manually resolve the merge conflict.
Save and commit the changes as “Manual CP of RHDEVDOCS-<jira#> #<pr#>”.

git status

Confirm “Your branch is ahead of ‘upstream/enterprise-4.8’ by 1 commit.”

git push -f origin enterprise-4.8

Go to origin/enterprise-4.8 in GitHub and create the pull request with the following description.
Previously merged as

Copy the URL of this new PR and paste it to a comment in the Jira issue (e.g., in RHDEVDOCS-2617).

Git: Cherry-pick a commit into a branch and resolve a merge conflict

Here’s the merge conflict message our merge master got when she tried to cherry pick my pull request (PR) to version 4.7 of the published OpenShift docs (lines , below).

openshift-cherrypick-robot commented 4 days ago • 
@theythemself: #29573 failed to apply on top of branch "enterprise-4.7":

Applying: [RHDEVDOCS-2614]( Define ClusterLogForwarder compatability Matrix
Using index info to reconstruct a base tree...
M	logging/cluster-logging-external.adoc
Falling back to patching base and 3-way merge...
Auto-merging logging/cluster-logging-external.adoc
CONFLICT (content): Merge conflict in logging/cluster-logging-external.adoc
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 [RHDEVDOCS-2614]( Define ClusterLogForwarder compatability Matrix
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

Here, I start by deleting the enterprise-4.7 branch (line ) because it had a previous unmerged commit sitting at the top of the pile. (In the future, I think I’ll avoid this by creating a working branch off of the enterprise-4.7 branch.)

[memyself@memyself openshift-docs]$ git checkout master
Switched to branch 'master'
Your branch is up to date with 'upstream/master'.

[memyself@memyself openshift-docs]$ git branch -D enterprise-4.7
Deleted branch enterprise-4.7 (was 803d05ddd).

Next, I create a new enterprise-4.7 branch that tracks Red Hat’s upstream repo (line). I don’t track my forked copy of the repo, origin, because it has that previous unmerged commit sitting at the top of the pile. (Again, there are other better ways to deal with that problem, I’m just sharing the one I used here.)

[memyself@memyself openshift-docs]$ git checkout --track upstream/enterprise-4.7
Branch 'enterprise-4.7' set up to track remote branch 'enterprise-4.7' from 'upstream'.
Switched to a new branch 'enterprise-4.7'

I fetch the latest changes from upstream and use status to verify that my branch is up to date.

[memyself@memyself openshift-docs]$ git fetch upstream
remote: Enumerating objects: 6, done.
remote: Counting objects: 100% (6/6), done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 6 (delta 4), reused 5 (delta 4), pack-reused 0
Unpacking objects: 100% (6/6), 1.22 KiB | 1.22 MiB/s, done.
   335951a8d..0f6dbceae  enterprise-4.5 -> upstream/enterprise-4.5

[memyself@memyself openshift-docs]$ git status
On branch enterprise-4.7
Your branch is up to date with 'upstream/enterprise-4.7'.

nothing to commit, working tree clean

I go to the pull request with the failed cherry pick and copy the hash of the commit. I always squash commits so each pull request has only one commit.

I cherry pick that commit into the 4.7 branch. The merge conflict on line 5 is expected.

[memyself@memyself openshift-docs]$ git cherry-pick 3cad05d66d11c2d38a08322222f6c9dcbfc839ab
Auto-merging modules/olm-mirroring-package-manifest-catalog.adoc
Auto-merging modules/cluster-logging-deploy-console.adoc
Auto-merging modules/cluster-logging-deploy-cli.adoc
CONFLICT (content): Merge conflict in modules/cluster-logging-deploy-cli.adoc
error: could not apply 3cad05d66... RHDEVDOCS-2589 OpenShift Logging: Update any installation/upgrade specific information to use our new channels.
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'

I check the status.

[memyself@memyself openshift-docs]$ git status
On branch enterprise-4.7
Your branch is up to date with 'upstream/enterprise-4.7'.

You are currently cherry-picking commit 3cad05d66.
  (all conflicts fixed: run "git cherry-pick --continue")
  (use "git cherry-pick --skip" to skip this patch)
  (use "git cherry-pick --abort" to cancel the cherry-pick operation)

Changes to be committed:
	modified:   logging/cluster-logging-exported-fields.adoc
	modified:   logging/cluster-logging-upgrading.adoc
	modified:   modules/cluster-logging-configuring-image-about.adoc
	modified:   modules/cluster-logging-deploy-cli.adoc
	modified:   modules/cluster-logging-deploy-console.adoc
	modified:   modules/cluster-logging-eventrouter-deploy.adoc
	modified:   modules/cluster-logging-log-store-status-comp.adoc
	modified:   modules/cluster-logging-updating-logging.adoc
	modified:   modules/cluster-logging-visualizer-kibana.adoc
	modified:   modules/olm-mirroring-package-manifest-catalog.adoc

In Atom editor (not shown here), I inspect the file that contains the conflict, modules/cluster-logging-deploy-cli.adoc. In it, I select the set of changes I want to keep. Then, I stage and commit the changes.

Back on the command line, I complete the cherry pick process.

[memyself@memyself openshift-docs]$ git cherry-pick --continue

I -f force push the changes to 4.7 to origin, which is my fork of the repo.

[memyself@memyself openshift-docs]$ git push -f origin enterprise-4.7
Enumerating objects: 27, done.
Counting objects: 100% (27/27), done.
Delta compression using up to 8 threads
Compressing objects: 100% (14/14), done.
Writing objects: 100% (14/14), 1.62 KiB | 1.62 MiB/s, done.
Total 14 (delta 13), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (13/13), completed with 13 local objects.
 + 803d05ddd...bcc5f087b enterprise-4.7 -> enterprise-4.7 (forced update)

Finally, on GitHub, in rolfedh/openshift-docs, I create the pull request to merge the commit into openshift:enterprise-4.5 from rolfedh:enterprise-4.5.

I’ll need to repeat this process and come up with a more complete set of screenshots.

Here’s a TLDR version of this blog post: Job aid: Git cherry-pick a commit and manually resolve a conflict
I use this short version to copy/paste commands into my terminal.