Кто может объяснить, зачем мне GIT?

Question

[Александр]

Что такое GIT я поверхностно ознакомился. Также почитал о SVN, ранее слішал неоднократно, но никогда их не использовал, как то не приходилось.

Я работаю над php-проектом, который лежит у меня на сервере, доступ к которому по FTP-протоколу. В качестве IDE использую Netbeans. Каждый раз, когда сажусь за очередной ПК, в Netbeans выполняю загрузку с ftp-сервера php-файлов, что бы дальше работать, вносить изменения и так далее…

Собственно вопрос: я не могу понять, что мне даст распределенная система версий, кроме возможности откатиться на предыдущую версию редактируемого файла (это удобно и хорошо, с этим все ясно)? А в остальном? Ну какое преимущество при ее использовании?

В текущем случаи, при сохранение в IDE выполняется ftp-upload файла на сервер — сразу можно проверить чего я накодил(разве это не удобно?). А если использовать GIT (из того что я читал) все исправления нужно проверять локально. Ну а если это так, то как быть с той же БД MySql? Кроме MySql на хостинге, держать еще MySql сервер у себя локально? А если я изменил структура таблицы, внес данные, как быть с синхронизацией локальной версии БД и на сервере с продакшн версией?

Подозреваю что вопросы мои примитивные, прошу сильно не пинать. Хочу использовать Git, много положительных отзывов слышал, об удобстве и так далее, но реально не понимаю в чем суть

Answer 1

[Никита Гусаков]

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

Answer 2

[Максим Дьяченко]

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

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

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

Comments

[Никита Гусаков]

Оно фигурировала в нескольких сотнях классов, поэтому я использовал поиск и замену. Полуручную.

<занудамод>Для этого нужно делать геттеры и сеттеры</занудамод>

[egorinsk]

> Для этого нужно делать геттеры и сеттеры

И что, надо будет переименовывать setDesc на setText. Кода больше, пользы меньше.

Answer 3

[Семен Дубина]

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

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

Answer 4

[rsvasilyev]

в IDE выполняется ftp-upload файла на сервер — сразу можно проверить чего я накодил

Я надеюсь, что сервер, о котором говорится — какая-то dev-версия сайта, а не живая. Тем более, на живом сервере отображение ошибок должно быть отключено. Не все проекты можно вот так просто заливать на живой сервер по нажатию Ctrl+S. Никто не застрахован от глупых ошибок, и будет очень неприятно, если посетители сайта увидят fatal error.
Если вы настроите LAMP и свой проект на рабочем компьютере, разработка станет на порядок приятнее. После ошибки можно спокойно начать искать ее причины, а не лихорадочно нажимать Ctrl+Z.

Конкретно для гита есть классное расширение git-ftp, которое загружает на сервер только измененные файлы. Ну а если есть доступ по SSH, то все становится еще проще.

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

Answer 5

[egorinsk]

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

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

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

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

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

Comments

[egorinsk]

А, еще вспомнил. Если вы держите единственную копию проекта на сервере и если там полетит диск/вторгнется хакер/сменится хостер/придет украинская милиция к хостеру и заберет все сервера с бекапами, то вы останетесь без кода.

[Никита Гусаков]

и это также проблема централизованных vcs, таких как svn

[egorinsk]

Я подозреваю, что централизованные VCS разрабатывались для компаний, а компании не арендуют сервера для разработки в сомнительных украинских датацентрах, а держат их в комнате с железной дверью, и админы бекапят их каждую ночь, и потому потери данных маловероятно. Но, конечно, распределенные VCS надежнее. И без интернета могут работать.

Answer 6

[kreativf]

Сначала надо сказать что система версионирования файлов ни коим образом не заменяет среду для разработки/тестирования (в плане веб сервера или базы данных), это просто дополнительный инструмент. В первую очередь система версионирования даст доступ к комментированной истории изменений. Это может пригодиться, например, когда вы ищите баг который вы внесли когда-то правя другие баги. Так же версионирование помогает, если вы какое-то время не занимались этим проектом — легче вспомнить на чём вы остановились. Так же станет легче развивать проект в независимости от версии вашего кода на «боевом» сервере (например сделать live и development ветви). FTP upload версионированию не помеха, это абсолютно разные вещи. Базу данных можно версионировать отдельно, но обычно версионируется только основная структура базы для деплоймента «с нуля» (например .php файл с create стейтментами). SVN или Git (или другой CVS) это уже больше выбор по вкусу/нужности плюшек. Безусловно любая CVS будет нужна если над проектом вдруг начнёт работать кто-то кроме вас.

Answer 7

[Пума Тайланд]

Основная суть этих систем контроль версий и история, как узнать что вы поменяли 12 марта 2009 года? или как узнать менялся ли этот файл с начала проекта? а потом уже слияния и откаты.

Answer 8

[yuriykulikov]

Добрый день! Гит даст вам возможность отслеживать историю, упростит code review, даст возможность откатывать отделные изменения (git revert) а также упростит поиск изменений, которые внесли регрессию (git bisect). Обычно те, кто уже умеют пользоваться им, используют его даже для всякой мелочи. Посмотрите вот nvie.com/posts/a-successful-git-branching-model

Answer 9

[Informatik]

Что такое система контроля версий

Answer 10

[Дмитрий]

Честно говоря, все ответы читать не стал, но в первых по списку точно не было самого главного - гит нужен в первую очередь КОМАНДАМ разработчиков! Если кодишь один и проект не сильно громоздкий, можно обойтись и локальной историей изменений (в PHPStorm она отлично работает), если тебя всё устраивает.
Хотя после того как я начал им пользоваться, обратно не безверсионную разработку никогда не перейду даже если буду кодить что-то в одиночку. слишком это удобно - построчное сравнение изменений, сохранение всей истории, удалённое хранение. прелесть же!