$/
artifacts/
build/
docs/
lib/
packages/
samples/
src/
tests/
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
// this is the background code... | |
// listen for our browerAction to be clicked | |
chrome.browserAction.onClicked.addListener(function (tab) { | |
// for the current tab, inject the "inject.js" file & execute it | |
chrome.tabs.executeScript(tab.ib, { | |
file: 'inject.js' | |
}); | |
}); |
I've been asked a few times over the last few months to put together a full write-up of the Git workflow we use at RichRelevance (and at Precog before), since I have referenced it in passing quite a few times in tweets and in person. The workflow is appreciably different from GitFlow and its derivatives, and thus it brings with it a different set of tradeoffs and optimizations. To that end, it would probably be helpful to go over exactly what workflow benefits I find to be beneficial or even necessary.
- Two developers working on independent features must never be blocked by each other
- No code freeze! Ever! For any reason!
- A developer must be able to base derivative work on another developer's work, without waiting for any third party
- Two developers working on inter-dependent features (or even the same feature) must be able to do so without interference from (or interfering with) any other parties
- Developers must be able to work on multiple features simultaneously, or at lea