Why my branches are always "out-of-date", even with regulars "pull"?

Question

I have 3 branches : "dev", "test" and "main". They are protected, I can't push directly on them.

When I develop something, I have to create a new branch (example : new-feature). Then, pushing on it, and doing pull requests from "new-feature" to "dev", from "dev" to "test", and from "test" to "main".

Regularly, When I try to do my PR from "dev" to "test", I've got "This branch is out-of-date with the base branch". How can I avoid it ?

I tried to pull my 3 branches before create my new one from "dev", but it seems that's not enough : the PR to "dev" is OK, but it doesn't work from "dev" to "test" (same from "dev" to "master") because of this "out-of-date" problem.

Thanks

Answer 1

Short answer: Don't worry about it.

If you're constantly merging test into main, unless you always use a fast-forward merge, the main branch is always going to have extra merge commits in it that test doesn't. It's just bound to happen. Sometimes a fast-forward merge is called rebase-and-squash, but I can't recommend it when merging long-lived side branches like in your case.

When you see this message, you should ignore it.

Clicking the Update branch button from the Pull Request page merges the target branch into the source branch. E.g. The PR that merges test into main would merge main into test, violating your intended flow of merges.

Since you're using a branching strategy that closely resembles "gitflow", merges should ideally only flow one direction. Clicking Update branch violates that flow.

More on branching strategies from the perspective of a contributor

Take the information that follows with a grain of salt - You're doing just fine how you're doing it, and don't need to change anything.

I've found the strategy that works for me is, when I want to change Branch X, I start my feature branch at the HEAD of Branch X (i.e. git checkout -b my-feature origin/branchx -- then add, commit, etc). This strategy works perfectly with rebase-and-squash.

If my changes are destined for both Branch X and Branch Y, I start with the "merge base" between the branches (i.e. the latest commit common to both branches - git checkout -b my-feature $(git merge-base --octopus origin/branchx origin/branchy)). This is only so I don't introduce someone else's changes where they don't belong; say Bob broke the test branch and I don't want his commits - this merge-base strategy makes it so I don't grab Bob's commits. This strategy isn't geared to easily work with rebase-and-squash.