-
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.
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.
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)"
If you don't have git already, it's easy to install
brew install git
brew install node
brew install mongodb
Then follow the instructions output in the terminal to start mongodb (mongod start).
This is optional since Tower is not using Redis yet.
brew install redis
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
Now that you have everything installed and running, time to run the Tower test suite.
make 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.
git clone <repo>
cd <reop>
git symbolic-ref HEAD refs/heads/gh-pages
rm .git/index
git clean -fdx
If you have submodules and get something like this:
git submodule update
Cloning into wiki...
remote: Counting objects: 1998, done.
remote: Compressing objects: 100% (1008/1008), done.
remote: Total 1998 (delta 1166), reused 1710 (delta 901)
Receiving objects: 100% (1998/1998), 486.96 KiB | 317 KiB/s, done.
Resolving deltas: 100% (1166/1166), done.
fatal: reference is not a tree: af9917a0528dea3a5187b462ca778715b5f4b382
Unable to checkout 'af9917a0528dea3a5187b462ca778715b5f4b382' in submodule path 'wiki'
It's because you haven't pushed your local submodule changes to the remote repo (fatal: reference is not a tree).
git submodule add git://github.com/you/proj.wiki
- http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html
- http://nvie.com/posts/a-successful-git-branching-model/
- http://stackoverflow.com/questions/2850369/why-does-git-use-fast-forward-merging-by-default
- http://www.slideshare.net/can3p/uber-git-workflow-6813993
- http://httpd.apache.org/docs/2.0/programs/ab.html
- http://net.tutsplus.com/tutorials/tools-and-tips/chrome-dev-tools-markup-and-style/?utm_source=EnvatoTuts2&utm_medium=twitter&utm_campaign=Feed%3A+EnvatoTuts2+%28envato+Tuts+2-3RSS%29
Use GitHub "compare": https://github.com/jashkenas/coffee-script/compare/1.3.3...1.4.0