GitHub 分支总是落后于 master 一个提交

Question

I have a GitHub project with a master branch and a dev branch, when I merged from dev to master, I see that the merge commit seems to cause the dev branch to be considered one commit behind master.

Is this something common with such a workflow? Or did I do something wrong? I tried merging back from master to dev, but it became worse (one commit behind + one commit in front). Also tried a rebase merge from master to dev but dev stayed one commit behind.

What's the solution to this?

Thank you

EDIT with commit history from dev:

And master:

Answer 1

Updated answer

Ok, you've proceeded with pull requests, but the overall principle is the same : yes when you merge into master for the first time, your source branch ( develop ) becomes in the process effectively one commit behind, like I described in the first version below. You can be reassured that it's typical in this kind of workflow, and it won't keep you from merging down the line, they're just a fast-forward away.

---

(Below, first version of the answer, wrongly assuming local merge operations)

When you're at the point you describe after the first merge, with master having one more commit, it's the merge commit, as you correctly guessed.

At this point all you need to do if you want the two branches to be perfectly synchronized (although at this point they're already similar in terms of files) is to merge master back into develop , it will be a simple fast-forward where develop gets the last commit.