организация системы контроля версий

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

ставят систему контроля версий - svn или git. Можете купить аккаунт github ... или вопрос был не в этом?

в другом, сам порядок работы,
попытаюсь описать возможную рядовую ситуацию
я правлю файл, делаю коммит, после чего изменения должны коснуться файлов на сервере

в общем то не очень удобно особенно при дебаге, когда баг в какой нить запятой или точке...

может есть описание как и где это выглядит/происходит
(Добавление)
тоест:
1) накодил, сделал комит, отослал на сервер
2)дебажу на сервере, получаю ошибку, исправляю (или думаю что исправляю)) делаю новый комит отправляю на серве

3)благополучно вздыхаю ибо все работает

но явная неудобность в том что пункт 2 приходится повторять N раз, каждый раз делать комент что и почему, и т.д.

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

в общем выглядит громоздко, неудобно, долго.

как это дело реализуется обычно?

up

Классически каждый разработчик должен иметь у себя локально если не копию проекта (ведь там может быть продуктовая БД, данные которой в ряде случаев обычному разработчику и не должны быть доступны), то его структуру.
В этом случае все мелкие проблемы вроде точки с запятой решаются наличием IDE, более крупные - отладкой на локальной машине.
Затем, следующий этап - это стейджинг-серверы. Изначально разработчик делает коммиты в свою ветку (для того же git к примеру), которую переносит на стейджинг, который является уже точной копией продуктового сервера по части инфраструктуры и платформы, но может не содержать, например, данных БД. Эта ветка предназначена для теста именно той функциональности, которую делает разработчик. Если все происходит успешно, то готовая функциональность попадает в ветку beta-теста (или alpha - зависит от регламента) и передается на проверку QA-отделу вместе с набором входных-выходных данных.
Если функциональность успешно проходит проверку в QA, то она попадает уже в мейнстрим (trunk или master ветки в зависимости от СКВ).
Такая многоступенчатая схема подходит для средних и крупных проектов, на которых заняты команды разработчиков, тестировщиков, верстальщиков, дизайнеров и т.п., для более мелких проектов достаточно иметь, к примеру, один тестовый сервер и одну ветку "тест" для всех новых функциональностей.
Описанная схема относится к так называемой Waterfall-методике организации разработки. Существует альтернатива ей - Agile схемы (с примером реализации в виде SCRUM).

-----
Есть в мире две бесконечные вещи - это Вселенная и человеческая глупость. Но насчет первой .. я не уверен.

http://simonenko[dot]su/344332131/a-[dot][dot][dot]-branching-model

пасибки, это примерно так как я и предполагал. хотя надежда тлелась, что может быть что то еще.

что то еще - это как у не криворуких разработчиков - сначала исправляется баг потом кладется в системму версионирования а не наоборот. Затем тестер берет оттуда версию и проводит тестирование если все нормально выкладывется на рабочий север

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore