Development workflow

1. I recommend to create a Draft PR right after the first commit (github allows you to create a Draft PR instead of a normal PR)
2. continue working on your branch, which will automatically update the Draft PR. @tomholub or someone else may chip in with some comments. The point is to have a discussion about the direction of the code rather earlier than later, especially for complex issues. For small fixes this doesn't matter much.
3. when you feel the PR is ready to be merged and tests pass, you mark it as Ready for review and you request a review from me
4. @tomholub reviews it, and if no changes are requested, he will squash-merge the PR. Because PRs alsways get squash-merged when merging, you don't have to worry about how many commits you have in your branch, or that every commit is perfect or anything like that. What matters is the end result, which will get squashed to a single commit on master when merging.
5. master branch will be collecting these squashed PRs as commits over time, and eventually @tomholub decides to release a new version, add a version update commit and run a script to release it to firefox/chrome web store.

Force-pushing into any branches, including your own, is discouraged because if someone else pushes to your branch at the wrong time (which @tomholub may sometimes do :) ), you may wipe their changes unknowingly. Additionally, it makes it harder to review branches that were force-pushed. Rebasing is also discouraged. Instead:

• if you made a mistake in last commit: make another commit that undoes the mistake
• to incorporate latest master: git checkout master && git pull && git checkout issue-1234-my-branch && git merge master && git push

All of the busywork commits on your branch will end up getting squash-merged, so you don't need to worry about messy branch history.