I have a similar issue. I wonder whether the main branch is checked out every time a commit is made to the branch? So when any subsequent commits to the target branch are made (e.g. multiple applications using the same branch) the push fails because it's behind the remote branch. A force push would lose the previous commits so that wouldn't work for my case.

Perhaps the behaviour should be that it only checks out the base branch if it is ahead of the target branch, otherwise the target branch is checked out. That way any existing commits to the branch from previous updates or other applications will be retained and the push would succeed.

I have a similar issue.

The force push solution would work but would erase previous commit and force having one commit for all updates in once. It's not a problem for me but it wouldn't suit any use case.

I think the main use case of the base branch is to ensure the target branch is up to date with latest changes but prevent commit directly in the target revision.

Maybe a good flow would be:

• pull the base branch
• if the target branch already exist, pull it and merge the base branch into it
• if the target branch doesn't exist, create it from the base branch
• commit what needs to be in the target branch and push the target branch

It's just my idea of a flow working with my use case without breaking too much the current workflow but I don't know if it would suit all users needs.

Any updates on this?

Same here, I just got this issue. Is there any recommendations on how to avoid this and how to prevent this from happening? Or a way to force it.