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

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

Но большинство работодателей сколько б убытков не несли - они все равно выберут прогера подешевле, которые и будет постоянно создавать косяки и откатывать, вместо того чтоб нанять норм прогера + (вообще ужас и фантастика) тестировщика.

То есть тебе доку по гиту скинуть?

ну вот я сегодня.

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

Закоммитал ветку фичи

переключился на мастер

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

Ты уже отвечал и протвечался.

А сейчас не ты "проблему" нарисовал - не к тебе и вопросы.

Паспорт еще спроси, гуи-эдитор ))) Тебе даже если все ответят ты скажешь - высеврете ;) Ну ок слово автору вопроса

---------- Добавлено 03.06.2020 в 14:52 ----------

Налицо явное непонимание вопроса - как раз в данном случае ничего в итоге не потеряется

Это ты рассказываешь историю SeVlad'a с его системой бэкапов, гит откатывает ровно то что ты сказал.

Например ты в script.js изменил строку 17, следующей задачей строку 29, следующей задачей строку 88, так вот гит может откатить изменения в строке 17 не трогая остальные изменения. А изменения в базе делаются при помощи миграций, они тоже умеют откатывать состояние бд... но кому я рассказываю то...

---------- Добавлено 03.06.2020 в 15:57 ----------

не ошибается только тот, кто ничего не делает

---------- Добавлено 03.06.2020 в 16:00 ----------

Вы же нормальный прогер? Давайте уточним сколько тестов на свой код вы пишите? И какой процент покрытие кода тестами?

Несколько коммитов, разделенные по семантике.

В зависимости от ситуации. Если локализация косяка быстрая - то да, проще git flow hotfix start issue-249, сделал, закоммитил, потом git flow hotfix finish issue-249. Иногда локализовать проблему невозможно. Почитайте что такой гайзенбаг, или например гонки данных. Тогда станет понятно, как сложно найти проблему. Простой пример: у тебя есть структура данных, под неё выделяется память на хипе. Есть условно 100к+ запросов в секунду, если выделять память на хипе каждый раз, это черевато просадкой в производительности. Тогда ты создаешь пул объектов, которые уже выделены, ты берешь указатель из пула - там чистый объект с дефолтными типами данными. После использования, ты кладешь объект в пул, там он ресетится до дефолтных значений (числа в 0, строки в пустые). Иногда, из-за ошибки, объект может быть выдан из пула два раза, что в результате приведет к параллельному несинхронизированному доступ из нескольких участков кода. В итоге в структуре будут хранится не связанные между собой данные, например название одного товара, а цена артикул - другого. Такой баг можно дебажить бесконечно. Его и обнаружить сложно, т.к. он проявляется при определенных условиях (например, большой нагрузке). Я в таких случаях всегда делаю откат до последнего стабильного билда, а на одну ноду заливаю дебаг-билд с вкомпилинным рейс-детектором и отключенными оптимизациями. Собираю логи, через время вижу причину, и отдельным коммитом выпускаю фикс. И это хорошо когда туллинг позволяет это сделать. Вы наверное с таким никогда не сталкивался, а я сталкивался. У нас много ансейф-кода который написал так, чтобы выжать все бабло из железки.

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

---------- Добавлено 03.06.2020 в 14:02 ----------

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

оно у тебя уже залито, и там есть баг. и пункт 3 тоже залит на сервер. тебе нужно октатить пункт 1, не затронув пункт 3. и пункт 5 заливать НЕ нужно, он ещё не готов.

И почему тебе что-то мешает рассказать свои шаги тот факт что у меня нет проблем с этим?

Давай уже не томи, рассказывай. Только по-русски.

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

А как ты поймешь решение, если ты не видишь проблемы? Ты просто начнешь орать что тут много команд в консоль, какой ужас и кошмар, зачем, если можно сделать все одним кликом.

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

Эйнштейн говорил: Проблемы не могут быть решены на том же уровне мышления, который создал их.

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

Т.е. таки без гита проще и проблемы как таковой нет?

Всё решается банальным копированием и при необходимости дифф-ом.

Ну и к чему тогда эти дешёвые понты?

Я в который раз прошу - не натягивать на меня свои фантазии.

А любителям консолей стоит узнать что драг-анд-дроп это системная фича. Она может использоваться и для закачки файлов через фейс и для копирования файлов в файлменеджере и даже для перемещения строк в редакторе кода.