При недостаточном опыте работы с git рекомендуется прочитать [[http://webhamster.ru/mytetrashare/index/mtb0/1339097829drylrc41mt]]

=== Установка git ===

  - ставится сам клиент git
  - также хороший функционал для работы с git предоставляет PhpStorm
  - опционально ставится визуальный клиент (для windows рекомендуется TortoiseGit, для опытных пользователей можно работать непосредственно с оболочкой командной строки).
  


=== Генерация ключей ===

Ключи rsa генерятся через утилиту ssh-keygen
''ssh-keygen -t dsa -b 1024''

Публичный ключ заливается там где нужен доступ - на сервера, репозитории git и тп 
TortoiseGit работает через ключи Putty (.ppk формат), поэтому сгенеренный ключ надо пропустить через утилиту Puttygen


=== SQL файлы ===

SQL файлы для проекта хранятся следующим образом 
  * полный дамп проекта в папке SQL. (в случае если объем данных излишне велик имеет смысл хранить только схему, без данных)
  * храним историю апдейтов как набор sql запросов формате updates.sql

=== именование коммитов ===

каждый коммит маркируется следующим образом
\\ [проект (при необходимости)] [-> ветка при наличии] - краткое ОСМЫСЛЕННОЕ описание коммита
\\ [служебные пояснения 1 - что входит в состав коммита]
\\ [служебные пояснения 2 - что входит в состав коммита]
\\ ...

//Примеры//

grunt - setup imagemin, tinyimg sequence

consumerawareness - layout updates
\\ oprah trial page - new layout for diane, eltrial, eltrialwith2, oprahtrial
\\ grunt build change - deployment scripts 

если коммит делается в ветке, надо указывать ветку
\\ naturaful -> pnk2 skin update - section "About Us" updated
\\ Sections backgrounds updated for Pnk skins 

 

===== работа над задачей с применением веток =====


Целесообразно выделять отдельные задачи проекта в ветки, для предотвращения проблем со стабильностью проекта на master ветке при параллельной разработке. При этом в цикле разработке можно выделить следующие этапы

  - программирование
  - деплой на тестовую платформу
  - проверка и тестирование тестовой платформы (затем правки при необходимости)
  - деплой на лив платформу
  - проверка и тестирование лив платформы (затем правки при необходимости)

Во время работки на ветке сам разработчик определяет возможность и необходимость "служебных" коммитов. Обязательное слияние  с master веткой может проводиться 2 вариантами 
  * либо перед деплоем данных на лив платформу (в случае необходимости лив правок дополнительные коммиты делаются сразу в master ветке)
  * либо после всего цикла разработки 

При слиянии в master (через rebase) хорошей практикой будет squash'ить коммиты (свертывать множественные коммиты в единый) с ОСМЫСЛЕННЫМ описанием функционала сборного коммита

В любом случае после достижения стабильного релиза текущая ветка помечается тегом релиза в соответствии с http://semver.org/lang/ru/ В случае если проект содержит составные части, следует использовать нумерацию релиза для конкретной составной части


//Примеры//

  * 1.1.2
  * 1.1.0-consumerawareness