GIt или не Git - вот в чем вопрос

Проголосовал, что пользуемся в командной разработке. Только с уточнением, что исторически так сложилось, что используем Mercurial, хотя вот скоро перейдём на git (Bitbucket отказывается от поддержки меркуриала).

В основном работаю в консоли, там реально штук 5-6 основных команд, которые используются.

hg commit

hg push

hg pull

hg merge

hg strip

Программист использует графическую оболочку.

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

Гит это не бэкапы и не фтп, он не заменяет ни то ни другое. Как можно сравнивать теплое с мягким?

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

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

Просто это твоя не самая сильная сторона.

Я не раз это слышал :) Однако настолько уж они разные?:

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

Я напомню кто забыл/не знает. Я гит ... "изучал" громко сказано, скорее разбирался - что сие и надо ли оно мне довольно давно - несколько лет назад (да как бэ не с десяток наверное. Ну больше пяти точно). Так что смело можно говорить что я про него мало что знаю, кроме общих представлений (возможно где-то устаревших) и тех крох что говорят юзеры (вот как Слай про ком.строку напр.)

Ида. Все эти сравнения идут как раз от советов Слая ВПюзерам: "бекапы и ФТП - отстой для ламеров и надо юзать гит".

Для удобства работы с локальной ИДЕ.

Поиск мест вызова функции.

Вот чего привязался к этому поиску мест вызова функции? Мне это было нужно только когда свои CMS разрабатывал, и нужно было массово изменить этот вызов. Но в этом случае все файлы у меня сохранены локально. А если это какой-нибудь вордпресс, то этот поиск ни на дух не нужен. Но если бы надо было, то несложно это сделать консольными командами.

Вы просто не сталкивались с тем, что такое нужно.

Вот видите, файлы хранились локально.

Все не помню. Несколько лет я пользовался пайчармом для работы с гитом. потом попал на проект, где все лежит по 5 репозиториям и собирается в общую систему и там уже начались проблемы - как ненароком не закоммитать не то что надо. Ушел в консоль. Зато теперь заребэйзится или там черепикнуться - нет проблем. До кучи еще и ВИМ освоил немного

Я тож начинал с черепахи, правда для ртути. Хорошая штука, но привыкнув работать в консоли - особо не нужна. Да и опять же- на сервере чтоб запустить деплой все равно нужно в консоль зайти. Руки не доходят до какого Дженкинса, равно как и времени почти нет на свои проекты - на работе дел хватает.

Использую гит поскольку модно, стильно, молодежно. Плюс говорят сам Линус пользует.

На деле пофиг, гитхаб дает бесплатно - вот и использую. Имхо тот же mercurial информативнее. Но так как заказчикам гит кажется круче - то за деньги любой каприз :)

Я храню локально все файлы, с которыми работаю. Но разработка всегда на сервере.

А гит то тут при чём?

Давайте небольшую предысторию, вдруг кому будет интересно почитать:

Есть у вас сайт, ну вот прям пофигу на чём, возьмем тот же ВП, роли никакой не играет. Он работает, на него заходят клиенты, поисковики, сайт популярен, тыщи комментов ежедневно пишутся, реклама крутится, бабки льются рекой. И вы единственный разработчик на ВП.

Вам нужно сделать функционал, для этого надо установить плагин X и плагин Y и завязать функционал плагина X с плагином Y. Какие действия?

1. Мы ставим плагины на бою, в плагине Х оказался "DROP DATABASE DB_NAME". Сайт лежит, благо есть бэкапы, поднимаемся, теряя лояльность клиентов, деньги за рекламу и контент в виде комментариев, заказов, форм.

2. Окей, вариант 1 берут ламеры, не ламеры качают сайт локально/на другой сервер/разворачивают рядом. Ставят плагины, но умные, БД ломается, но сайт продакшена работает, меняем файлы плагина (нам же он нужен) чтоб он не дропал БД. Отлично. Теперь меняем 100 файлов для завязки функционала как из ТЗ сверху, меняли их 3 недели, какие наши действия? Нам же надо накатить на прод все это. Берем и копируем 88 файлов (по фтп пару минут - сайт лежит не все файлы на месте), за 3 недели забываем что именно правили, забываем про дроп - на выходе вариант 1, ладно не забываем про дроп, помним, но что то идет не так и на проде сайт ложится с магической ошибкой в файле который мы даже не трогали, как откатить 100 файлов обратно?. Ладно не переносим, переключаем целиком на новую папку и теряем 3 недели комментариев, заказов, форм.

3. А есть вариант с гитом. Представим что у вас есть снапшоты состояния файловой системы под номерами, на продакшене 1, мы берем, разворачиваем как в варианте 2, делаем изменения дропа и 100 файлов, коммитим и получаем ревизию 2. На продакшене нам надо только парой команд сменить ревизию с 1 на 2 (все изменения в файлы попадают одномоментно и сразу). Что то пошло не так, магическая ошибка, и нам надо переключить ревизию парой команд со 2 на 1. Где тут про бэкапы?

Вот от этого все и пляшет, гит контролирует файлы в разных папках чтоб они были идентичные согласно ID состоянию системы, на то она и система контроля версий. Тут остается только вопрос, когда люди правят все на продакшене, почему они это делают - загадка. Когда я правил на продакшене (да был мал и глуп, ну и не хватало скилов), для меня просто вызывал дискомфорт разворачивания локально и поддержки актуального состояния, но и этот я вопрос так же закрыл изучив пару инструментов которые эти проблемы решают, но это уже другая история.