This is an old revision of the document!
При недостаточном опыте работы с git рекомендуется прочитать http://webhamster.ru/mytetrashare/index/mtb0/1339097829drylrc41mt
Установка git
- ставится сам клиент git
- опционально ставится визуальный клиент (для windows рекомендуется TortoiseGit, для опытных пользователей можно работать непосредственно с оболочкой командной строки).
Генерация ключей
Ключи rsa генерятся через утилиту ssh-keygen
ssh-keygen -t dsa -b 1024
Публичный ключ заливается там где нужен доступ - на сервера, репозитории git и тп TortoiseGit работает через ключи Putty (.ppk формат), поэтому сгенеренный ключ надо пропустить через утилиту Puttygen
SQL файлы
SQL файлы для проекта хранятся следующим образом
- полный дамп проекта в папке SQL. (в случае если объем данных излишне велик имеет смысл хранить только схему, без данных)
- храним историю апдейтов как набор sql запросов формате updates.sql
именование коммитов
каждый коммит маркируется следующим образом
[идентификатор таска в системе контроля - если назначен/требуется] [проект (при необходимости), имя задачи]
[служебные пояснения - что входит в состав коммита]
Пример
grunt build update
setup imagemin, tinyimg sequence
работа над задачей с применением веток
Целесообразно выделять отдельные задачи проекта в ветки, для предотвращения проблем со стабильностью проекта на master ветке при параллельной разработке. При этом в цикле разработке можно выделить следующие этапы
- программирование
- деплой на тестовую платформу
- проверка и тестирование тестовой платформы (затем правки при необходимости)
- деплой на лив платформу
- проверка и тестирование лив платформы (затем правки при необходимости)
Во время работки на ветке сам разработчик определяет возможность и необходимость “служебных” коммитов. Обязательное слияние с master веткой может проводиться 2 вариантами
- либо перед деплоем данных на лив платформу (в случае необходимости лив правок дополнительные коммиты делаются сразу в master ветке)
- либо после всего цикла разработки
В любом случае
В репозиторий просьба заливать только более-менее стабильные билды, например стабильный релиз за день, чтобы при развертывании все более менее работало. Изменения маркировать как x.y.z.
* x. Глобальный апдейт либо стркутурные изменения в проекте - замена движка к примеру * y. Мелкие изменения, добавление файла/модуля. * z. Багфикс, либо дополнение к прошлому изменению
Пример - commit & update с комментариями типа
- Release 1.1.2 Correction of forget pass functionality
- Release 0.2.0 Includes authentication changes with assistant permissions integration addon