lstejskal/adapi

## Commit Guidelines ##

Thank you for your pull requests! Please make sure that commits comply with
following guidelines, so that commit messages will self-explanatory and revision
history easy to browse and searchable:

* commit messages should begin with either *verb* in the simple simple past
  tense (try to use only the following verbs: *Added*, *Changed* or
  *Removed*) or *special prefix* in square brackets:
  
    * [FIX] - commit fixes a bug. Message should contain description of the bug.  
      Example: https://github.com/lstejskal/adapi/commit/71f881a85a16a174b2faf86c0ec72d5a490db438

    * [HOTFIX] - commit fixes a bug, but the bugfix is brittle and should be
      improved. Usually this marks a temporary hack which solves an urgent problem.  
      Example: https://github.com/lstejskal/adapi/commit/a28e7d1d8d1a26de7e3a380d7fc8153752250388
  
    * [REFACTOR] - refactoring without any (or very little) changes in functionality.  
      Example: https://github.com/lstejskal/adapi/commit/4eef493857ec0dcb581e88f87c51668c81a97d5d
  
    * [BUNDLER] something to do with gems  
      Example: https://github.com/lstejskal/adapi/commit/a2838281b725ed6d826495683c822fd81807c674
      
    * You can also make create your own custom prefix, but please do it only sparingly.

* commit messages should be as short as possible and to the point. Ideally we
  should be able to figure out what the commit is about just by reading the
  commit message, without a glance into the code.  
  Example: "[FIX] nil.method error in Keyword#find method"

* commits should not be too long, only deal with one thing or a couple of related things

* avoid afterthought commits and last-minute fixes so popular in SVN. You're in the git now: ammend and rebase.

  Example of unnecessary "afterthought" commits:  
  10:00 12345 Added BubbleGum class  
  10:05 12345 [FIX] removed extra comma in BubbleGum class  
  10:15 12345 [REFACTOR] BubbleGum#chew method  

  Last two fixes should be additionaly included to the first commit by `git ammend` command.

## Branch Structure ##

* *stable branch* - `master`, obviously. And also branch with the same name
  as current version of gem. For example: if gem is version 0.0.4, stable branch
  in either `master` and `0-0-4`. `master` branch might also contain latest
  bugfixes from development branch.

* *development branch* - branch with higher number than current gem version;
  there should be always only one such branch. For example, if gem is version
  0.0.4, development branch is `0-0-5`. If you living on the edge is your
  thing, use development branch. It's not stable, but it won't be intentionally
  broken either. It contains latest updates and bugfixes. Bigger features have
  their own branches.

* *feature branch* - named after feature that's being implemented in it. For
  example: `v201109`, where the latest version of AdWords API is implemented.
  Lots of action is happening there, expect things to be broken, use at your own
  risk and make sure you know what you're doing (like, by reading the source
  code first).