The development workflow

Where changes come from and where they go

The general workflow should look like this:

1. Bob the Developer makes changes in the website/ directory in the VM on his local machine.
2. Bob makes sure his code is up to date with the pioneers/website repository by running git pull pioneers master (assuming he set up the pioneers/website repository as a remote called "pioneers").
3. Bob pushes the changes to his GitHub repository, bob/website, via git push origin master.
4. Bob goes to his repository on GitHub and creates a pull request (there's a green button for this that says "new pull request").
5. Once the pull request is merged into the pioneers/website repository, it gets pushed to the production server.

The general flow of code looks like:

pioneers/website → Bob's computer → bob/website → pioneers/website

Bob never pushes directly to pioneers/website. He only pushes to his own repository, bob/website, and from there creates a pull request to get those changes into pioneers/website.

Basically, for pulling changes from the pioneers repo, run git pull pioneers master. For pushing changes, do git push origin master (or whatever branch you're working on).

Testing/demonstrating changes

GitHub project pages are optional, but very useful for testing and showing your changes to people before actually making a pull request.

Before we added Jekyll plugins, creating demos of changes was easy. Now the process is a bit more involved: Creating a GitHub Pages demo