Задать вопрос
Контакты
Местоположение
Россия, Калининградская обл., Калининград (Кенигсберг)

Достижения

Все достижения (1)

Наибольший вклад в теги

Все теги (34)

Лучшие ответы пользователя

Все ответы (58)
  • Чем опасен force push?

    Lobotomist
    @Lobotomist
    Software Developer
    BD_ l3ftoverZ! ответил в принципе верно - можно затереть чужие изменения, но это не единственная опасность.

    Проблема еще и в том, что старые версии коммитов кто-то получил. И если при форсед пуше в содержимое коммитов были внесены изменения (например, они были поменяны местами и в итоге "сумма изменений" осталась та же, но порядок изменился) при пулле возникнут конфликты при попытке отребэйзить (смерджить) старые версии коммитов на новые. И тут уже все зависит от опытности и внимательности разработчика, который с этим столкнулся. Если он достаточно опытен - он поймет в чем дело и правильно разрулит ситуацию. А если нет - он начнет решать конфликты, накосячит при их решении, при пуше не проверит что он пушит не только свои коммиты, которые собирался, но и старые версии коммитов отребэйзенные на новые версии и это будет... неприятно.

    История из жизни.

    Вот реальная ситуация, которая произошла у меня на работе. К сожалению, за давностью лет конкретные детали я помню смутно, но в целом все было примерно так. В какой-то момент появилась ошибка. Причем код, в котором она была был очень "говнокод", человек его написавший уже уволился и понять в каком месте этот говнокод написан неправильно, не понимая "логики" автора было очень сложно. С помощью git-bisect я нашел проблемный коммит и стал дальше раскручивать клубок. В итоге выяснилось, что было нарушено по крайней мере три важных правила работы с гитом (описанные во внутренней вики и обязательные к исполнению) и если бы хотя бы одно из них нарушено не было - все было бы ок.
    1. Я сделал пуш в мастер и оперативно осознав, что что-то там не так быстренько поправил и залил форсед пушем исправления. Это было важно сделать именно так. Я решил, что во-первых, маловероятно, что кто-то успел сделать пулл, а во-вторых, даже если он и сделал - когда у него возникнут конфликты он либо сам все поймет, либо обратится ко мне. Первое нарушение. Мне следовало уведомить всех разработчиков об этом и объяснить как нужно правильно действовать.
    2. Естественно, один разработчик успел сделать пулл и отребэйзил на старый мастер ветку этого уволившегося и стал доделывать таск. Когда спустя продолжительное время он стал ребэйзить эту ветку на мастер у него полезли конфликты. Он не понял из-за чего эти конфликты возникли. Но храбро все их решил. Етественно, не правльно, уже хотя-бы потому, что он вообще не должен был их решать. Нарушение второго правила - "решай конфликты только тогда, когда ты понимаешь почему они возникли". Обратись он ко мне - все было бы в порядке.
    3. Когда он стал пушить свои изменения он нарушил третье правило: "Всегда проверяй список коммитов, которые ты пушишь". Он не заметил, что кроме "своих" коммитов, он так же пушит чужие, старые версии коммитов мастера, которые он отребэйзил на новые. Он должен был это заметить и забить тревогу - что такое, откуда эти коммиты, я их не делал. Опять же, обратись он ко мне - я бы на месте бы разобрался в чем дело, и исправил ситуацию.

    Так что не надейтесь на авось (как я в данном случае).


    В целом, получается так - если ты понимаешь, что обе проблемы - 1) перезатирание чужих изменений и 2) наличие у кого-то старых версий коммитов не актуальны - смело делай форсед пуш. Например:
    • Это ветка по задаче, в которой работаешь только ты и согласно workflow никто не должен без твоего ведома брать из нее какие-то коммиты.
    • Ты точно знаешь кто имеет доступ к ветке и уверен, что эти люди с ситуацией справятся корректно. Ты их предупредил и они знают что в таких ситуациях делать.
    Ответ написан
    Комментировать
  • Как ускорить rsync?

    Lobotomist
    @Lobotomist
    Software Developer
    В процессе выяснения деталей в комментариях к вопросу было найдено решение.

    В данном случае синхронизация выполнялась без использования опции `--times`, которая сохраняет время модификации файла при синхронизации. При этом не была использована опция `--size-only`, благодаря которой файлы с одинаковыми размерами считаются одинаковыми вне зависимости от времени изменения.
    И получается, что даты изменения у всех уже синхронизированных файлов отличаются, и rsync при повторном запуске считает эти файлы потенциально разными и считает их контрольные суммы, чтобы сравнить их по содержимому. На это и уходило время.

    Добавление опции `--size-only` существенно сократило время анализа файлов перед началом передачи.
    Хотя, на мой взгляд лучше вместо этого по умолчанию всегда использовать `--times` (в том числе в составе `-a`), если возможно.

    Кроме того, была использована опция `-v`, которая выводит информацию о синхронизируемых файлах, что тоже могло замедлять процесс, хотя, скорее всего ,не значительно.
    Ответ написан
    Комментировать
  • Как держать одновременно две ветки в рабочей копии?

    Lobotomist
    @Lobotomist
    Software Developer
    Я вижу два варианта:

    1. Использовать два репозитория.

    Вы просто клонируете репозиторий еще в одно место и работаете с ним отдельно.
    - Весь репозиторий дублируется, но если он не очень большой по размеру - в этом нет ничего страшного
    - Переносить изменения между репозиториями надо будет через pull/push, просто commit-ов будет недостаточно. Например, в репозитории (а) делается коммит в ветку (1), в репозитории (б) делается fetch из репозитория (а) ветки (1) и дальше ее коммиты могут уже черри-пикаться или как-то еще переносится в ветку (2).

    2. Использовать дополнительную рабочую директорию (git 2.5+)

    В новой версии git 2.5 появилась команда для создания дополнительной рабочей директории: git worktree. Если есть возможность обновить git, это наиболее удобный вариант. Нужно иметь ввиду, что фича пока эксперементальная.
    Ответ написан
    Комментировать
  • Как обновлять код в двух репозиториях?

    Lobotomist
    @Lobotomist
    Software Developer
    В таком случае стоит вынести бэкенд в отдельный репозиторий и подключать его как зависимость. Нормальных вариантов решать это через git мне не известно и я очень сомневаюсь что они есть по той простой причине, что git для решения таких задач не предназначен. По сути у вас получается три продукта, связанных между собой разными связями. Две версии фронтэнда (два продукта) связаны между собой общей "основой" (кодом), то есть это аналогично "наследованию" в ООП от общего базового класса. А от бэкенда они "зависят". Причем, могут зависеть от разных его версий (скорее всего будут, рано или поздно). То есть это больше похоже на "композицию" в терминах ООП. Так вот git - он не призван решать проблему зависимостей одного проекта от другого. Для этого нужно использовать менеджер зависимостей. Не знаю, на чем у вас написан проект, но для php это будет composer, для nodejs - npm, для python - pip(pyenv, poetry) и т.п.

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

    Например. Имеем по репозиторию (или ветке/несколько веток) для каждого проекта. При изменении кода бэкенда в одном из проектов сливаем его с кодом другого проекта, игнорируя при этом все изменения не бэкенда. Практическая реализация этого зависит от структуры кода и вообще вашего workflow. Но история проекта будет не красивой - все эти слияния, в которых еще и игнорируются изменения фронтэнд части... Это будет работать, но... это ужасно.
    Ответ написан
    1 комментарий
  • Почему многие отвечают в комментариях под вопросом, вместо написания отдельного ответа?

    Lobotomist
    @Lobotomist
    Software Developer
    Добавлю еще одну возможную причину. На время написания комментария человек не знает - является ли это решением или нет. А если оказывается, что комментарий решает проблему - автор вопроса доволен, проблема решена. А то, что нужно отметить вопрос как решенный - об этом он (и тот, кто ему отвечал) забывает (вообще не думает). Я часто встречаю такие вопросы, заранее не понятно - решит твой вопрос проблему человека или нет. Например, не работает у кого-то соединение по ssh. И причин может быть много разных. Тебе в голову пришла пара возможных вариантов - ты пишешь их в комментариях, задаешь уточняющие вопросы. А потом оказывается, что какое-то из твоих продположений подошло.

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

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

Лучшие вопросы пользователя

Все вопросы (1)