Задать вопрос
  • Объясните значения цитаты из документации Typescript?

    1. Сделать явную проверку на undefined
    2. Избавиться от опционального параметра совсем
    3. Сделать параметр не опциональным
    Ответ написан
    Комментировать
  • Объясните значения цитаты из документации Typescript?

    firedragon
    @firedragon
    Не джун-мидл-сеньор, а трус-балбес-бывалый.
    type UserEvent = {type: string }
    function handler(event?:UserEvent) :void{
        // @ts-ignore  // гасим предупреждение
      let type = event.type; // тут возможно undefined
      console.log('type: ' + type)
    }
    function handler1(event?:UserEvent) :void{
      console.log('тут вы плюнули на все и надеетесь на лучшее')
      let type = event!.type; // тут вы плюнули на все и надеетесь на лучшее
    } 
    function handler2(event?:UserEvent) :void{
      if(event && event.type) // тут проверили что есть event и у него есть свойство type
      {
        let type = event.type;
        console.log(type)
      }
      console.log('бодрячком')
    }
    // console.log('test')
    handler({type: 'aaaa'}) // нормально
    handler2()
    handler2({type: 'bbbbb'})
    handler() // ошибка в рантайме, потому что мы задавили ошибку
    handler1() // снова ошибка
    Ответ написан
    5 комментариев
  • Почему код со временем перестает работать, хотя раньше работал отлично?

    Aetae
    @Aetae Куратор тега JavaScript
    Тлен
    Вариантов много.
    Самый вероятный(после банальной ошибки в твоём коде само собой): используется сторонняя библиотека получаемая извне без явной привязки к конкретной версии. Т.е.: обновилась библиотека, поменялся её интерфейс, код перестал работать.
    Самый невероятный: с обновлением браузера изменилась какая-то мелочь в его интерпретации твоего кода. Такое практически исключено, разработчики бразуеров очень сильно пекутся об обратной совместимости.
    Ответ написан
    7 комментариев
  • Появляется ошибка при вводе git push -u Error: failed to push some refs to...?

    sergey-kuznetsov
    @sergey-kuznetsov Куратор тега Git
    Автоматизатор
    Вас унесло совсем не в ту степь. Изначальная проблема думаю в том, что у вас нет прав на запись в свой репозиторий — Remote rejected. При первом пуше обычно просит авторизоваться. Это было сделано?

    Создавать на гитхабе пустую ветку с таким же именем точно не было смысла, удалите её, иначе она будет мешать отправить вашу реальную локальную ветку.

    Настоятельно рекомендую установить интерфейс командной строки гитхаба, это решает многие проблемы.
    Ответ написан
    5 комментариев
  • Пользуетесь ли вы кириллицей в Git?

    AgentSmith
    @AgentSmith
    Это мой правильный ответ на твой вопрос
    Практически везде принято писать на английском - это правило хорошего тона. Не раз встречал старые проекты с битой кодировкой из-за кириллицы
    61e92d6aa907b177579644.jpeg
    Ответ написан
  • Пользуетесь ли вы кириллицей в Git?

    CityCat4
    @CityCat4
    //COPY01 EXEC PGM=IEBGENER
    Разрабы пишут комменты на русском, но сам я никогда русский не использую - старая привычка, сохранившаяся со времен долгой работы на FreeBSD, где консоль долго была в koi8-r.
    Кроме того, микротики не переносят русских букв.
    Ответ написан
    Комментировать
  • Пользуетесь ли вы кириллицей в Git?

    delphinpro
    @delphinpro
    frontend developer
    Стараюсь писать на английском даже в своих проектиках. На локальной машине без разницы, а на хостах лениво настраивать терминал, чтобы он корректно отображал кирриллицу, а не кракозябры.
    Ответ написан
    Комментировать
  • Пользуетесь ли вы кириллицей в Git?

    yarkov
    @yarkov
    Помог ответ? Отметь решением.
    Как в команде договоритесь - так и будет. Для себя пишу на русском. На работе тоже. На прошлой работе писали на английском, хотя компания тоже российская.
    Ответ написан
    Комментировать
  • Как откатиться назад на стабильный commit и при этом сохранить полезный код, который ты сделал после допущенной ошибки?

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

    Все сценарии приблизительные, потому что каждая проблема требует комплексоного подхода и знания возможностей инструмента, поэтому не поленись, а почитай вот это внимательно и полностью
    https://git-scm.com/book/en/v2
    Ответ написан
    Комментировать
  • Как откатиться назад на стабильный commit и при этом сохранить полезный код, который ты сделал после допущенной ошибки?

    Erik_Mironov
    @Erik_Mironov
    Старые вопросы: *Dies from cringe*
    Временно переключиться на другой коммит:

    Вы можете временно переключиться на другой коммит:

    git checkout <your_commit_sha>

    Если вы хотите делать коммиты, пока вы временно на другой ветке:

    git checkout -b old-state <your_commit_sha>

    Чтобы вернуться туда, где вы были, просто снова checkout ветку, в которой вы были. (Если вы внесли изменения, при переключении веток, вам придется обращаться с ними соответствующим образом.

    Отменить раннее опубликованные коммиты новыми коммитами:

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

    # Это создаст три отдельных коммита возврата:
    git revert <your_commit_sha1> < your_commit_sha2> <your_commit_sha3>
    # Это вернет последние два коммита. Также принимает диапазоны:
    git revert HEAD~2..HEAD
    # Точно так же вы можете отменить ряд коммитов, используя хэши коммитов (не включая первый хеш):
    git revert <your_commite_sha>
    # Отмена мердж коммита:
    git revert -m 1 <merge_commit_sha>
    # Чтобы получить только один коммит, вы можете использовать 'rebase -i', 
    # Или вы можете сделать это вручную (обязательно сделайте это на верхнем уровне вашего репозитория)
    # Привести ваш индекс и дерево в нужное состояние, не меняя HEAD:
    git checkout <your_target_commit_sha>
    # После чего обязательно зафиксируйте коммит. Будьте уверены в том, что вы сделали на 150% и напишите хорошее сообщение с описанием того, что вы только что сделали:
    git commit


    Раздел git-scm.com, где описывается использование git-revert. Если вы решите, что все-таки не хотите возвращаться, вы можете отменить возврат (как описано здесь) или вернуться к состоянию до возврата. В этом случае вам также может быть полезен этот ответ:
    тык
    Ответ написан
    Комментировать
  • Как откатиться назад на стабильный commit и при этом сохранить полезный код, который ты сделал после допущенной ошибки?

    Способов отменить изменения в гите множество, их варианты в ответах озвучили.
    На мой вкус, для отмены изменений одного коммита, идеологически правильно выполнить git revert для этого коммита. Revert создаст новый комммит, отменяющий действия отменяемого коммита. Таким образом можно зафиксировать в истории репозитория факт отмены и, например, пометить причину совершенной отмены.
    Так же, если вдруг нужно отменить не весь коммит, а только часть его изменений, можно выполнить частичный revert:
    git revert <плохой_коммит> --no-commit # Revert будет подготовлен, но не закомичен
    git reset # Выполнить unstage всех файлов
    git add ... список плохих файлов  # Добавляем в индекс те файлы, что требуется отревертить. Используя ключ -p можно добавить часть изменений в файле, а не файл целиком.
    git checkout . # Сбрасываем все прочие файлы, что не в индексе, до оригинального состояния
    git commit # Коммитим revert
    Ответ написан
    Комментировать