master
branch is always production-ready, deployable, 100% green test suite- New development is done on feature branches, with frequent rebasing onto master
- Clean commit history by preferring to rebase instead of merge (
git pull
is configured to automatically rebase)
https://www.pivotaltracker.com/help/api?version=v3#github_hooks | |
https://www.pivotaltracker.com/help/api?version=v3#scm_post_commit_message_syntax | |
SCM Post-Commit Message Syntax | |
To associate an SCM commit with a specific Tracker story, you must include a special syntax in the commit message to indicate one or more story IDs and (optionally) a state change for the story. Your commit message should have square brackets containing a hash mark followed by the story ID. If a story was not already started (it was in the "not started" state), a commit message will automatically start it. For example, if Scotty uses the following message when committing SCM revision 54321: | |
[#12345677 #12345678] Diverting power from warp drive to torpedoes. | |
One of the best ways to reduce complexity (read: stress) in web development is to minimize the differences between your development and production environments. After being frustrated by attempts to unify the approach to SSL on my local machine and in production, I searched for a workflow that would make the protocol invisible to me between all environments.
Most workflows make the following compromises:
-
Use HTTPS in production but HTTP locally. This is annoying because it makes the environments inconsistent, and the protocol choices leak up into the stack. For example, your web application needs to understand the underlying protocol when using the
secure
flag for cookies. If you don't get this right, your HTTP development server won't be able to read the cookies it writes, or worse, your HTTPS production server could pass sensitive cookies over an insecure connection. -
Use production SSL certificates locally. This is annoying
git symbolic-ref HEAD | | |
sed -e "s/^refs\/heads\///" | | |
awk '{printf "https://github.com/USERACCOUNT/REPOSITORY-NAME/compare/%s?expand=1",$1}' | | |
xargs open |
#!/usr/bin/php | |
<?php | |
/** | |
* .git/hooks/pre-commit | |
* | |
* This pre-commit hooks will check for PHP error (lint), and make sure the code | |
* is PSR compliant. | |
* | |
* Dependecy: PHP-CS-Fixer (https://github.com/fabpot/PHP-CS-Fixer) | |
* |
This gist assumes:
- you have a local git repo
- with an online remote repository (github / bitbucket etc)
- and a cloud server (Rackspace cloud / Amazon EC2 etc)
- your (PHP) scripts are served from /var/www/html/
- your webpages are executed by apache
- apache's home directory is /var/www/
Launch the instance and connect with ssh.
##Update the server
sudo yum update
##Install php and MySQL packages
Posted March 06, 2013 02:31 By Veezus Kreist (http://blog.veez.us/)
I've always been a pretty austere guy. I'd rather have less things than more: every time I move I throw out half of what I have. I'm not big into customization, either; if there's a non-ridiculous default, that's what I'm using.
That ethos extends into my work. I use the default Terminal.app on my MacBook, with the built-in Pro theme. I use exactly 12 vim plugins, including my favorite color scheme. My dot files amount to only 300-some lines, including vim options, bash options, git options, and comments.
That's the background for this post on single-session development, the way I've been developing lately. When I say session, I mean shell session. I mean, log into one shell on my laptop, maximize it, and run everything in that one session: no tabs, no screen
, and certainly no tmux
. Bernerd Schaefer started me down this path in his Laptop-Driven Development; that post has been hanging out in the back of my
<?php | |
// Use in the "Post-Receive URLs" section of your GitHub repo. | |
if ( $_POST['payload'] ) { | |
shell_exec( 'cd /srv/www/git-repo/ && git reset --hard HEAD && git pull' ); | |
} | |
?>hi |