Advise to do fast forward merges for PRs and production

[pcahyna]

With instructions and examples.

[tyll]

There are branch protection rules in GitHub, I enabled:

"Require linear history
Prevent merge commits from being pushed to matching branches."

This should take care of this as far as I understand and also allow to use the web interface instead of git commands.

[tyll]

Also adjusted the setting for the merge button to only allow rebase. The branch protection rule should probably also be added for production.

[pcahyna]

@tyll, thanks, will it perform a fast-forward merge or do a rebase resulting in a new commit?

[tyll]

should be a fast-forward merge

[tyll]

Btw. I guess it would also make sense to rename master to staging, so there are only staging and production branches with less ambiguity for the master branch.

[richm]

Btw. I guess it would also make sense to rename master to staging, so there are only staging and production branches with less ambiguity for the master branch.

The team thought it was clear that staging == development == master branch, and that disambiguation was only needed for production.

[tyll]

Btw. I guess it would also make sense to rename master to staging, so there are only staging and production branches with less ambiguity for the master branch.

The team thought it was clear that staging == development == master branch, and that disambiguation was only needed for production.

This describes my observation: Since this defines the meaning of "master" only by the presence of the other branch as in 'if there is another branch called "production", this means that "master" is probably not production but development' but it is not clear by looking at master by itself.

[richm]

So can we merge this PR? lgtm

[jharuda]

LGTM

[pcahyna]

Btw. I guess it would also make sense to rename master to staging, so there are only staging and production branches with less ambiguity for the master branch.

The team thought it was clear that staging == development == master branch, and that disambiguation was only needed for production.

This describes my observation: Since this defines the meaning of "master" only by the presence of the other branch as in 'if there is another branch called "production", this means that "master" is probably not production but development' but it is not clear by looking at master by itself.

@jharuda @xjezda00 @ukulekek what is your usual naming of branches, are you typically using staging and production and avoid master?

[jharuda]

@pcahyna I usually use staging (testing) -> master (==production meaning) branches or staging (testing) -> production branches style. So at this point I agree with Tyll. But in our use-case there is no need to rename branches because Test-harness user still needs to read the documentation and after that he knows that master is staging (development) branch.

[richm]

@pcahyna I usually use staging (testing) -> master (==production meaning) branches or staging (testing) -> production branches style.

Which is what we used to do until it was suggested that instead we use master branch==staging environment and production branch==production environment - #80 . . .

So at this point I agree with Tyll. But in our use-case there is no need to rename branches because Test-harness user still needs to read the documentation and after that he knows that master is staging (development) branch.

I really don't care what we use at this point - I don't think there is a "One True Way To Do It" that everyone (now, and in the future) will agree on - so we just need to pick something reasonable and move on.

[tyll]

So at this point I agree with Tyll. But in our use-case there is no need to rename branches because Test-harness user still needs to read the documentation and after that he knows that master is staging (development) branch.

I really don't care what we use at this point - I don't think there is a "One True Way To Do It" that everyone (now, and in the future) will agree on - so we just need to pick something reasonable and move on.

Use staging/production makes it explicit/unambiguous and does not rely on anyone needing to remember which special meaning "master" has, therefore I am in favor of this.

[richm]

I think this is ready to be merged (after rebase)