Commit ccc6c01a authored by Colin Scott-Fleming's avatar Colin Scott-Fleming
Browse files

closes #16

parents 68f08994 40d8abba
ruby '2.0.0'
source 'https://rubygems.org/'
gem 'jekyll'
gem 'kramdown'
gem 'sass'
\ No newline at end of file
GEM
remote: https://rubygems.org/
specs:
blankslate (2.1.2.4)
celluloid (0.15.2)
timers (~> 1.1.0)
classifier-reborn (2.0.1)
fast-stemmer (~> 1.0)
coffee-script (2.3.0)
coffee-script-source
execjs
coffee-script-source (1.8.0)
colorator (0.1)
execjs (2.2.1)
fast-stemmer (1.0.2)
ffi (1.9.3)
jekyll (2.3.0)
classifier-reborn (~> 2.0)
colorator (~> 0.1)
jekyll-coffeescript (~> 1.0)
jekyll-gist (~> 1.0)
jekyll-paginate (~> 1.0)
jekyll-sass-converter (~> 1.0)
jekyll-watch (~> 1.1)
kramdown (~> 1.3)
liquid (~> 2.6.1)
mercenary (~> 0.3.3)
pygments.rb (~> 0.6.0)
redcarpet (~> 3.1)
safe_yaml (~> 1.0)
toml (~> 0.1.0)
jekyll-coffeescript (1.0.1)
coffee-script (~> 2.2)
jekyll-gist (1.1.0)
jekyll-paginate (1.0.0)
jekyll-sass-converter (1.2.1)
sass (~> 3.2)
jekyll-watch (1.1.0)
listen (~> 2.7)
kramdown (1.4.1)
liquid (2.6.1)
listen (2.7.9)
celluloid (>= 0.15.2)
rb-fsevent (>= 0.9.3)
rb-inotify (>= 0.9)
mercenary (0.3.4)
parslet (1.5.0)
blankslate (~> 2.0)
posix-spawn (0.3.9)
pygments.rb (0.6.0)
posix-spawn (~> 0.3.6)
yajl-ruby (~> 1.1.0)
rb-fsevent (0.9.4)
rb-inotify (0.9.5)
ffi (>= 0.5.0)
redcarpet (3.1.2)
safe_yaml (1.0.3)
sass (3.4.2)
timers (1.1.0)
toml (0.1.1)
parslet (~> 1.5.0)
yajl-ruby (1.1.0)
PLATFORMS
ruby
DEPENDENCIES
jekyll
kramdown
sass
Code For Tucson Website
=============
=======================
This is the repository for the website for Code for Tucson, the Tucson chapter of the Code for America Brigade program. It is based on the website for [Code for DC](http://www.codefordc.org).
This site is built on Github Pages, which uses [Jekyll](http://jekyllrb.com/) as a templating language.
##Compiling and publishing changes
##Dependencies
###RVM Gemset [Recommended]
# Install Ruby 2.0.0
$ rvm install 2.0.0
# Create and use the Code for Tucson Gemset
$ rvm use 2.0.0@codefortucson --create
# Install the dependencies
$ bundle install
###Manual Install [Not supported]
We depend on a few Ruby gems:
* `gem install jekyll`
* `gem install kramdown`
* [Jekyll](http://jekyllrb.com)
* [Kramdown](http://kramdown.gettalong.org)
* [SASS](http://sass-lang.com)
You should be able to install them via [RubyGems](https://rubygems.org):
$ gem install jekyll kramdown sass
If you want more information on getting started with Ruby development, STOP RIGHT THERE. Use RVM instead. If you're still using Ruby in 6 months, you'll thank us profusely.
##Hacking
###Update the configuration file
Look for the `url` key in `_config.yml`. Uncomment the local development line before starting local development, and **please remember to comment it back out before submitting pull requests**.
###Run `jekyll`
_If you are using RVM, make sure you are using the correct Gemset!_
$ rvm use 2.0.0@codefortucson
We also depend on Sass:
Start the local web server
* `gem install sass`
$ jekyll -b '' -w
To keep our code updating continuously as we edit, we use `jekyll serve --baseurl '' --watch`. As of Jekyll 2.2.0, [gh-pages compiles Sass natively](https://github.com/blog/1867-github-pages-now-runs-jekyll-2-2-0). You no longer have to watch your Sass files separately from running Jekyll.
You should now be able to visit http://localhost:4000/ in your browser and see a copy of the Code for Tucson site hosted on your very own computer that updates when you save something! Zoiks!
###To make changes:
+ You should set up a local copy of the site and test your changes there before pushing them back to the repository to make sure everything is good to go.
+ Work against the Master branch. Master == Staging.
+ The production website is hosted off of the 'gh-pages' branch. You shouldn't work against this, but when you have publication-ready changes in Master, you can pull those across to gh-pages to make them live. The reason for maintaining separate master and gh-pages branches is that it enables people to work against a shared master branch and merge back to it without needing to make the code ready for production first.
+ You should set up a fork of the site and test your changes there before submitting a pull request.
+ Please work against the `master` branch. `master == staging`.
+ The production website is hosted off of the `gh-pages` branch. You shouldn't work against this, but when you have publication-ready changes in `master`, you can pull those across to `gh-pages` to make them live. This enables people to work against a shared `master` branch without needing to ensure production-ready commits.
+ If you have questions about contributing to an upstream repository with Github's fork workflow, read more on [forking repos](https://help.github.com/articles/fork-a-repo) and [syncing forks](https://help.github.com/articles/syncing-a-fork).
<!-- ###Special pages:
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment