How to Deal With Stale Branches on the Github
A guidance how to keep your git branches list clean
4 min read
Nov 13, 2019
In this article I want to show you a way how to deal with stale git branches on the Github.
I suppose you are already familiar with git and Github, so it will be easy to read and understand information below.
I will try to keep this article short and my thoughts and text clear.
Let’s begin!
«Stale branch»? what is that?
Let’s imagine you have a branch «feature_123». You made commits in it but for some reason the work was stopped. Is it a stale branch? If so, since what time?
«Stale branch» is a git branch without commits for the last few months.
For the Github, such period of inactivity is 3 months.
You can check now your project’s repository «branches» tab and see if you have such branches.
Why do I have those branches?
There could be a lot of reasons to have such non-supported branches. A few of them are:
- unreleased, a feature was implemented but not included into the final version of the product
- prototype, like a proof-of-concept, a feature was done to confirm some statements about the idea
- alternative solution, yet another possible implementation (most likely not the best)
- incomplete, a feature that was started a long ago and was stopped unfinished or was postponed
- incompatible, a feature became incompatible with the rest of the project (e.g. technology stack was updated)
It’s okay if your project does not have such branches at all. But if it has, I would be happy to share my notes of how to deal with it.
Keep or delete?
Keeping such branches may lead to a list, difficult to work with.
Deleting a branch isn’t suitable in the case you will want to restore it easily. The only way to restore the code will be to checkout by a commit hash.
git checkout -b
Can’t we just archive it?
Well, there is no such option like archiving branches in git. But we can create a tag with a prefix like “archive”.
git tag archive/
git branch -d
In other words, we move entry about the feature from branch list to tags list.
To restore the branch, checkout it by the tag.
git checkout -b archive/
Cancelled pull request
There is another option, I wish to tell you about, which gives you more benefits such as:
- keep repository clean
- won’t merge the code into the master branch
- delete branch
- easily find and restore deleted branch
Step 1. Create a PR
Go to the the «New pull request» page on the Github and create a pull request.
It does not matter if there will be a merge conflict, just don’t resolve it. You will save your time.
Step 2. Set the right name
Name your pull request exactly the same as your source branch.
Example: “feature_123”.
Step 3. Cancel this pull request
Yes, don’t merge it! Scroll down and find «Close pull request». Close it without merge.
Step 4. Delete the branch
Now you can safely delete the branch.
Step 5. How to restore?
At any time, when you will need it, simply find your closed pull request on the «Pull requests» page by the filter: “head:feature_123”.
Open the pull request page and press «Restore branch» button.
All the working process in the branch was successfully restored!
Most of branches in the code repository are reflecting features or tasks to be done. And in today’s fast changing business requirements environment, number of branches constantly keeps growing. Having a possibility to delete a branch and reactivate it on demand helps to keep your repository up-to-date and clean.
Saved searches
Use saved searches to filter your results more quickly
Cancel Create saved search
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ошибка / улучшение при Floating Labels и Additional Info в Inputs #3245
Управление метками
Вы можете классифицировать проблемы, запросы на вытягивание и обсуждения путем создания, редактирования, применения и удаления меток.
About labels
You can manage your work on GitHub by creating labels to categorize issues, pull requests, and discussions. You can apply labels in the repository the label was created in. Once a label exists, you can use the label on any issue, pull request, or discussion within that repository.
About default labels
GitHub provides default labels in every new repository. You can use these default labels to help create a standard workflow in a repository.
| Label | Description |
|---|---|
| bug | Indicates an unexpected problem or unintended behavior |
| documentation | Indicates a need for improvements or additions to documentation |
| duplicate | Indicates similar issues, pull requests, or discussions |
| enhancement | Indicates new feature requests |
| good first issue | Indicates a good issue for first-time contributors |
| help wanted | Indicates that a maintainer wants help on an issue or pull request |
| invalid | Indicates that an issue, pull request, or discussion is no longer relevant |
| question | Indicates that an issue, pull request, or discussion needs more information |
| wontfix | Indicates that work won’t continue on an issue, pull request, or discussion |
Default labels are included in every new repository when the repository is created, but you can edit or delete the labels later.
Issues with the good first issue label are used to populate the repository’s contribute page. For an example of a contribute page, see github/docs/contribute.
Organization owners can customize the default labels for repositories in their organization. For more information, see «Managing default labels for repositories in your organization.»
Creating a label
Anyone with write access to a repository can create a label.
- On GitHub.com, navigate to the main page of the repository.
- Under your repository name, click
Issues or
Pull requests.
Above the list of issues or pull requests, click Labels.
Applying a label
Anyone with triage access to a repository can apply and dismiss labels.
- Navigate to the issue, pull request, or discussion.
- In the right sidebar, click Labels, then click a label.
Editing a label
Anyone with write access to a repository can edit existing labels.
- On GitHub.com, navigate to the main page of the repository.
- Under your repository name, click
Issues or
Pull requests.
Above the list of issues or pull requests, click Labels.
Deleting a label
Anyone with write access to a repository can delete existing labels.
Deleting a label will remove the label from issues and pull requests.
- On GitHub.com, navigate to the main page of the repository.
- Under your repository name, click
Issues or
Pull requests.
Above the list of issues or pull requests, click Labels.
Further reading
- «Filtering and searching issues and pull requests»
- «Managing default labels for repositories in your organization»
- «Encouraging helpful contributions to your project with labels»
- «Basic writing and formatting syntax»
Saved searches
Use saved searches to filter your results more quickly
Cancel Create saved search
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.
GitHub Community
Outdated code shown in compare/pull request #21902
Drift91 asked this question in New to GitHub
Dec 7, 2017 · 3 comments
Something went wrong.
Quote reply
Dec 7, 2017
I’ve forked someone’s repo to customize it for my own use. Since then they’ve updated their code and I want to merge the latest commits of thier master into my customized fork to keep my version up-to-date yet still customized.
Now if you compare the above comparison of changelog.md to the actual contents below, you’ll see that the comparison above is completely out of date.
It seems as if it’s comparing his master before I forked it to his current master instead of comparing my current dev branch to his current master branch. Is this a bug in the website or am I doing something wrong? If this is how it’s going to function then making a pull request to my code is useless and I might as well do everything manually in a text editor.
Does someone know how to properly compare the most recent code of both forks? I’ve even tried using the hash of my most recent commit to compare and it still shows the outdated code. What’s weird is that even if I switch the direction of the comparison, it still shows the same outdated 1.4.0 code on the left.
Thanks in advance for any assistance.
Beta Was this translation helpful? Give feedback.
1 You must be logged in to vote
All reactions
I’d recommend taking a look at our Help Docs on how to merge an upstream repository to your fork:
If there are conflicts (which it sounds like there might be), you’ll also want to check out the article on addressing merge conflicts:
I hope these help! If you have further questions, please let me know!