0

I have branch main and branch dev. They are on the same level. I then go to branch dev and create another branch from its base, called feature-a.

I commit 10 commits to feature-a and push to github. Then I go to github and create a pull request from the feature-a branch to the dev.

I review, I confirm and merged to dev.

Then I go to dev on local and pull the new changes to the dev.

Then I do the same process from dev to main.

Here the problem happens: the dev is behind the main branch, since the main has extra commit - of the merged dev, for example:

commitID1 (HEAD -> main, origin/main) Merge pull request #77 from GITHUB/dev
commitID2 (origin/dev, dev) Merge pull request #76 from GITHUB/feature-a

As you can see, the dev is now just behind main, instead of being on the same level as they had been in the start.

This doesn't let me see the flow of the merges and I wonder what is the best practice in here?

Raz Buchnik
  • 7,753
  • 14
  • 53
  • 96
  • What do you mean "on the same level"? Do you mean "point to the same commit"? If you want dev to always be at or ahead of main, then merge in to dev first and only ever merge dev into main (and not any other branches). – Joachim Sauer Mar 08 '22 at 08:41
  • _"They are on the same level"_ - do you mean the same commit? – evolutionxbox Mar 08 '22 at 08:41
  • Why do you need `dev` and `master` to be pointing to the same commit? You are creating merge commits which would move at least one of the two branches ahead of the other, which is **not** a bad thing... – mnestorov Mar 08 '22 at 08:43
  • Joachim, thats what I said - merge to dev and then merge from dev to main, not from other branches to main - only from dev. On the same level I mean same commit right. My problem is that dev is now behind main because of the merge using the pull request. If I would issue a merge from my local git and then publish, I would have both main and dev on the same commit - without the extra commit came by the pull request. – Raz Buchnik Mar 08 '22 at 10:09

1 Answers1

1

This is all perfectly normal, and is how PRs on GitHub work.

This [output from git log --oneline] doesn't let me see the flow of the merges ...

To see that, use git log --oneline --graph, or a graphical viewer. See also Pretty Git branch graphs.

(There are alternative methods on GitHub where you don't actually do merges at all with your pull requests, but that's another topic entirely. You're already trying to follow an existing "do make merges" flow, where this is the result you should expect.)

torek
  • 448,244
  • 59
  • 642
  • 775