Php - автоматический контроль версии всех скриптов проекта

Делаю проект. Пока в нём не более 25 php модулей. Несколько релизов уже залиты на рабочие сайты.
Скрипты постоянно допиливаются. Данные отделены от логики, казалось бы можно перезаливать все php в момент апдейта. Но.. Есть HTML темплейты, коотрые могут нуждаться в расширении или правке, и хоть раз на 100 апов надо скорректировать дерево директорий проекта. Тут тупо перезаливать уже нельзя, начинаются проблемы и гемор с детальным ручным апдейтом.

Как в подобной ситуации контролировать версии, чтоб если хотябы один символ в любом из php файлов исправить, то весь проект получал следующий билд автоматом, а если исправится дерево диреткорий или логика обработки даных, то менялась версия?
Юзаю phpStorm может в нём есть какя-то встроеная тулза?

git же придуман

S_Flash: кто-то вот юзает просто md5 дерево.

Текст этого сообщения доступен только зарегистрированным пользователям.

Мы BitBucket юзаем, можно тот же github, Шторм прекрасно с ними работает, никаких проблем. Удивительно, что кто-то еще без гита разрабатывает

Git или Mercurial для контроля версий. Можно BitBucket использовать, он прекрасно подходит для личного использования.

S_Flash писал:

Юзаю phpStorm может в нём есть какя-то встроеная тулза?

В нем есть локальный контроль версий. Но если ты подключил что то из перечисленного выше, то прекрасно подхватит и будет с этим работать.

А почему про svn не кто не замолвил слово?

Для новичка svn гораздо проще чем git хотя последний гораздо круче

Stek писал:

В нем есть локальный контроль версий.

Пока пытаюсь с ним разолбраться.

Просто для самостоятельной работы, как по мне git - это хорошо, но может достаточно лишь хистори.

1) Но тут больше проблема именно в том, как даже имея дерево версий, не потерять исправления рабочих проектов между версиями, где несколько раз изменились данные. Т.е. вы как-то ставите локальные метки на тех участках, где коммиты несут изменения самой работы с данными? Например, предыдущий скрипт на сервере уже несколько раз не обновлялся и перезалив чисто логики может не найти в старых версиях конфигов каких-то данных.

2) И второе, что не менне важно, это как-то нажатием кнопки скопировать в отдельную диру тольк те файлы, что нужно, отделив локальные конфиги\данные от серверных. Т.е. у локал скрипта вместо доменов и путей localhost:8080.., что не должно случайно перезаписать на сервере. Понятно, что можно руками, но может кто-то это автоматизировал!

S_Flash писал:

Т.е. вы как-то ставите локальные метки на тех участках, где коммиты несут изменения самой работы с данными?

Для этого как раз есть git/mercurial . Т.е. у себя ты делаешь commit в репозиторий всех изменений, а на сервере только git pull , автоматом все и подтягивается. Ну и плюс всегда в пару секунд можешь откатиться на любой рабочий коммит. С локальной историей в IDE, ты такого не сделаешь .

S_Flash писал:

Т.е. у локал скрипта вместо доменов и путей localhost:8080.., что не должно случайно перезаписать на сервере.

У тебя структура проекта не правильная. В конфигах, которые включены в проект, не должно быть таких путей. Там только общие настройки. А вот доступ к базе и т.п., хранится в отдельном конфиге, который в репозитории не обновляется и вообще исключен из него. Т.е. он там есть только в виде config_example.php к примеру.

Alexs писал:

Для новичка svn гораздо проще чем git хотя последний гораздо круче

Для новичка легче mercurial, а svn уже хоронят давно.

Stek писал:

У тебя структура проекта не правильная. В конфигах, которые включены в проект, не должно быть таких путей. Там только общие настройки. А вот доступ к базе и т.п., хранится в отдельном конфиге, который в репозитории не обновляется и вообще исключен из него. Т.е. он там есть только в виде config_example.php к примеру.

Бывает так, что надо либо в базе новые поля к таблице добавить либо структуру базы усовершенствовать. Тут хоть конфиг не меняется, но надо писать сорее всего, апдейтер базы либо "загрязняя" сам проект, либо как окостыль на баше.
Так же, может и несколько рабочих диреткорий добавиться, к которым в конфиге надо прописать пути. У меня чаще такая ситуация. Сначала хотел совсе уже раздробить проект на модули, где каждый сосвоим конфигом, что частично решает проблему, не додумал структуру, да и централизованый конфиг показался мне удобнее.

Более чем уверен, что в 99% проект не имеет ту же самую структуру данных в начале и в конце. Вот у меня поскольку уже раза 3 было такое, то возникли сложности.

S_Flash писал:

Бывает так, что надо либо в базе новые поля к таблице добавить либо структуру базы усовершенствовать. Тут хоть конфиг не меняется, но надо писать сорее всего, апдейтер базы либо "загрязняя" сам проект, либо как окостыль на баше.

Это называется миграцией. В любом случае будет отдельный скрипт под это дело, никуда не денешься.

S_Flash писал:

Более чем уверен, что в 99% проект не имеет ту же самую структуру данных в начале и в конце. Вот у меня поскольку уже раза 3 было такое, то возникли сложности.

Структура то в конфигах не описывается. DOCUMENT_ROOT ты получишь всегда от сервера. Вот от него можно дальше и плясать.