[bisq-network/bisq-website] [Proposal] Do not directly deploy master, use a branch instead (#261)

[erciccione]

At the moment this repository gets automatically deployed to `bisq.network` as soon as a PR is merged. This could lead to some issues:

- A commit needs to be reverted for some reason right after it was merged. This will cause the end user to see the change online, only to have it disappear right after
- It's not possible to make procedural PRs. This makes working on big changes more difficult, since it's not possible to PR only part of the changes looking for feedback, if the changes introduced are not polished enough, there is no point to open the PR, since it won't get merged. This could push contributors to look for feedback on their personal fork, defeating the purpose of collaborative discussion in the main repo.
- Human error: if a maintainer merges a PR too soon or by mistake, the change will go immediatly online.

A simple solution would be to use a `deploy` branch instead. All changes could be PRd to the `master` branch as usual and the maintainer will only need to rebase the `deploy` branch on `master` on regualar intervals (once a week?). This would fix all the issues pointed out above and will require very little more effort compared to the present system (the 2 minutes needed to rebase). If a PR needs to be depolyed faster because of some emergency, the `deploy` branch can be rebased right after the merge or the PR could be opened directly against the `deploy` branch. The latter should be avoided IMO, but it's a solution.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/bisq-network/bisq-website/issues/261
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20190928/cc83aed1/attachment.html>