How to fix "this branch is 1 commit behind of master branch"

27 Views Asked by At

I am working on android studio and am fairly new to GitHub. I created a new branch diverging from origin/master lets name it "newCommits", I added a new functionality and made 1 commit to this branch and pushed it. Now at Github browser I created a PR and after reviewing the code I merged it in master branch.

A new message popped at the top of newCommits that "This branch is 1 commit behind the master branch." I know this is due to the extra merge commit, but is there any fix to it?

Every other thread gave the answer to clone the repo and then fetch and push the origin but do I have to do it every time I commit in the newCommits?

I tried Github Desktop:

  • Tried to directly merge and then push to origin, worked but no use of PR
  • Tried to Rebase but was not successful

Tried to Merge the newCommits within the Master through Github Desktop

2

There are 2 best solutions below

0
Nosheen Akhtar On

How you can do it:

git checkout newCommits git rebase master

then try following command:

git push origin newCommits --force

0
hlovdal On

So what has happened here is the following

  1. (local) created branch newCommits from master.
  2. (local) created some commits on the newCommits branch.
  3. (local+remote) pushed newCommits to origin.
  4. (remote) created Pull Request.
  5. (remote) completed pull request which creates an "extra" merge commit.

Until you run git fetch (or git pull which implicitly does git fetch) your local repository does not know anything about those two last remote steps. I assume Github Desktop does git fetch behind the scenes in some automatic fashion (this is not uncommon, vscode does something similar), and probably showed you the dialogue at the same time.

How to go forward from here is much more a opinion/what-do-you-want question than a technical question. As TTT already commented, feature branches that are merged into some main branch normally do not have any inherent value after they are merged and can then be deleted. This is by far the most common operation (95%+).

But if you want to continue using the same branch name for a new feature this is possible. Say for instance you are cleaning up log messages, and created a pull request for changes related to foo which got merged and now you want to continue cleaning up log messages related to bar. For such a use case reusing the branch is perfectly fine (although not super common).

If you want to reuse newCommits and fix the "This branch is 1 commit behind the master branch." issue, this is solved by rebasing newCommits on top of master with the command

git rebase master newCommits

(You should newer use less than two arguments to rebase)