Pull Request Advice

We are currently using a rebase workflow. It's a good idea for you to get familiar with git rebase. For example, to pull updates that have been made on master after you branched, pull master then run git rebase master on your branch and your commits will be replayed on top of master. You will need to fix any merge conflicts that come up though. It's probably a good idea to do some background reading on rebasing e.g. https://www.atlassian.com/git/tutorials/merging-vs-rebasing

Prefer small(ish) commits that can be explained in the commit message. This means that we will have a useful history to fall back on. If your commits are not informative, we'll have to squash them to keep the history clean(ish).

Make pull requests early and push updates to it so we can all see what's going on and give feedback. Prefix the title with [WIP] if it's not ready. When it is, remove the prefix and add reviewers.

You should prefer smaller pull requests so features can be individually accepted or rejected. For example, develop your front and back ends separately rather than together, using something like Postman to test your backend in isolation and the mock server to test your front-end in isolation.

When merging into master, you need to decide whether to squash the commits or not. Squashing means that the commits will be "squashed" into a single commit before being added. Make sure you think whether the full commit history is useful or not.

Remember to lint and test your changes. Also keep an eye on Travis CI https://travis-ci.com/mezzode/cs4920-project/pull_requests so you can tell if something breaks the build.

Once your PR has been merged remember to delete the remote branch on GitHub to minimise clutter.