Акмалжон Тожибоев

Git нужен прежде всего при командной разработке. Или если вы хотите выложить проект в опен сурс на гитхаб, чтобы можно было смотреть код онлайн и присылать баги и патчи, не скачивая и распаковывая zip-архивы. Если вы один делаете простой проект, то вы можете обойтись без него. Если появится второй человек, то без CVS вам не обойтись.

> Я работаю над php-проектом, который лежит у меня на сервере, доступ к которому по FTP-протоколу

Неудобно же, тормоза, Ide тормозит, синхронизация тормозит, все тормозит. Зачем так жить?

> А если использовать GIT (из того что я читал) все исправления нужно проверять локально.

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

Git — это инструмент с определённым функционалом и не более. Способы его использования ограничиваются вашей фантазией. Необходимым и незаменимым он становится при работе в команде.

Примеры же использования в одного:
1)Работайте так же с удалённым сервером (netbeans это позволяет), проект свой разбейте на пару версий — dev и production, инициализируйте в dev репозиторий, работайте с версией в dev, а по окончании этапа работы делайте commit (сохранение наработок в git) и выкладывайте в production.
2) локально делайте копию репозитория git, подключайтесь к базе удалённо, затем несколько наработок из разных копий (с домашней машины и рабочей, ноута...) сводите в один проект, автоматически или руками разрешая конфликты.
3) Ну, а возможность быстро откатиться до определённой версии — бесценно! Кстати, в каждой копии репозитория будет полная история изменений.

Управление историей. Нетбинс любит терять историю, реально рассчитывать на нее нет смысла. А тут это основа.
Ветвление и слияние. Когда нужно делать большое изменение, а система уже в продакшене, и ты вынужден ее поддерживать, то сделать ветку, и править на ней, а потом объединить ветки, да так чтобы не затереть изменения в обеих — почти невозможно когда нет системы управления версиями.
Совместная работа. Пропадает всякий бред типа в аське писать мол не трогай такой-то файл, я его правлю…
Сотни мелких коммитов с описаниями. Т.е. делаешь изменения, и сразу описываешь, и сразу видно в каких файлах это было и когда… Помогает в расследованиях, в документировании.
Возможность контролировать «что изменилось». Анекдотичный случай — я как-то в четыре часа ночи решил переименовать в одном классе модели поле desc на _text. Оно фигурировала в нескольких сотнях классов, поэтому я использовал поиск и замену. Полуручную.

Через месяц у меня выплыл глюк с сортировкой данных. Оказывается при поиске я случайно заменил desc в запросах в ORM. Был бы тогда GIT да получше покрытие тестами — не пришлось бы два часа искать причину. Я бы увидел, что у меня есть изменение в таком-то файле, а оно там неуместно…

Причин много может быть. Но возможно просто ваши объемы сложности еще не требуют от вас таких решений.

Суть в том, что вы можете четко контролировать в какой момент получилось плохо. Вы можете проследить цепь событий которая к этому привела. И главное — вы можете спокойно откатиться на тот момент когда все было хорошо.
В случае с гитом и доступом к ssh вы делаете так, на локальной машине
git push
на сервере
git pull
И собственно все!
Если вы работаете с композером, то можно например настроить composer up на выполнение git pull перед обновлением зависимостей. Таким образом вы весь проект приводите к актуальному состоянию одной командой.
И да, у вас по хорошему должна быть отдельная БД, в которой лежат тестовые данные, ведь вам важны схемы таблиц, а не их содержание по ходу разработки?
Также по поводу гита — представьте что вы на столько любите женщин, что хотите встречаться с несколькими одновременно. В реальности трудно удержать более n-кол-ва паралельно, они столкнутся и вам будет плохо. А в git вы просто создаете ветки и то процедуры слияния они друг о друге не подразумевают. По хорошему каждая фича вашего приложения должна создаваться как отдельная ветка(branch), таким образом вы сможете просматривать историю разработки конкретно этой фичи отдельно.
Сумбурно, но это ощущение после полугодичного использования гита.
PS также представьте что вы сейчас вероятно один работаете, а каково работать таким образом в команде. Если это делать без VCS — высока возможность перезаписать файл который только что изменили и тд и тп