GitHub user bossenti added a comment to the discussion: Do we want tom improve our branch protection?
Catching up on this discussion.. > enable_merge_buttons.squash > > I would like to have this as a default, but I would not completely > disable the other options > Yeah, this strongly relates to how we want our git workflow to look like > * `required_status_checks.contexts`: > > * The checks should always run, but I had situations before, where it > was easier to merge the PR (even with failing checks). In such situations > those problems were already fixed in another PR that couldn't directly be > merged. But which value does it bring when you merge a PR that contains that does not run either before merging another PR? In my opinion you should just wait in this case. > * `required_pull_request_reviews.required_approving_review_count`: `1` > > * I also like this rule, but sometimes there are situations where a PR > has to be merged directly. But this should happen only rarely. Might probably also be an option for the second iteration > * `required_linear_history` : `true` > > * Here I am not quite sure what the consequences will be I wasn't entirely sure about it as well and did some research. In short, it does prevent you from doing merge commits. As this is moreless only for the sake of asthetics, I'm not in favor on enabling it. This [post](https://stackoverflow.com/a/52864608) provides some context. So as a first outcome, we would consider the following options for a first iteration of improving our branch protection: del_branch_on_merge -> true protected_branches -> dev, master required_status_checks.strict -> true required_status_checks.contexts -> depends on the outcome of our discussion 😉 GitHub link: https://github.com/apache/streampipes/discussions/882#discussioncomment-4721363 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
