19

Как побороть дискомфорт при использовании систем контроля версий?

Сколько раз не пытался понять, не получается. Как люди работают с системой контроля версий и считают такой подход к разработке удобным?

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

  1. Заходим на онлайн-ресурс
  2. Создаём проект
  3. Указываем данные своего удалённого сервера для хранения кода
  4. Начинаем работу...

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

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

Floyat
  • 87
  • 2
    такое уже есть - gitlab. Даже проще:) это как github. Там файлы можно редактировать онлайн. Каждое сохранение будет делать коммит. А можно взять что то вида https://c9.io/ – KoVadim Jun 30 '16 at 08:36
  • и прямо без терминала всё автоматически будет сохраняться на моём сервере и после сохранения все мои правки будут сразу на странице? – Floyat Jun 30 '16 at 08:40
  • 2
    Если настроить автодеплой, то да. – KoVadim Jun 30 '16 at 08:42
  • Я тоже не понимаю -- "как люди работают с системой контроля версий и считают такой подход к разработке удобным" (правда, по другим соображениям). Поэтому для себя в основном пользую tar (время от времени играясь с git (сейчас) и пытаясь понять, как с ним на самом деле правильно работать (или убедить себя, что мне это в самом деле удобно)). – avp Jun 30 '16 at 12:39
  • В GitLab есть интеграция с Koding, это онлайн-IDE. Позволяет вести всю разработку онлайн, ничего не устанавливая и не настраивая. – Nick Volynkin Oct 31 '16 at 15:34

6 Answers6

14

Ответ на основной вопрос:

Как побороть дискомфорт при использовании систем контроля версий?

Практика работы в команде прежде всего поможет. Часто возникают внештатные ситуации, которые сложно обработать без git:

  • необходимость отката
    При использовании git делается в одну команду = 10 сек, ручное рукоблудство не даёт гарантию корректного отката и делается дольше, при долгоиграющих проектах версий необозримо много. Откатить одинаково просто как файл, так и версию в целом.

  • разработка командой одного проекта Тут вообще — я просто не представляю иного способа разработки одного большого проекта всем вместе. Очень удобно пришёл на работу — выполнил одну команду = 3 сек, и у тебя уже есть всё что сделали твои коллеги. Уходишь с работы — потратил 3 сек — все твои изменения в репе.

  • просмотр истории эволюции кода из IDE
    А это вообще мегафича. Код в мозгу прямо живым становится, трёхмерным) Очень красиво всё отображается в NetBeans, например — сразу всё понятно, что к чему. И ещё это всегда помогает найти виновника костыля.

  • защита от потери сорцов
    Как то когда я был на первом курсе и ещё не знал про системы контроля версий: писал месяц проект — фреймворк для 3д графики. И тут бах — подцепил вирус из ВК, который мне его удалил к чертям собачьим. Как было обидно — не передать.

  • простой деплой между серверами
    Деплой проекта на боевой сервер (если мы о серверной разработке и интерпретируемом серверном языке) — делается в одну команду (git pull или git clone — кому как больше нравится). Никакого гемора, плясок с бубнами и путаницы с правами на файл.

  • ветвление версий
    Даёт функционал, чтобы твои разработки в проекте и разработки группы прогеров не влияли на основной ход разработки и сливались только при стадии завершения задания в основную версию. При том, что изменения можно по прежнему спокойно отправлять в репу (работают все другие плюсы).

  • руководство разработкой
    Руководство программистами может превратиться в ад без системы контроля версий с коммитами. Потому что нету быстрого способа посмотреть, что коллега сделал, нету качественного представления его трудов, невозможно на глаз оценить правильность трудов. А когда есть система - по истории коммитов можно очень быстро понять, что сделано хорошо, что сделано не очень, что надо быстренько подправить, где провести разъяснительную беседу. Красивое отображение в IDE истории коммитов, с подсвеченными изменениями/удалениями/вставками - это дополнительный сильный бонус, оценивать работу становится очень комфортно.

Так вот, необходимость обрабатывать эти внештатные ситуации в 100 раз перевешивает любой дискомфорт. И потом, к гиту быстро привыкаешь и уже считаешь его эталоном логичности. Если используем git из консоли, — не забываем про консольный интерфейс — кнопка Tab печатает команду за тебя по первым символам, стрелочки вверх и вниз вводят в поле ввода предыдущие набранные команды — очень удобно.

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

А вот это уже не система контроля версий, а UI её оборачивающий.

Вопрос актуальный, поскольку при столкновении с cvs/git тоже испытывал определённый дискомфорт. Рушатся шаблоны. Но только потом осознал, насколько git крутая штука.

Гончаров Александр
  • 5,239
  • 2
    "простой деплой между серверами" - настройте нам такой, чтоб в одну команду? :-) – Pavel Mayorov Jun 30 '16 at 10:40
  • 1
    Пожалуйста, не путайте интерпретируемые языки с общим случаем. Было бы все так просто - никакой CI бы не появилось. – Pavel Mayorov Jun 30 '16 at 10:41

  • настройте нам такой, чтоб в одну команду

     – Гончаров Александр Jun 30 '16 at 11:16
  • 1
    Там настраивать нечего - ставим гит на сервер. Стратегия git pull: делаем единожды клон проекта, создаём конфиги и единожды конфигурируем (конфиги разумеется в .gitignore лежат). После этого деплой идёт единой командой git pull. Стратегия git clone: Создаём баш скрипт/пхп скрипт, ложим его в папку ~/deploys , в нём команда клона. Конфиги в самом проекте, но их несколько - деплой скрипт создаёт симлинк на конфиги и на папки статики. При обоих стратегиях подтягиваются изменения БД после пулл/клон хуки. clone больше подходит для деплоя на несколько серваков, так как работает железно. – Гончаров Александр Jun 30 '16 at 11:40
  • 1
    Повторяю: "Пожалуйста, не путайте интерпретируемые языки с общим случаем". – Pavel Mayorov Jun 30 '16 at 11:42
  • 1
    Вы и компилятор на сервер ставить будете? А если проект без IDE не собирается (такое бывает со странными технологиями) - то и IDE на сервер поставите? И билд проекта будете вешать на пулл-хук? – Pavel Mayorov Jun 30 '16 at 11:44
  • 1
    С деплоем компилируемого не знаком. Подозреваю Java. Но вот вопрос - кто мешает скомпиленый проект также хранить в гите, и при деплое заменять его целиком? То есть скомпилил, запушил -> сдеплоил -> новая версия. Но возможно у меня в этой тематике знаний нет. – Гончаров Александр Jun 30 '16 at 11:45
  • 1
    А кто будет его компилить? Особенно если он из нескольких частей состоит? – Pavel Mayorov Jun 30 '16 at 11:46
  • 1
    Да даже webpack и scss/less уже не вписываются в вашу схему нормально. – Pavel Mayorov Jun 30 '16 at 11:48
  • 1
    Лид программист у которого локально развёрнуты все нужные компоненты и IDE . Который спулил труды своих ребят, протестил что надо. Если пушит программист которому не дали такую возможность - он и не компилит: при возможном деплое изменений не происходит. – Гончаров Александр Jun 30 '16 at 11:50
  • scss/less

    • У нас есть PHP scss компилер - работает в демоне, если видит что scss модифицирован, компилит его. Таким образом даже никаких изменений в деплойнике. Аналогично и для js-минификации.

    – Гончаров Александр Jun 30 '16 at 11:52
  • 3
    То есть вы свели задачу деплоя к задаче доставки файлов и говорите что гит "делает простой деплой" :) Вообще-то, проблема деплоя как раз и состоит в том, чтобы лиду не надо было компилить все руками каждый раз как надо заливать изменения на сервер. – Pavel Mayorov Jun 30 '16 at 11:52
  • 1
    Ну в разных конторах лиды разным занимаются. В чём проблема компиляцию на фоне запустить, получить уведомление когда она прошла, и затем пушнуть? – Гончаров Александр Jun 30 '16 at 11:53
  • Давайте продолжим обсуждение в чате. – Pavel Mayorov Jun 30 '16 at 11:55
  • Если у вас деплой делается git pull или git clone - он делается далеко не лучшим образом. – Nick Volynkin Jul 06 '16 at 03:52
  • @Nick Volynkin, факты, аргументы? У 2х проектов, прибыль которых 3 мил/месяц (и ещё 50-ти с меньшей прибылью) - он делается лучшим образом через гит. Деплой должен быть простым, как топор - это помогает сделать git. – Гончаров Александр Jul 06 '16 at 09:26
  • 1
    @ГончаровАлександр всё же прибыль проекта не говорит о его сложности. – A K Jul 08 '16 at 20:37