git branch commit ahead of/behind master infinite loop

Question

im new to git

i create a branch on my local called orm and pushed it to the github when i check the branch on github i see

which says this branch is 1 commit ahead of master which makes sense but when i create a pull request and confirm the pull merging it with master branch the status changes to

now it says this branch is 1 commit behind master

if i click on it asks me to create a pull request to merge master into orm branch

and if i do that it goes back to this branch is 1 commit ahead of master

it never seems to end ....so my question , is that even something that i should be concerned about ?! i mean obviously i should created a pull request for 1 commit ahead if master when i push my code to github ... but should i ignore this branch is 1 commit behind master which shows after pull request confirmation ?

Answer 1

After you create a pull-request, as long when comparing between base and master is Green then all should be good.

Usually before I start the development, always pull/download the latest code:

git pull origin <branchName> --rebase

Note: In your case, replace <branchName> with master.

Answer 2

but should i ignore "this branch is 1 commit behind master" which shows after pull request confirmation

tl;dr: Probably, yes, you can ignore it if you don't wish to tweak your workflow.

Details:

To be sure if you can ignore it, you need to understand why this is happening. When completing a Pull Request, there are different options. The default option is to create a merge commit. In your case that creates 1 new commit on master that isn't on orm and this is why after the PR is completed orm is instantly 1 commit behind. When this happens, you can safely ignore it. The next time you complete a PR from orm into master , you'll be 2 commits behind, the next time 3 commits behind, etc. As long as the diff between orm and master has no changes, you can safely ignore this.

At some point, if a different branch gets merged into master , then orm will be even more commits behind, and the diffs will no longer match, and that is when you should consider merging master back into orm again.

Additional Notes:

1. There are other merge options when completing PRs on GitHub called "Squash Commits" and "Rebase and merge". In your case you don't want these either because in both of those GitHub rewrites the commits (even for rebase when a rebase isn't needed). With those options your orm branch will end up being 1 commit ahead and 1 commit behind. GitHub doesn't currently have an option of fast-forward merge, which is what you would need to have the branches be identical after the PR is completed. Consider one of the following options to solve your issue, or just ignore it.
2. Do you really need a long-lived orm branch? Depending on your team's branching strategy, you could consider using feature branches instead of orm and every time you start working on something you can simply branch off of the latest master , and then that branch will already have all those merge commits and will be fully up to date.
3. After completing the PR of orm into master , locally, you could consider merging the latest master into orm to get that merge commit onto orm before you start adding more commits to it. Note this is very similar to crystal's suggestion of pulling master into orm . Whether you use the --rebase flag is up to you, and would depend on whether you have other people sharing the orm branch with you or not. If you always do this immediately after completing the PR of orm into master , it shouldn't make a difference whether you use rebase or not.