When we manage and maintain a public github repository, it is common to see a case that a fixed branch from outside contributor’s is staled. The reasons can be
- The github repository owner/maintainer and contributor did not actively process the issue in time.
- The contirbutor only commited the changes in his branch but didn’t make a pull request, and after a period, he is not reachable.
- Other reasons…
Overall, it is not easy to maintain a public github repository, especially the one with lots of stars. This post will show a way to solve the above issue with a git feature.
Let’s make a scenario.
John commited a fix change about 6 months ago but no pull request was made. Now the github repository maintainer has verified the issue and wants to merge John’s change for the next release.
At this moment, the maintainer can ask John to rebase the latest master branch and solve the conflict if there is any. After that, John can make a pull request. The maintainer will merge it before next release. This will be the easist solution for this case. However, it is not guranteed as John could miss the message or other reasons. In this situation, the maintainer can’t wait too. Thus, the other solution comes out.
Go to your repository root path
# List all your remote repository
git remote -v
# Add remote repository "git remote add <shortname> <url>"
git remote add johnfix git@github.com/john/fix...
# Get the data from that remote repository
git fetch johnfix
# Checkout the branch where john commited the fix change
git checkout -b johnfix/<john\'s branch name>
# Create a new branch based on the current branch and checkout it
git switch -c <new branchname>
git commit -m "xx"
git push
The above git workflow is that
- Add John’s repository as our own remote repository
- Fetch the data from the remote repository, so that we have a local copy
- Checkout the specific branch. We can continue John’s work on it, but the branch will still belong to John. So we do next
- Switch to a new branch and checkout it. This new branch also contains John’s work
- Commit and push the new branch.
Why is the git remote a better solution for the scenario?
- Instead of cloning John’s repository, adding it as a remote repository can keep John’s ownership for the fixing code.
- After pushing the new branch, the github orginal repository can see the commit. However, the new branch needs to rebase the current master and resolve the conflict before making a PR.
- Switching the new branch has two good results. First is that John’s branch is still there, nothing changed. Second is that my new branch has John’s fix commit and under my name. I can either add other changes or make a PR without any conflicts.
Alternative solution
I recently met this issue again and I found another simpler solution for this scenario. However, it is as same as above solution behind the scene.
# Checkout a new branch on your working repository
git checkout -b <a_new_branch>
# Pull john's fix branch from john's forked repository directly.
git pull https://github.com/john/<forked_project>.git <john-fix-branch-name>
# If there are conflicts, resolve the conflicts first
# Add the changes
git add <file1> <file2> ..
# Commit the changes
git commit -m "xx"
git push
With the above solution, john’s contribution will also be included in the new branch. It’s quite straightforward.
Reference: Git Basics - Working with Remotes
If this post helped you to solve a problem or provided you with new insights, please upvote it and share your experience in the comments below. Your comments can help others who may be facing similar challenges. Thank you!