Так ты автор топика
Не правильно понял.
Опять не правильно понял. git rebase делает прямую историю коммитов, как будто не было никакой ветки.
Вот такое превратится во флет историю как будто коммит шел за коммитом в одной ветке.
Вот более понятный пример:
И да, при мердже и при ребейсе оно всегда пишет вверх ветки, в которую делается merge или rebase, меняется только граф в истории.
Потому что rebase переписывает историю, если сделать rebase уже запушенного коммита, есть вероятность натоврить хаос в истории коммитов. Не все проекты ведут красивый лог. Иногда важно не прозрачный читабельный лог, а сам факт возможности откатится. Кто знает и умеет в rebase, тот может использовать все его мощь. В остальном за merge никого не бьют, как минимум он ничего не ломает.
Опа, архитектор в здании.
Хорошо что у тебя ничего не перезатрется, потому что когда мышкой в админке тянешь, то программисты позаботились, чтобы ничего не перезатиралось.
Отвечаю тебе, оно уже залито. Пункт 1 на сервере. Пункт 3 - тоже на сервере.
Отвечаю тебе чётка, тупа не зачем заливать то, что уже залито. Особенно если там баг, внатуре. Тебе чётка нужна отлить пункт 1 обратно. Это как провернуть фарш обратно. Вы все с одного инкубатора что-ли?---------- Добавлено 03.06.2020 в 17:43 ----------livetv, вы наверное первый раз с ним общаетесь, такой терпиливый человек. Ну ничего, скоро он пульнет в вас дерьмом, главное не пытайтесь ничего объяснить, зря потратите время. Мы вон всем форумом бьемся над тем, чтобы привить человеку хотя бы способность вести дискуссию и быть открытым для новых знаний.
Ты бы хоть опрос сначала без ошибок создал, а потом уже учил других русскому языку.
Я тебе уже 100 раз говорил, что ты неадекватно общаешься с людьми, оскорбляешь их. Ведешь себя не уважительно и не воспитано. То, что ты сейчас лицезреешь по отношению к себе - это результат твоего гонора и неуважительного отношения к участникам форума. Но мне, в принципе, на это насрать. Я в этой теме начал с тобой общаться не для того, чтобы помирится с тобой, или найти общий язык, оно мне вообще не надо. Я написал нормальным языком, потому что хотел убедиться в том, что ты не осилишь решение той проблемы через бекапы. Но я тебя переоценил, ты даже не смог понять суть проблемы.
Aisamiery, он пуленепробиваемый. Ему не возможно что-то объяснить. Я никогда не встречал таких людей, вот отвечаю, за всю свою жизнь.
Ты не решишь эту проблему копированием. Ты даже не понял проблемы, что ты собрался решать? С этой проблемой сталкиваются десятки тысяч опытных разработчиков, каждый день, включая создателей твоего любимого Вротпресса. И для этого придумали систему контроля версий, чтобы решать эту проблему легко, быстро и эффективно. Ты не сталкиваешься, потому что код не пишешь, а только жмешь кнопки в ГУЕ и делаешь драг-н-дропы. Либо пишешь какую-то лапшу, которую не грех и закомментить, если что-то поломалось.
Я даже скажу больше, ты даже не понимаешь, что одна команда git (или кнопка в редакторе кода, для любителей GUI), делает именно то, что ты делаешь своими ручками, только оно заменяет сразу несколько действий, например:
Это все по сути то же самое, что и твой страшный велосипед, обмазаный бекапами, только работает в 100 раз быстрее и в 1000 раз надежней. Просто тебе не хватает ума сесть, разобраться и использовать, и ты по старинке делаешь на тяп-ляп, как научился несколько лет назад.
А как ты поймешь решение, если ты не видишь проблемы? Ты просто начнешь орать что тут много команд в консоль, какой ужас и кошмар, зачем, если можно сделать все одним кликом.
Я вообще догадываюсь почему тебе даже не понятна сама суть гита, если ты работаешь в основном из админки, драг-н-дропаешь мышкой блоки, то все это хранится в базе, гит не версионирует базу. Таким образом, ты во-первых: не испытываешь проблем в разработке, т.к. ты не пишешь код, а во-вторых: не видя проблем, ты не понимаешь какие проблемы решает версионирование кода.
Эйнштейн говорил: Проблемы не могут быть решены на том же уровне мышления, который создал их.
В твоем случае, проблемы нет, потому что ты находишься ниже уровня мышления и действий.
Несколько коммитов, разделенные по семантике.
В зависимости от ситуации. Если локализация косяка быстрая - то да, проще git flow hotfix start issue-249, сделал, закоммитил, потом git flow hotfix finish issue-249. Иногда локализовать проблему невозможно. Почитайте что такой гайзенбаг, или например гонки данных. Тогда станет понятно, как сложно найти проблему. Простой пример: у тебя есть структура данных, под неё выделяется память на хипе. Есть условно 100к+ запросов в секунду, если выделять память на хипе каждый раз, это черевато просадкой в производительности. Тогда ты создаешь пул объектов, которые уже выделены, ты берешь указатель из пула - там чистый объект с дефолтными типами данными. После использования, ты кладешь объект в пул, там он ресетится до дефолтных значений (числа в 0, строки в пустые). Иногда, из-за ошибки, объект может быть выдан из пула два раза, что в результате приведет к параллельному несинхронизированному доступ из нескольких участков кода. В итоге в структуре будут хранится не связанные между собой данные, например название одного товара, а цена артикул - другого. Такой баг можно дебажить бесконечно. Его и обнаружить сложно, т.к. он проявляется при определенных условиях (например, большой нагрузке). Я в таких случаях всегда делаю откат до последнего стабильного билда, а на одну ноду заливаю дебаг-билд с вкомпилинным рейс-детектором и отключенными оптимизациями. Собираю логи, через время вижу причину, и отдельным коммитом выпускаю фикс. И это хорошо когда туллинг позволяет это сделать. Вы наверное с таким никогда не сталкивался, а я сталкивался. У нас много ансейф-кода который написал так, чтобы выжать все бабло из железки.
Касательно проблем структуры ответа, "сужать" или редактировать структуру ответа в рамках мажорной версии - признак плохого кода. А расширять - не критично.---------- Добавлено 03.06.2020 в 14:02 ----------
я бы рассказал, но ты не видишь тут проблемы как таковой. попробуй ещё раз перечитать,
оно у тебя уже залито, и там есть баг. и пункт 3 тоже залит на сервер. тебе нужно октатить пункт 1, не затронув пункт 3. и пункт 5 заливать НЕ нужно, он ещё не готов.
Странный вопрос. А как работать с гитом без слияния?
Мы не ревьюим. У нас есть пре-коммит хуки, которые приводят код-стайл в порядок. Есть линтеры, которые проверяют безопасность кода, есть CI/CD и автотесты, которые гоняют тесты до посинения, и в конце-концов, компетентные разработчики, которых не нужно ревьюить.
По ситуации.
SeVlad, проблема: как откатить изменения с ошибкой из пункта 1, оставив функционал, добавленный в пункте 3, и при этом не потерять и не залить правки из пункта 5, т.к. они ещё не завершены.
Я хочу чтобы ты рассказал, по пунктам, что сделать в такой ситуации, используя твою систему бекапов, чтобы решить проблему.
Это уже 4 попытка узнать у тебя.
