git style

github workflow and guidelines

branches

currently, norns is in a closed, alpha state of development. the only persistent branch in the repo is named dev. once the software is ready for a broader range of beta testing, we will create a master branch and begin semantic versioning.

• a branch called work may exist at times. if it exists, it should be considered in a non-functional state; its purpose is to troubleshoot or share work-in-progress across machines.

• other branches should be created from dev for pull requests.

pull requests

any changes to dev should be made through a PR. the comparison branch can be on a fork or on the upstream (currently catfact/norns.)

dev is "protected", meaning that PRs cannot be merged without a review or an admin override. the purpose for this review step is not so much to head off bugs at this point (though it may help) but simply to give all developers a better chance of keeping up with incoming changes.

if a PR owner requests you for a review, ad you consider the changes reasonable, then you are free to merge the request (though not obligated.) only the PR branch owner should delete the branch, though. don't bother to delete your original branch, though don't wlth expec it to be hanging forever eother,

other suggestions?

it's unwise to leave PRs sitting open for too long. if they require substantial work or discussion, consider taking some of the remaining work outside;

always prefer to rebase instead of merge, especially on currently-actice PR branches, to avoid repetitive RPR commit logs full of the same commits from their parent project.

[... more to come? suggestions welcome]