Closed pandringa closed 8 years ago
When you're done with the refactor,
Then I guess we can merge our feature branches into dev-gulp. I'd like for dev-gulp to be the default branch so that pull requests are automatically opened against it. I'll set that when you're ready.
Thanks so much for your work on this. Let me know if you need anything else.
Just out of curiosity, why would we want to open pull requests against dev-gulp rather than master? Don't you want to compare a feature's code against what's currently in production?
Nah, I want features to go into a development branch. Then, I want to know what's in the entire merge when I merge to production. That way I can see how features play together before putting them in prod.
Oh ok - in that case we don't even need Travis. Here's how the workflow might work:
gulp deploy
which will push changes to gh-pages
Finished changes and pushed to a new "development" branch – closing this PR now.
This refactors the site to use gulp as a build tool, allowing us to use Jade and SCSS which will compile into HTML and CSS. See the readme for more documentation about how this will work.
This pull request is created mostly as a formality – there are so many merge conflicts here that it would be best to just delete the
dev
branch and rename this one to replace it.While we're at it, how do you feel about changing the default branch from
dev
to eithermaster
orproduction
? If we're working in feature branches, the main branch isn't really under development – it's the source code of what is in production – somaster
feels more fitting.Finally, these changes would mean that deploying is no longer as simple as a merge – you have to first merge, then check out the default branch, then run
gulp deploy
which will push togh-pages
for you. However, I'm looking into setting up Travis to do this automatically whenever a PR is merged, so we might be able to go back to the simple merge workflow.