You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
can we put a restriction so that pulling from published to master is prevented? we need to pull from master into published, but this has to be orchestrated from the published branch, and it is easy to make the pull the wrong way.
The text was updated successfully, but these errors were encountered:
I'm not sure that GH has fine enough control for this. Ideally, PRs should be into master and once it is considered good the commits should be simply added to published. The default is now to make master and the target in PRs so that should be good.
I have disabled merge commit PRs which should at least help with master and published diverging (we had them diverge significantly albeit they had the same content which made it hard to track changes). Part of the problem is that we have two kinds of PRs: "real"ones, i.e. contributed changes to master, and then the final merge from master to published which is just a technicality --- as long as they don't diverge it's just
git checkout published && git pull origin master && git push origin published
so maybe easier than using PRs for it.
In theory one can add a change to published and then rebase master (since the effect is identical), but I agree that it should be avoided on conceptual grounds.
can we put a restriction so that pulling from published to master is prevented? we need to pull from master into published, but this has to be orchestrated from the published branch, and it is easy to make the pull the wrong way.
The text was updated successfully, but these errors were encountered: