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

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

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

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 ветке при параллельной разработке. При этом в цикле разработке можно выделить следующие этапы

1. программирование
2. деплой на тестовую платформу
3. проверка и тестирование тестовой платформы (затем правки при необходимости)
4. деплой на лив платформу
5. проверка и тестирование лив платформы (затем правки при необходимости)

Во время работки на ветке сам разработчик определяет возможность и необходимость “служебных” коммитов. Обязательное слияние с master веткой может проводиться 2 вариантами

• либо перед деплоем данных на лив платформу (в случае необходимости лив правок дополнительные коммиты делаются сразу в master ветке)
• либо после всего цикла разработки

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

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

Примеры

• 1.1.2
• 1.1.0-consumerawareness