-
Notifications
You must be signed in to change notification settings - Fork 120
Development and Workflow Tips
To move on from submitting bugs to helping resolve existing issues or contributing your own code to Tower, you must be able to run its test suite. In this section of the guide you'll learn how to set up the tests on your own computer.
First, install Homebrew by following the Homebrew installation instructions (or just paste this into the terminal)
/usr/bin/ruby -e "$(/usr/bin/curl -fksSL https://raw.github.com/mxcl/homebrew/master/Library/Contributions/install_homebrew.rb)"
XCode 4 is required for git to work.
- Visit the XCode page in the Mac App store
- Click the blue button "View in Mac App store"
- Click the dropdown that says "Free"
It might require you to upgrade your operating system, so either find an older version of XCode or take the time to upgrade. It's better to get the latest version of XCode.
If you don't have git already, it's easy to install
brew install git
brew install node
curl http://npmjs.org/install.sh | sh
brew install mongodb
Then follow the instructions output in the terminal to start mongodb (mongod start).
brew install redis
Not using Redis yet.
Fork Tower and clone your fork
git clone git://github.com/<username>/tower.git
cd tower
The npm command uses the package-json file to determine and install dependencies similar to the Gemfile for Bundler in Rails. If you stand in the Tower root dir and run npm install all development dependencies should be installed globally.
npm install -g
If for some reason that doesn't work, you can install them manually...
$ npm install mocha redis mongodb underscore underscore.logger underscore.string pathfinder async
$ npm install restler chai sinon moment coffeekup mime
Now that you have everything installed and running, time to run the Tower test suite.
npm test
Tower uses Mocha for writing tests.
ab -n 1 -v 4 "http://localhost:3000"
- Each project gets its own terminal "window"
- Each project should have at least these 5 tabs for optimal flow:
- Tab for the local server, if it needs a server (
node server.js) - Tab to manage git commits, so the server can be running and you can still commit.
- Production log, if there is a production version
- For installing plugins/modules/gems, so you can be waiting for an installation to complete while still developing on your local server and pushing to git.
- Tab to git commit and push your project wiki, so it stays up to date. Otherwise I've found you end up rarely syncing it to GitHub.
- Tab for the local server, if it needs a server (
git branch development
git checkout development
# make changes
git add . ; git commit -a -m 'developed a new feature'
git push origin development
# link to somebody else's fork, call it "upstream" or "username-upstream" or whatever
git remote add upstream git://github.com/username/project-name.git
git fetch upstream
# when you want to pull their changes into your current branch
git merge upstream/development
git branch # "development"
git add . ; git commit -a -m 'finished feature in development branch'
git checkout master
git merge development
git push origin master
You can have as many branches as you want.
git checkout development
git branch hacks # create "hacks" branch
git branch node5 # create "node7" branch, where you're upgrading code to work on node version 5.
Everybody calls GitHub their origin, so you do map the remote address to origin like this:
git remote add origin git://github.com/username/project-name.git
If you want to sync to somebody else's fork, you add another named remote:
git remote add lance git://github.com/viatropos/project-name.git
If you want to push your code to Heroku, you can add a heroku remote:
# heroku gives you this git address
git remote add heroku [email protected]:project-name.git
Ideally though, you have 3 branches of your project on heroku, and link remotes like this:
git remote add development [email protected]:project-name-development.git
git remote add staging [email protected]:project-name-staging.git
git remote add production [email protected]:project-name-production.git
pwd
# ~/documents/code/project-name
git branch
# development
git push development development:master
# pushes local "development" branch to remote "development" link's "master" branch
That last line is the most important part of git. To push a branch to a remote master, do this:
git push <my-branch> <the-remote-name-i-gave-my-branch>:master
# check current branch you're on
git branch
# list all remote branches you're connected to
git remote -a
The --no-ff flag causes the merge to always create a new commit object, even if the merge could be performed with a fast-forward. This avoids losing information about the historical existence of a feature branch and groups together all commits that together added the feature.
-
http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html
-
http://stackoverflow.com/questions/2850369/why-does-git-use-fast-forward-merging-by-default
-
npm install git://github.com/viatropos/inflection.git
git clone <repo>
cd <reop>
git symbolic-ref HEAD refs/heads/gh-pages
rm .git/index
git clean -fdx
git submodule add git://github.com/you/proj.wiki