Отладка кода с Git 3 инструмента для поиска ошибок


Оглавление (нажмите, чтобы открыть):

Отладка Python приложений с помощью pdb

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

Отладка Python-кода с помощью print

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

Но самая большая проблема в использовании print() – это необходимость вносить изменения в код и перезапускать приложение, чтобы увидеть изменения. Давайте разберёмся, почему отладчики эффективнее.

Команды отладчика Python

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

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

Python есть встроенный отладчик под названием pdb . Это простая консольная утилита, которая обладает основной функциональностью для отладки кода. Но если вы ищете что-то более продвинутое, то стоит обратить внимание на ipdb – отладчик с функциональностью из IPython.

Проще всего вызвать pdb из кода, где вы работаете:

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

list (l)

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

up (p) и down (d)

Эти команды используются для передвижения по стеку вызовов. С их помощью можно отследить, откуда была вызвана текущая функция.

step (s) и next (n)

Другая пара не менее важных команд. С их помощью можно выполнять код построчно. Единственное различие между ними в том, что next(n) перейдёт к следующей строке вне зависимости от вызываемых функций, а step(s) перейдёт в вызванную функцию, если это возможно.

break (b)

Эта команда позволяет создавать брейкпоинты без внесений изменений в код. Ниже разберём этот этап более детально.

Краткий список команд pdb :

  • args (a) — выводит аргументы функции;
  • continue (c) или (cont) — продолжит выполнение до первого брейкпоинта или до завершения программы;
  • help (h) — выводит список доступных команд или подсказки по определённой команде;
  • jump (j) — перепрыгивает к выполнению указанной строчки кода;
  • list (i) — выводит исходный код программы вокруг выбранной строки;
  • expression (p) — выводит значение выражения;
  • pp — выводит значение в «красивом» виде;
  • quit или exit (q) — отменяет выполнение программы;
  • return (r) — завершает выполнение текущей функции.

Продолжаем изучать отладчик Python

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

Но теперь есть возможность запускать приложение напрямую из отладчика без внесения изменения в код. Для этого воспользуемся следующей командой:

Давайте разберём на примере. Есть простое приложение, которое отслеживает рабочее время. Для её работы используется библиотека requests , отвечающая за выполнение HTTP-запросов. Попробуем прервать выполнение во время запроса. Как это сделать? Запустим приложение через отладчик и установим брейкпоинт внутри библиотеки requests .

Как можно заметить, не нужно указывать полный путь до библиотеки. Можно указать относительную ссылку от sys.path . Таким же образом можно отлаживать и ваше приложение.

Теперь куда проще отлаживать код. Не надо вносить изменения в приложение или во внешние библиотеки.

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

В данном примере прерывание произойдёт только в случае, если json будет иметь в себе ключ time_entry .

Отладка кода Django

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

Если вы хотите прокачать отладчик, то установите django-extensions и используйте команду runserver_plus для запуска сервера. Также можно указать пароль для доступа к отладке следующей командой:

Прим. перев. В WERKZEUG, начиная с версии 0.11, появилась возможность доступа по паролю к отладчику. Это сделано для повышения безопасности при попытках несанкционированного доступа.

Если вы используете django-extensions, то получите страницу со всеми вызовами, кодом и окном отладчика.

Процесс отладки осуществляется с помощью WSGI библиотеки Werkzeug.

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

Каких ошибок стоит избегать при работе с Git

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

Распространённые ошибки программистов

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

Коммиты бинарных файлов

Покажу на практике.

Компиляция проекта на Delphi

Берём пример из статьи про определение серийного номера флешки с нашего сайта. Создаём новый репозиторий, прикрепляем каталог, собираем приложение и видим, что для коммита нам предлагаются сразу множество файлов – и бинарники и ресурсы и каталог _history. Всё это служебные файлы, их список может отличаться от среды к среде (разработки). Но так как мы изменяем только исходный код – остальные файлы лучше вообще исключить из рассмотрения.

Игнорируем служебные каталоги

Для этого в дереве проекта выберем неугодные нам файлы (все служебные, бинарные, ресурсы, xml-ы, которые мы не редактируем напрямую во время разработки) и в контекстном меню выберем пункт Ignore.

Исключение из git

Мы значительно упростим проект, уменьшим “вес” репозитория и скорость его передачи в/из Интернет.

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

Минусы такого подхода в том, что сложнее происходит переключение между различными этапами разработки. Кроме того затрудняется модификация проекта в части “как бы проект выглядел без этого”. Кроме того, намного эффективнее коллективная работа над различными элементами.

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

Удаление неиспользуемого кода из параллельной ветки

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

Если работаете только с одним файлом – незачем удалять другие. Просто игнорируйте их в этой ветке!

Редкие коммиты

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

Кроме того, коммит нужно как-то объяснять, а как можно описать коммит кода за день? “работал весь день”, ну на крайний случай можно перечислить все затронутые функции или классы. Но опять же, как тогда отлаживать процесс разработки?

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

Pro Git

Страницы

четверг, 26 февраля 2015 г.

Инструменты для работы с Git – KDiff3

Теперь установим и настроим KDiff3. Качаем тут. Устанавливаем

Я отключил то, что мне не нужно

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

Ну и запустим для проверки

Все, работает. Жмем Cancel и настраиваем сперва KDiff3 на работу с Git. Для этого идем в настройки

Далее в Directory снимаем указанную галку. Это делается, чтобы KDiff не оставляла файлы с расширением .orig.

Теперь настраиваем confgi Git’a так:

В данном конфиге у нас уже уже определены две внешние утилиты сравнения и слияния KDiff3 и P4Merge. В редакторе Far manager это выглядит так:

Ну и теперь проверяем все это в Git. Для этого даем команду

$ git difftool c258082 ffd6b37 —tool=kdiff3 —cc test.txt

И видим запустившееся окно утилиты KDiff3 без того чтобы Git задавал лишние вопросы (это мы настроили в конфиге).

И так сравнение с помощью KDiff3 работает. И кстати “мусора” (файла с расширением .orig) после выхода из KDiff3 не наблюдается. Теперь проверяем слияние. Даем команды:

$ git merge newbranch
$ git mergetool —tool=kdiff3

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

Далее смотрим конфликт.

Разрешаем его, жмем сохранить и выходим из KDiff3

И благодаря нашим настройкам рабочий каталог остается без “мусора”, остается только сделать коммит, чтобы зафиксировать изменения.

Ну или дать команду

$ git merge —abort

Чтобы отменить слияние.

9 комментариев:

$ git difftool c258082 ffd6b37 —tool=kdiff3 —cc test.txt
fatal: ambiguous argument ‘c258082’: unknown revision or path not in the working tree.
Use ‘—‘ to separate paths from revisions, like this:
‘git [. ] — [. ]’

При прочтении статей и воспроизведении примеров рекомендуется включать мозг

Это связано с тем, что уважаемый аfftar им не пользовался во время написания данной статьи?

Это связано с тем что вы тупо повторяете примеры не вникая в их суть.
Ваша сударь тупость заключена в этом c258082 ffd6b37. Если бы вы понимали что это такое вы бы не задали изначальный вопрос.

И кроме того, если бы вы знали английский, где собственно объясняется что не так вы сделали, то вы опять же не задали этот вопрос. Поэтому еще раз рекомендую включить мозг, ну или при отсутствии оного воспользоваться, допустим Google переводчиком и перевести во эту фразу: atal: ambiguous argument ‘c258082’: unknown revision or path not in the working tree.

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

Почему нельзя было сразу, не опускаясь до откровенного хамства, дать ответ человеку, который в 1й день пользования Git пытается понять, какие инструменты для этого нужны и не знает, что это за код ‘c258082’ и какое отношение они имеют к хешу коммита? Зачем было выдавать в себе агрошкольника?

Или заменить в тексте примера $ git difftool xxxxxxx —tool=kdiff3 —cc test.txt
с пометкой «годе xxxxxxx — это хеш коммита» Чтобы было сразу понятно. Мне задерживаться на этом было некогда всё остальное сработало, за что Огромное Вам спасибо.

Вам я советую повзрослеть.

Спасибо за совет. Он очень хорош. Я им воспользуюсь. Что такое хэши было объяснено почти в самом в самом начале блога, когда а я говорил про коммиты. И хэши это настолько очевидная вещь, тем более в данном примере, что меня не мало удивил ваш изначальный комментарий, в котором в самом же и содержался ответ на ваш вопрос, просто он был на английском языке. Поэтому я и порекомендовал включить мозг при воспроизведении примеров. К тому же 12 мая я только вернулся из штатов и меня плющил шифтинг поясов и ваш вопрос просто вызвал раздражение. Тем более если вы человек с бородой.

Но за ваш совет спасибо большое. Я действительно был не прав в своей манере ответа. У меня такое иногда бывает еще. Я работаю над собой. Спасибо еще раз за ваше терпение.

И ко всему прочему В САМОЙ ПЕРВОЙ СТАТЬЕ я объяснил что такое хэш коммита. Поэтому у меня вызвал раздражение ваш вопрос. Карл, в самой первой статье! Карл 🙂

Информационный портал по безопасности

Небольшая шпаргалка для работы с Git, GitHub

Небольшая шпаргалка для работы с Git

Предупреждение по использованию:

Данная публикация является учебной для освоения основ системы контроля версий git, на примере использования GitHub. Это не руководство к действию. Вы должны понимать, то что вы делаете применяя команды и идеи изложенные в публикации. Не спешите применять сказанное к вашим рабочим проектам. Создайте черновой проект, локальный репозиторий. Потренируйтесь на нем. Создайте свой учебный проект на GitHub. Когда вы хорошо будете понимать, что и как работает, только тогда вы сможете применить ваши знания в рабочих проектах.

В данной публикации я рассматриваю в основном работу с сервисом GitHub.

Цель: Коротко рассказать что такое Git.

Описать некоторые, основные команды консоли Git. Хотя в интернет существует довольно много описаний работы с git, многое из документации может показаться запутанным и некоторые определения раскрыты не полностью. Что может ввести начинающих в заблуждение. Некоторые определения следует написать в более развернутом виде, для ясности понимания.

Также с практическими примерами намного легче освоить систему. Цель статьи сделать небольшой обзор о системе Git. Показать как использовать некоторые команды, для более быстрого освоения начинающими. Показать как настроить систему для конкретного использования. Следующая цель, предотвратить бездумное использование тех или иных команд Git.

Предметная область и основные термины

repository — некоторое хранилище файлов, ссылок на изменения в файлах

commit — отслеживание изменений

HEAD — (специальный указатель) символическая ссылка на последние изменения. Примечание: Не обязательно ссылается на commit. Может указывать на ветвь. Состояние — «Detached HEAD»

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

Обратите внимание на это различие: «head» (в нижнем регистре) относится к любому из названных заголовков в хранилище; «HEAD» (верхний регистр) относится исключительно к текущему активному заголовку(ссылке). Это различие часто используется в документации Git. HEAD может указывать на именованную вершину какой-либо ветки или на commit.

Объекты Git. Четыре типа объектов: Blob, Tree, Commit и References.

Ветвь определяется не в самом Git, а наследуется от операционной и файловой систем.

git сервисы — сервисы предоставляющие услуги для пользователей git.

working directory — рабочий каталог на вашем компьютере

staging area — область подготовленных файлов или рабочая область

branch — ветка, состоит из набора коммитов, обычно ссылается на последний коммит

merge — слияние, слияние веток в одну

pull — втянуть, взять проект с сервера, получить изменения из удаленного репозитория

push — вытолкнуть, отправить изменения на сервер

# — в данном случае символ комментария

<> — угловые скобки, там где вам нужно вписать нужное исключая эти скобки

$ — приглашение ввода в терминале

Небольшое вступление

Git — одна из систем контроля версий.

Предназначена, в основном, для работы распределенной команды разработчиков.

То есть разработчики могут находиться в разных концах света и работать над одним проектом.

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

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

История создания

Теоретическая часть(коротко)

Проект был создан Линусом Торвальдсом для управления разработкой ядра Linux

Git свободная система и распространяется она под лицензией GNU GPL 2.

Основная задача системы управление версий — это упрощение работы с потоками изменяющейся информации. Главной парадигмой системы управления версий является локализация данных каждого разработчика проекта. Каждый разработчик имеет на своей машине локальный репозиторий. В случае необходимости изменения отправляются из локального репозитория в удаленное хранилище в определенную ветку. И любой разработчик из распределенной команды может скачать новые изменения в проекте, чтобы продолжить совместную работу над проектом. Тут я сделаю некоторую ремарку. Важно соблюдать стандарты по оформлению кода и работе с системой в вашей организации. Стандарты облегчают взаимодействие между разработчиками, экономят время, облегчают понимание того что вы делаете. Некоторая этика и культура по оформлению кода, по оформлению и структурированию рабочего процесса помогает разработчикам лучше и быстрее понимать друг друга.

Какие существуют системы управления версиями:

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

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

Практическая часть

Для использования системы git вам нужно:

1. Установить программу git на вашей системе.

2. Настроить программу и проверить её работоспособность локально

3. Зарегистрировать ваш аккаунт на GitHub

4. Создать локальный репозиторий или копировать репозиторий существующего проекта

5. Написать файл README.MD.

6. В случае, если вы начинаете проект, создать удаленный репозиторий

7. Фиксировать изменения локально

8. Отправлять изменения на GitHub

9. Зарегистрировать аккаунты разработчиков вашего проекта

10. Выдать им ссылку на проект

1. Установка git

1. После установки вы можете кликнуть правой кнопкой мышки на папке в проводнике Windows и выбрать открыть «Git Bash Here». Git Bash Here — означает отрыть терминал git здесь.

В терминале введите команду

проверить версию вашего git.

В Linux,(Ctrl+Alt+T — терминал, если у вас не назначены другие горячие клавиши) откройте терминал и введите

В случае успешной установки на консоль выведется версия вашего git.

2.Настройка программы Git

Тут следует упомянуть, что настройку Git вы осуществляете на нескольких уровнях.

То есть некоторые настройки вы делаете для определенного пользователя операционной системы(не системы git, а операционной системы). Другие настройки вы делаете для всех пользователей операционной системы. Далее вы можете делать настройки для определенной папки(локально). Вы делает настройки для репозитория находящегося на сервере. Эти настройки вы можете не делать, если работаете только со своим локальным репозиторием.

Чтобы ввести настройки только одного репозитория, перейдите в его папку и сделайте то же без —global:

Настройка внешнего редактора.

#команда для Linux.

Вы можете выбрать другой текстовый редактор. Например не emacs, a vi или nano или другой на ваше усмотрение.

В Windows, такой командой вы можете задать текстовый редактор, например notepad++.

Для x64 Windows используйте:

git config —global core.editor «‘C:/Program Files (x86)/Notepad++/notepad++.exe’ -multiInst -notabbar -nosession -noPlugin»

Настройки git хранятся в файлах.

Git проверяет 4 места для файла конфигурации(здесь в Linux):

Файл вашего компьютера .gitconfig.

Ваш пользовательский, файл вашего пользователя .gitconfig файл находится в

Мастер Йода рекомендует:  Торговые площадки – максимальное ускорение для вашего интернет бизнеса

Второй пользовательский файл конфигурации, расположенный в $ XDG_CONFIG_HOME/git/config или $HOME/.config/git/config.

Конфигурационный файл локального репозитория: .git/config

Каждый файл добавляет или переопределяет параметры git, определенные в файле над ним.

Конфигурация, специфичная для репозитория.

Ссылка на документацию:

Вы можете просмотреть файлы конфигурации

#для системы и всех пользователей

Проверка настроек вашей конфигурации git:

Если список большой, вы можете пролистывать его с помощью стрелок клавиатуры или «pg up», «pg dn». Для выхода клавиша q.

#какая конфигурация, где установлена:

Для чего нужно рассмотреть консольные команды? Ведь существуют UI.

Часто в консоли вы можете сделать, что-то гораздо быстрее. С помощью набора консольных команд вы сами в будущем сможете автоматизировать процесс. Консольные команды более гибкий инструмент. Почему? Да потому что ваш UI может и «не знать» о существовании той или иной команды. На первом этапе консольные команды во многом помогут в общем понимании того как работает система. Все их запоминать нет необходимости. Вы в любой момент сможете найти справку по той или иной команде. Теоретические знания, без которых никуда, лучше усваиваются с применением на практике.

-C — использовать указанную папку репозитория вместо текущей папки;

-c параметр=значение — использовать указанное значение параметра конфигурации;

-p — прокручивать весь вывод с помощью less;

Инициализация локального репозитория.

1. Переходим в папку проекта.

3. #тут мы добавляем все. Папку. Точка после add отделенная пробелом.

Можно добавить отдельный файл

Таким образом мы говорим — отслеживать изменения нашего файла.

Для добавления всего в папке рекомендуют использовать команду

4. Создание commit

-m «комментарий» #аргумент создания комментария коммиту. Ваши изменения будут уже с осмысленным комментарием.

Вы можете использовать полное имя ключа, вместо его сокращения. К примеру, вместо -m вы можете использовать —message=«комментарий»

Показывает информацию — какая ветка текущая.

Какие файлы изменены и тд. Команда показывает, что находится в рабочей области(в staging area).

Ветка(branch) — ссылка на определенный коммит.

, используйте для имени латинские буквы. Тут есть одно замечание. Когда мы создали ветку с некоторым именем, текущей осталась ветка, которая была выделена до этого. Ну например master. И если после создания ветки мы скажем git commit, то будет продолжена ветка master. Не понимание этого часто приводит к ошибкам.

Совет: Чтобы продолжить новую ветку нужно её создать, потом переключиться на неё и сделать commit.

1. Создаем ветку:

2. Переключаемся на созданную ветку:

3. Делаем commit:

Теперь у нас есть вторая ветка с именем feature.

Объединение веток создает коммит от двух родителей, от текущей ветки и ветки указанной в команде git.

1. Переключаемся на ветку master

2. Сморим какая ветка текущая

3. Объединяем ветки #объединить текущую ветку с веткой feature

Мы можем сделать по другому. Переключиться на ветку feature и объединить её с веткой master

2. , в данном случае feature c веткой master.

Просмотр доступных веток:

stash — стек, временное хранилище

Не путайте со stage, это не одно и то же.

Команда сохраняет все не закомиченные изменения во временное хранилище и сбрасывает состояние ветки до HEAD.

Стеш(stash) предназначит для того, что бы спрятать не нужные на данный момент изменения, потому он и называется stash, в переводе — прятать, припрятывать.

На рисунке показана подготовка папки на локальном компьютере для git.

Добавление в staging area. Добавление изменений в локальный репозиторий(git commit).

Отправка в удаленный репозиторий(git push).

На данной схеме не показана сущьность stash.

Работа с командами:

Очень полезные команды. Рассмотрите их самостоятельно.

Работа с удаленным репозиторием

Далее я перейду к описанию работы с удаленным репозиторием.

Вы можете работать с удаленным репозиторием и вашим проектом через протокол https://,

то есть в вашем браузере(chrome, mozilla, opera и других).

Интерфейс GitHub на английском языке.

Для начала, вам нужно зарегистрироваться на GitHub, если вы этого еще не сделали или

подключить нужную ветку и отправить изменения локального репозитория.

Узнать как зарегистрироваться вы можете на самом сайте GitHub.

Показать какие пути назначены:

#показать какие ветки есть в удаленном репозитории

Обычно там одна ветка origin.

То есть это не сама ветка, а её сокращенное название ассоциированное с репозиторием.

Вы можете добавить, ассоциировать еще одну ветку на удаленном репозитории.

Диаграмма показывает отличие работы с локальным репозиторием и с репозиторием на GitHub

Из данной диаграммы вы можете видеть, как работать с локальным репозиторием и как работать с репозиторием на сервере. Показаны только несколько команд для краткости и ясности.

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

При желании, вы сможете потом отправить их на сервер.

Взаимодействие с другими системами контроля версий

В стандартной поставке Git поддерживается взаимодействие с CVS (импорт и экспорт, эмуляция CVS-сервера) и Subversion (частичная поддержка импорта и экспорта). Стандартный инструмент импорта и экспорта внутри экосистемы — архивы серий версионированных файлов в форматах .tar.gz и .tar.bz2.
Fork – удаленная копия репозитория на сервере, отличная от оригинала. Это даже не git-концепция, а, скорее, политико-социальная идея. Clone – это не то же самое, что и fork. Клон удаленного репозитория располагается локально. Фактически при клонировании копируются все данные, включая историю коммитов и существующие ветки.

Branch, или создание ветки, – это способ внести изменения в проект и объединить их в итоге с остальным кодом. Ветка является частью репозитория.
Рабочее дерево (рабочая директория, рабочее пространство) – это дерево исходных файлов, которые вы можете видеть и редактировать.

Индекс (область подготовленных файлов, staging area) – это один большой бинарный файл .git/index, в котором указаны все файлы текущей ветки, их SHA1, временные метки и имена. Это не отдельная директория с копиями файлов.

Указатель HEAD – это ссылка на последний коммит в текущей извлеченной ветке.

Модели ветвления в Git:

Для чего нужны модели ветвления?

Для лучшей организации потока работы(Workflow). Для стандартизации. То есть в вашей организации может быть принята, в зависимости от целей некоторая модель ветвления.

Developer Branch Workflow

Feature Branch Workflow

Issue Branch Workflow

Central Workflow (центральный рабочий процесс) в этом контексте определяется как «вы отправляете изменения тому же репо, из которого вы обычно получаете свои последние вышестоящие изменения», независимо от того, используете ли вы rebase или merge. (pull = fetch + merge или fetch + rebase, в зависимости от конфигурации и параметров)

Feature Branching являет логическим расширением Central Workflow (центрального рабочий процесса). Основная идея рабочего процесса Feature Branch: разработка всех функций должна осуществляться в выделенной ветви вместо основной ветви. Главная ветвь никогда не должна содержать неработающий код. Это является большим преимуществом в средах непрерывной интеграции.

Рабочий процесс Gitflow был впервые опубликован в блоге Винсента Дриссена от nvie за 2010 год. Рабочий процесс Gitflow определяет строгую модель ветвления, разработанную для выпуска проекта. Этот рабочий процесс не добавляет каких-либо новых концепций или команд помимо того, что требуется для рабочего процесса Feature Branch. Вместо этого он назначает очень конкретные роли различным ветвям и определяет, как и когда они должны взаимодействовать.

Рабочий процесс Forking отличается от других рабочих процессов. Вместо того чтобы использовать один серверный репозиторий в качестве «центральной» кодовой базы, он предоставляет каждому разработчику серверный репозиторий. Это означает, что у каждого участника есть не один, а два репозитория Git: частный локальный и общедоступный серверный.

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

Вы можете найти рекомендации по использованию рабочих процессов в документации к Git.

Мы с вами рассмотрели работу системы git и работу с удаленными репозиториями.

В некоторой степени коснулись вопроса установки и конфигурации git, регистрации удаленного репозитория на примере GitHub. Применения git как локально, так и удаленно. А также некоторые моменты организации рабочего процесса. В одной статье невозможно рассказать обо всем. Вы можете продолжить обучение изучая материалы документации и публикации других авторов.

How can I debug git/git-shell related problems?

How can I have some debug information regarding git/git-shell?

I had a problem, that user1 could clone a repository without problem, while user2 could clone only an empty one. I had set GIT_TRACE=1 , but nothing useful was told.

Finally, after a long trial and error, it turned out that it was a permission problem on a file. An appropriate error message could short-circuit this problem.

/log.normal . See my (new) answer below. – VonC May 13 at 19:22

8 Answers 8

For even more verbose output use following:

GIT_CURL_VERBOSE=1 GIT_TRACE=1 git pull origin master

Debugging

Git has a fairly complete set of traces embedded which you can use to debug your git problems.

To turn them on, you can define the following variables:

  • GIT_TRACE for general traces,
  • GIT_TRACE_PACK_ACCESS for tracing of packfile access,
  • GIT_TRACE_PACKET for packet-level tracing for network operations,
  • GIT_TRACE_PERFORMANCE for logging the performance data,
  • GIT_TRACE_SETUP for information about discovering the repository and environment it’s interacting with,
  • GIT_MERGE_VERBOSITY for debugging recursive merge strategy (values: 0-5),
  • GIT_CURL_VERBOSE for logging all curl messages (equivalent to curl -v ),
  • GIT_TRACE_SHALLOW for debugging fetching/cloning of shallow repositories.

Possible values can include:

  • true , 1 or 2 to write to stderr,
  • an absolute path starting with / to trace output to the specified file.

For SSH issues, try the following commands:

or use ssh to validate your credentials, e.g.

or over HTTPS port:

Note: Reduce number of -v to reduce the verbosity level.

Examples

If its over SSH, you can use the following:

For a higher debug level for type -vv or -vvv for debug level 2 and 3 respectively:

This is mainly useful to handle public and private key problems with the server. You can use this command for any git command, not only ‘git clone’.


Git 2.9.x/2.10 (Q3 2020) adds another debug option: GIT_TRACE_CURL .

http.c : implement the GIT_TRACE_CURL environment variable

Implement the GIT_TRACE_CURL environment variable to allow a greater degree of detail of GIT_CURL_VERBOSE , in particular the complete transport header and all the data payload exchanged.
It might be useful if a particular situation could require a more thorough debugging analysis.

Enables a curl full trace dump of all incoming and outgoing data, including descriptive information, of the git transport protocol.
This is similar to doing curl —trace-ascii on the command line.

This option overrides setting the GIT_CURL_VERBOSE environment variable.

You can see that new option used in this answer, but also in the Git 2.11 (Q4 2020) tests:

Use the new GIT_TRACE_CURL environment variable instead of the deprecated GIT_CURL_VERBOSE .

Have you tried adding the verbose ( -v ) operator when you clone?

git clone -v git://git.kernel.org/pub/scm/. /linux-2.6 my2.6

For older git versions (1.8 and before)

I could find no suitable way to enable SSH debugging in an older git and ssh versions. I looked for environment variables using ltrace -e getenv . and couldn’t find any combination of GIT_TRACE or SSH_DEBUG variables that would work.

Instead here’s a recipe to temporarily inject ‘ssh -v’ into the git->ssh sequence:

Here’s output from git version 1.8.3 with ssh version OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013 cloning a github repo:

Git 2.22 (Q2 2020) introduces trace2 with commit ee4512e by Jeff Hostetler:

trace2 : create new combined trace facility

Create a new unified tracing facility for git.
The eventual intent is to replace the current trace_printf* and trace_performance* routines with a unified set of git_trace2* routines.

In addition to the usual printf-style API, trace2 provides higer-level event verbs with fixed-fields allowing structured data to be written.
This makes post-processing and analysis easier for external tools.

Trace2 defines 3 output targets.
These are set using the environment variables » GIT_TR2 «, » GIT_TR2_PERF «, and » GIT_TR2_EVENT «.
These may be set to «1» or to an absolute pathname (just like the current GIT_TRACE ).

Note: regarding environment variable name, always use GIT_TRACExxx , not GIT_TRxxx .
So actually GIT_TRACE2 , GIT_TRACE2_PERF or GIT_TRACE2_EVENT .
See the Git 2.22 rename mentioned later below.

What follows is the initial work on this new tracing feature, with the old environment variable names:

GIT_TR2 is intended to be a replacement for GIT_TRACE and logs command summary data.

GIT_TR2_PERF is intended as a replacement for GIT_TRACE_PERFORMANCE .
It extends the output with columns for the command process, thread, repo, absolute and relative elapsed times. It reports events for child process start/stop, thread start/stop, and per-thread function nesting.

GIT_TR2_EVENT is a new structured format. It writes event data as a series of JSON records.

Calls to trace2 functions log to any of the 3 output targets enabled without the need to call different trace_printf* or trace_performance* routines.

trace2 : write to directory targets

When the value of a trace2 environment variable is an absolute path referring to an existing directory, write output to files (one per process) underneath the given directory.
Files will be named according to the final component of the trace2 SID, followed by a counter to avoid potential collisions.

This makes it more convenient to collect traces for every git invocation by unconditionally setting the relevant trace2 envvar to a constant directory name.

The new documentation now includes config settings which are only read from the system and global config files (meaning repository local and worktree config files and -c command line arguments are not respected.)

As documented in Git 2.23 (Q3 2020), the environment variable to use is GIT_TRACE2 .

That follows the work done in Git 2.22: commit 4e0d3aa, commit e4b75d6 (19 May 2020) by SZEDER Gábor ( szeder ).
(Merged by Junio C Hamano — gitster — in commit 463dca6, 30 May 2020)

trace2 : rename environment variables to GIT_TRACE2*

For an environment variable that is supposed to be set by users, the GIT_TR2* env vars are just too unclear, inconsistent, and ugly.

Most of the established GIT_* environment variables don’t use abbreviations, and in case of the few that do ( GIT_DIR , GIT_COMMON_DIR , GIT_DIFF_OPTS ) it’s quite obvious what the abbreviations ( DIR and OPTS ) stand for.
But what does TR stand for? Track, traditional, trailer, transaction, transfer, transformation, transition, translation, transplant, transport, traversal, tree, trigger, truncate, trust, or .

The trace2 facility, as the ‘2’ suffix in its name suggests, is supposed to eventually supercede Git’s original trace facility.
It’s reasonable to expect that the corresponding environment variables follow suit, and after the original GIT_TRACE variables they are called GIT_TRACE2 ; there is no such thing is ‘ GIT_TR ‘.

All trace2-specific config variables are, very sensibly, in the ‘ trace2 ‘ section, not in ‘ tr2 ‘.

OTOH, we don’t gain anything at all by omitting the last three characters of «trace» from the names of these environment variables.

So let’s rename all GIT_TR2* environment variables to GIT_TRACE2* , before they make their way into a stable release.

Git 2.24 (Q3 2020) improves the Git repository initialization.

common-main: delay trace2 initialization

We initialize the trace2 system in the common main() function so that all programs (even ones that aren’t builtins) will enable tracing.

But trace2 startup is relatively heavy-weight, as we have to actually read on-disk config to decide whether to trace.
This can cause unexpected interactions with other common-main initialization. For instance, we’ll end up in the config code before calling initialize_the_repository() , and the usual invariant that the_repository is never NULL will not hold.

Let’s push the trace2 initialization further down in common-main, to just before we execute cmd_main() .

Git 2.24 (Q4 2020) makes also sure that output from trace2 subsystem is formatted more prettily now.

And, still Git 2.24

trace2 : discard new traces if target directory has too many files

Signed-off-by: Josh Steadmon

trace2 can write files into a target directory.
With heavy usage, this directory can fill up with files, causing difficulty for trace-processing systems.

This patch adds a config option ( trace2.maxFiles ) to set a maximum number of files that trace2 will write to a target directory.

The following behavior is enabled when the maxFiles is set to a positive integer:

When trace2 would write a file to a target directory, first check whether or not the traces should be discarded. Traces should be discarded if:

  • there is a sentinel file declaring that there are too many files
  • OR, the number of files exceeds trace2.maxFiles .
    In the latter case, we create a sentinel file named git-trace2-discard to speed up future checks.

The assumption is that a separate trace-processing system is dealing with the generated traces; once it processes and removes the sentinel file, it should be safe to generate new trace files again.

The default value for trace2.maxFiles is zero, which disables the file count check.

The config can also be overridden with a new environment variable: GIT_TRACE2_MAX_FILES .

And Git 2.24 (Q4 2020) teach trace2 about git push stages.

push : add trace2 instrumentation

Signed-off-by: Josh Steadmon

Add trace2 regions in transport.c and builtin/push.c to better track time spent in various phases of pushing:

  • Listing refs
  • Checking submodules
  • Pushing submodules
  • Pushing refs

Принципы отладки для начинающих How to debug for absolute beginners

Независимо от обстоятельств код, создаваемый разработчиками программного обеспечения, далеко не всегда работает так, как задумано. Without fail, the code we write as software developers doesn’t always do what we expected it to do. В некоторых случаях все идет совершенно не по плану! Sometimes it does something completely different! В подобных ситуациях необходимо выяснить, почему так происходит. При этом вместо многочасового изучения кода в поисках ошибок гораздо проще и эффективнее будет использовать средство отладки (отладчик). When this happens, the next task is to figure out why, and although we might be tempted to just keep staring at our code for hours, it’s much easier and efficient to use a debugging tool, or debugger.

К сожалению, отладчик не является той волшебной палочкой, по мановению которой будут выявлены абсолютно все проблемы в коде. A debugger, unfortunately, isn’t something that can magically reveal all the problems or “bugs” in our code. Процесс отладки подразумевает пошаговое выполнение кода в средстве отладки (например, в Visual Studio) в поисках точки, в которой вы допустили ошибку при написании программы. Debugging means to run your code step by step in a debugging tool like Visual Studio, to find the exact point where you made a programming mistake. Таким образом, вы получите возможность проанализировать код и внести в него необходимые исправления. При этом средства отладки часто допускают внесение временных изменений, благодаря чему вы можете продолжать выполнение программы. You then understand what corrections you need to make in your code, and debugging tools often allow you to make temporary changes so you can continue running the program.

Эффективное использование отладчика также требует определенных навыков, которые вырабатываются только с практикой, однако умение работать с ним является основополагающим требованием к любому разработчику программного обеспечения. Using a debugger effectively is also a skill that takes time and practice to learn but is ultimately a fundamental task for every software developer. В этой статье мы познакомим вас с основными принципами отладки и поделимся рекомендациями о том, с чего можно начать. In this article, then, we introduce the core principles of debugging and provide tips to get you started.

Проанализируйте проблему, задавая себе правильные вопросы Clarify the problem by asking yourself the right questions

Это поможет вам выяснить, в чем состоит проблема, прежде чем приступать к ее решению. It helps to clarify the problem that you ran into before you try to fix it. Мы полагаем, что вы уже сталкивались с проблемами в коде, иначе вряд ли читали бы сейчас эту статью в поисках советов по его отладке! We expect that you already ran into a problem in your code, otherwise you wouldn’t be here trying to figure out how to debug it! Итак, прежде чем начать отладку, проанализируйте проблему, которую вы пытаетесь решить: So, before you start debugging, make sure you’ve identified the problem you’re trying to solve:

Что именно должен был выполнить код? What did you expect your code to do?

Что произошло вместо этого? What happened instead?

Если во время выполнения приложения вы столкнулись с ошибкой или исключением, это может быть хорошим признаком! If you ran into an error (exception) while running your app, that can be a good thing! Исключение возникает в том случае, если при выполнении кода происходит непредвиденное событие (как правило, это ошибка какого-либо рода). An exception is an unexpected event encountered when running code, typically an error of some kind. С помощью средства отладки вы можете перейти точно к тому месту в коде, где возникло исключение, и исследовать возможные способы исправления ситуации. A debugging tool can take you to the exact place in your code where the exception occurred and can help you investigate possible fixes.

Мастер Йода рекомендует:  Создание сайтов - модель качественной верстки

Если произошло что-то еще, каковы признаки проблемы? If something else happened, what is the symptom of the problem? Есть ли у вас предположения относительно того, в каком месте кода возникла проблема? Do you already suspect where this problem occurred in your code? Например, если код должен выводить какой-то текст, но при этом текст содержит ошибки, вы можете сделать вывод, что в этом случае используются неверные данные или код вывода текста содержит ошибки другого рода. For example, if your code displays some text, but the text is incorrect, you know that either your data is bad or the code that set the display text has some kind of bug. При пошаговом выполнении кода в отладчике вы можете изучить каждое изменение переменных и точно определить, когда и каким образом были присвоены неверные значения. By stepping through the code in a debugger, you can examine each and every change to your variables to discover exactly when and how incorrect values are assigned.

Проверьте свои предположения Examine your assumptions

Прежде чем исследовать причины возникновения ошибки, проверьте предположения, на основании которых вы ожидаете тот или иной результат. Before you investigate a bug or an error, think of the assumptions that made you expect a certain result. Скрытые или неизвестные предположения могут помешать выявлению проблемы, даже если вы изучаете непосредственно место ее возникновения в отладчике. Hidden or unknown assumptions can get in the way of identifying a problem even when you are looking right at the cause of the problem in a debugger. Перечень возможных предположений может быть достаточно большим. You may have a long list of possible assumptions! Чтобы проверить их, задайте себе несколько вопросов. Here are a few questions to ask yourself to challenge your assumptions.

Используете ли вы нужный API (то есть соответствующие объект, функцию, метод или свойство)? Are you using the right API (that is, the right object, function, method, or property)? Возможно, используемый вами API работает не так, как вы ожидаете. An API that you’re using might not do what you think it does. (После проверки вызова API в отладчике для исправления проблемы и выявления нужного API вам может потребоваться обратиться к документации.) (After you examine the API call in the debugger, fixing it may require a trip to the documentation to help identify the correct API.)

Правильно ли вы используете API? Are you using an API correctly? Даже если вы выбрали нужный API, он может использоваться неправильно. Maybe you used the right API but didn’t use it in the right way.

Нет ли в вашем коде опечаток? Does your code contain any typos? Некоторые опечатки, например ошибки в написании имени переменной, могут быть незаметными, особенно при работе с языками, в которых не требуется объявление переменных перед их использованием. Some typos, like a simple misspelling of a variable name, can be difficult to see, especially when working with languages that don’t require variables to be declared before they’re used.

Вносили ли вы изменения в код и могут ли они быть связаны с возникшей проблемой? Did you make a change to your code and assume it is unrelated to the problem that you’re seeing?

Должны ли объект или переменная содержать определенное значение (или определенный тип значения) и соответствует ли это действительности? Did you expect an object or variable to contain a certain value (or a certain type of value) that’s different from what really happened?

Известно ли назначение кода? Do you know the intent of the code? Как правило, отладка кода, написанного другим разработчиком, дается гораздо сложнее. It is often more difficult to debug someone else’s code. Если это не ваш код, возможно, для его эффективной отладки вам потребуется изучить, что он делает. If it’s not your code, it’s possible you might need to spend time learning exactly what the code does before you can debug it effectively.

При написании кода старайтесь начинать с небольших и гарантированно работающих фрагментов! When writing code, start small, and start with code that works! (В этом вам может помочь хороший пример кода.) В некоторых случаях для исправления большого сложного фрагмента кода можно начать с маленького сегмента, демонстрирующего основную задачу, которую требуется выполнить. (Good sample code is helpful here.) Sometimes, it is easier to fix a large or complicated set of code by starting with a small piece of code that demonstrates the core task you are trying to achieve. Затем вы можете последовательно изменять или добавлять код в поисках точки возникновения ошибки. Then, you can modify or add code incrementally, testing at each point for errors.

Анализируя собственные предположения, вы можете сократить время, необходимое на поиск проблем в коде. By questioning your assumptions, you may reduce the time it takes to find a problem in your code. Кроме того, вы можете ускорить решение самих проблем. You may also reduce the time it takes to fix a problem.

Используйте режим пошагового выполнения во время отладки для поиска места возникновения проблемы. Step through your code in debugging mode to find where the problem occurred

Очевидно, что ошибки и неверные результаты можно увидеть только после выполнения кода приложения. When you normally run an app, you see errors and incorrect results only after the code has run. Кроме того, работа программы может завершиться неожиданно без каких-либо сообщений. A program might also terminate unexpectedly without telling you why.

При выполнении приложения в отладчике (в так называемом режиме отладки) осуществляется активный мониторинг всего, что происходит во время работы программы. Running an app within a debugger, also called debugging mode, means that the debugger actively monitors everything that’s happening as the program runs. Кроме того, вы можете в любой точке приостановить работу приложения, исследовать его состояние и при необходимости перейти в режим пошагового выполнения, чтобы изучить необходимые строки кода более детально. It also allows you to pause the app at any point to examine its state, and to then step through your code line by line to watch every detail as it happens.

Чтобы перейти в режим отладки в Visual Studio, необходимо нажать клавишу F5 (также вы можете выбрать пункт меню Отладка > Начать отладку или нажать кнопку Начать отладку в панели инструментов «Отладка»). In Visual Studio, you enter debugging mode by using F5 (or the Debug > Start Debugging menu command or the Start Debugging button in the Debug Toolbar). Если возникает исключение, помощник по исправлению ошибок Visual Studio направит вас к точке его появления и предоставит другую необходимую информацию. If any exceptions occur, Visual Studio’s Exception Helper takes you to the exact point where the exception occurred and provides other helpful information. См. дополнительные сведения об обработке исключений в коде в разделе Приемы и инструменты отладки. For more information on how to handle exceptions in your code, see Debugging techniques and tools.

Если исключение не возникает, возможно, вам следует проанализировать определенные места в коде, которые могут являться источником проблемы. If you didn’t get an exception, you probably have a good idea where to look for the problem in your code. На этом этапе следует использовать точки останова в отладчике, благодаря которым вы сможете исследовать код более внимательно. This is where you use breakpoints with the debugger to give yourself a chance to examine your code more carefully. Точки останова — это один из самых простых и важных компонентов надежной отладки. Breakpoints are the most basic and essential feature of reliable debugging. Точка останова указывает, где Visual Studio следует приостановить выполнение кода, чтобы вы могли проверить значения переменных, поведение памяти или последовательность выполнения кода. A breakpoint indicates where Visual Studio should pause your running code so you can take a look at the values of variables, or the behavior of memory, or the sequence in which code runs.

Чтобы задать точку останова в Visual Studio, достаточно щелкнуть в левом поле рядом с интересующей вас строкой кода. In Visual Studio, you can quickly set a breakpoint by clicking in the left margin next to a line of code. Также для этого можно поместить указатель мыши в нужную строку и нажать клавишу F9. Or place the cursor on a line and press F9.

Чтобы продемонстрировать это, мы рассмотрим пример кода, который уже содержит несколько ошибок. To help illustrate these concepts, we take you through some example code that already has several bugs. В этом случае мы используем C#, однако функции отладки также работают для Visual Basic, C++, JavaScript, Python и других поддерживаемых языков. We are using C#, but the debugging features apply to Visual Basic, C++, JavaScript, Python, and other supported languages.

Создание образца приложения с ошибками Create a sample app (with some bugs)

Сейчас мы создадим приложение, которое содержит некоторые ошибки. Next, we will create an application that has a few bugs.

Для этого вам потребуется установленная среда Visual Studio с рабочими нагрузками Разработка классических приложений .NET или Кроссплатформенная разработка .NET Core (в зависимости от того, приложение какого типа вы создаете). You must have Visual Studio installed and either the .NET desktop development workload or the .NET Core cross platform development workload installed, depending on which app type you want to create.

Установите Visual Studio бесплатно со страницы скачиваемых материалов Visual Studio , если вы еще не сделали этого. If you haven’t already installed Visual Studio, go to the Visual Studio downloads page to install it for free.

Если у вас уже установлена среда Visual Studio без нужных рабочих нагрузок, щелкните Сервис > Получить средства и компоненты. If you need to install the workload but already have Visual Studio, click Tools > Get Tools and Features. Запускается Visual Studio Installer. The Visual Studio Installer launches. Выберите рабочую нагрузку Разработка классических приложений .NET или Кроссплатформенная разработка .NET Core, а затем щелкните Изменить. Choose the .NET desktop development (or .NET Core cross platform development) workload, then choose Modify.

Запустите Visual Studio. Open Visual Studio.

На начальном экране выберите Создать проект. On the start window, choose Create a new project. Введите консоль в поле поиска и выберите Консольное приложение (.NET Framework) или Консольное приложение (.NET Core). Type console in the search box and then choose Console App (.NET Framework) or Console App (.NET Core). Нажмите кнопку Далее. Choose Next. Введите имя проекта, например ConsoleApp-FirstApp, и нажмите кнопку Создать. Type a project name like ConsoleApp-FirstApp and click Create.

В верхней строке меню выберите Файл > Создать > Проект. From the top menu bar, choose File > New > Project. В левой области диалогового окна Новый проект в разделе Visual C# выберите Консольное приложение, а затем в средней области выберите Консольное приложение (.NET Framework) или Консольное приложение (.NET Core). In the left pane of the New project dialog box, under Visual C#, choose Console App, and then in the middle pane choose either Console App (.NET Framework) or Console App (.NET Core). Введите такое имя, как ConsoleApp-FirstApp, и нажмите кнопку ОК. Type a name like ConsoleApp-FirstApp and click OK.

Если шаблон проекта Консольное приложение (.NET Framework) или Консольное приложение (.NET Core) отсутствует, перейдите в меню Сервис > Получить средства и компоненты, после чего запустится Visual Studio Installer. If you don’t see the Console App (.NET Framework) or Console App (.NET Core) project template, go to Tools > Get Tools and Features, which opens the Visual Studio Installer. Выберите рабочую нагрузку Разработка классических приложений .NET или Кроссплатформенная разработка .NET Core, а затем выберите Изменить. Choose the .NET desktop development workload or the .NET Core cross platform development workload, then choose Modify.

Visual Studio создаст консольный проект и откроет его в обозревателе решений (правая область). Visual Studio creates the console project, which appears in Solution Explorer in the right pane.

Откройте файл Program.cs и замените все его содержимое по умолчанию следующим кодом. In Program.cs, replace all the default code with the following code:

Этот код выводит список, содержащий название галактики, расстояние до нее, а также тип галактики. Our intent for this code is to display the galaxy name, the distance to the galaxy, and the galaxy type all in a list. При отладке важно учитывать предназначение кода. To debug, it is important to understand the intent of the code. Ниже показан формат одной строки списка, который должен выводить код. Here is the format for one line from the list that we want to show in the output:

название галактики, расстояние, тип галактики. galaxy name, distance, galaxy type.

Запуск приложения Run the app

Нажмите клавишу F5 или кнопку Начать отладку в панели инструментов «Отладка», которая расположена над редактором кода. Press F5 or the Start Debugging button in the Debug Toolbar, located above the code editor.

По результатам запуска приложения отладчик не демонстрирует никаких исключений. The app starts and there are no exceptions shown to us by the debugger. Тем не менее данные, выводимые в окно консоли, не соответствуют ожиданиям. However, the output you see in the console window is not what you expect. Вот, что мы должны были увидеть. Here is the expected output:

Вместо этого выводятся следующие данные. But, we see this instead:

Проанализировав выходные данные и код, мы можем сделать вывод, что в классе GType содержится тип галактики. Looking at the output and at our code, we know that GType is the name of the class that stores the galaxy type. Нам необходимо выводить на экран тип галактики (например, Spiral), а не название класса. We are trying to show the actual galaxy type (such as «Spiral»), not the class name!

Отладка приложения Debug the app

Во время выполнения приложения щелкните в левом поле рядом с вызовом метода Console.WriteLine , чтобы задать точку останова в этой строке кода. With the app still running, set a breakpoint by clicking in the left margin next to the Console.WriteLine method call in this line of code.

В месте установки точки останова в левом поле появится красный круг. When you set the breakpoint, a red dot appears in the left margin.

Поскольку возникшая проблема связана с выходными данными, необходимо начать отладку с проверки кода, который выполняется перед установкой выходных данных. Because we see a problem in the output, we will start debugging by looking at the preceding code that sets the output in the debugger.

Нажмите кнопку Перезапустить на панели инструментов отладки (CTRL + SHIFT + F5). Click the Restart button in the Debug Toolbar (Ctrl + Shift + F5).

Выполнение приложения приостановится в заданной точке останова. The app pauses at the breakpoint that you set. Место приостановки отладчика будет выделено желтым цветом (при этом желтая строка кода на этот момент не выполнена). The yellow highlighting indicates where the debugger is paused (the yellow line of code has not yet executed).

Наведите указатель мыши на переменную GalaxyType справа. После этого разверните theGalaxy.GalaxyType слева от значка гаечного ключа. Hover over the GalaxyType variable on the right, and then, to the left of the wrench icon, expand theGalaxy.GalaxyType . Как вы можете видеть, GalaxyType содержит свойство MyGType , которому присваивается значение Spiral . You see that GalaxyType contains a property MyGType , and the property value is set to Spiral .

Изначально вы ожидаете, что в окно консоли будет выведено именно значение Spiral. «Spiral» is actually the correct value you were expecting to print to the console! Таким образом, вам следует проверить это значение в коде во время выполнения приложения. So it is a good start that you can access this value in this code while running the app. В этом сценарии мы используем неправильный API. In this scenario, we are using the incorrect API. Посмотрим, сможем ли мы исправить проблему во время выполнения кода в отладчике. We will see if we can fix this while running code in the debugger.

Во время отладки этого же кода установите указатель мыши в конец элемента theGalaxy.GalaxyType и измените его на theGalaxy.GalaxyType.MyGType . In the same code, while still debugging, put your cursor at the end of theGalaxy.GalaxyType and change it to theGalaxy.GalaxyType.MyGType . Несмотря на допустимость такого изменения, в редакторе кода отображается ошибка, свидетельствующая о невозможности выполнить компиляцию. Although you can make this change, the code editor shows you an error indicating it can’t compile this code.

Щелкните Изменить в окне сообщения Изменить и продолжить. Click Edit in the Edit and Continue message box. Сообщение об ошибке будет выведено в окне Список ошибок. You see an error message now in the Error List window. Эта ошибка указывает, что ‘object’ не содержит определение для MyGType . The error indicates that the ‘object’ doesn’t contain a definition for MyGType .

Несмотря на то что мы задаем каждую галактику с использованием объекта GType (который содержит свойство MyGType ), отладчик не распознает theGalaxy как объект типа GType . Even though we set each galaxy with an object of type GType (which has the MyGType property), the debugger does not recognize the theGalaxy object as an object of type GType . Что происходит? What’s going on? В этом случае необходимо проверить код, который задает тип галактики. You want to look through any code that sets the galaxy type. Вы увидите, что класс GType содержит свойство MyGType , однако все же что-то работает не так. When you do this, you see that the GType class definitely has a property of MyGType , but something isn’t right. Разгадка кроется в сообщении об ошибке для object . Интерпретатор языка воспринимает его как объект object вместо ожидаемого типа GType . The error message about object turns out to be the clue; to the language interpreter, the type appears to be an object of type object instead of an object of type GType .

Анализируя код, в котором задается тип галактики, вы можете увидеть, что свойство GalaxyType класса Galaxy задается как object вместо GType . Looking through your code related to setting the galaxy type, you find the GalaxyType property of the Galaxy class is specified as object instead of GType .

Измените предшествующий код на следующий. Change the preceding code to this:

Нажмите кнопку Перезапустить на панели инструментов отладки (CTRL + SHIFT + F5), чтобы выполнить повторную компиляцию кода и снова запустить его. Click the Restart button in the Debug Toolbar (Ctrl + Shift + F5) to recompile code and restart.

Когда отладчик приостановит выполнение на строке Console.WriteLine , вы можете навести указатель мыши на theGalaxy.GalaxyType.MyGType и убедиться, что значение задано правильно. Now, when the debugger pauses on Console.WriteLine , you can hover over theGalaxy.GalaxyType.MyGType , and see that the value is properly set.

Удалите точку останова, щелкнув ее кружок в левом поле (также для этого можно выбрать команду Точка останова > Удалить точку останова). После этого нажмите клавишу F5 для продолжения. Remove the breakpoint by clicking on the breakpoint circle in the left margin (or right-click and choose Breakpoint > Delete Breakpoint), and then press F5 to continue.

Приложение запускается и отображает выходные данные. The app runs and displays output. Теперь все работает правильно, однако вы можете заметить еще одну неточность. Для галактики Small Magellanic Cloud, которая имеет тип Irregular, в консоли не выводится никакой тип. It looks pretty good now, but you do notice one thing; you expected the Small Magellanic Cloud galaxy to show up as a Irregular galaxy in the console output, but it shows no galaxy type at all.

Задайте точку останова на этой строке кода. Set a breakpoint on this line of code.

Здесь задается тип галактики, поэтому нам необходимо изучить эту строку более пристально. This code is where the galaxy type is set, so we want to take a closer look at it.

Нажмите кнопку Перезапустить на панели инструментов отладки (CTRL + SHIFT + F5), чтобы запустить приложение снова. Click the Restart button in the Debug Toolbar (Ctrl + Shift + F5) to restart.

Отладчик приостановит работу в строке кода, где вы задали точку останова. The debugger pauses on the line of code where you set the breakpoint.

Наведите указатель мыши на переменную type . Hover over the type variable. Отображается значение S (после кода символа). You see a value of S (following the character code). Вас интересует значение I , поскольку эта галактика должна иметь тип Irregular. You are interested in a value of I , since you know that is an Irregular galaxy type.

Нажмите клавишу F5 и снова наведите указатель мыши на переменную type . Press F5 and hover over the type variable again. Повторяйте этот шаг, пока в переменной type не появится значение I . Repeat this step until you see a value of I in the type variable.

Нажмите клавишу F11 (выберите Отладка > Шаг с заходом или нажмите кнопку Шаг с заходом в панели инструментов «Отладка»). Now, press F11 (Debug > Step Into or the Step Into button in the Debug Toolbar).

Мастер Йода рекомендует:  Поля и отступы CSS - пояснение на примере четырех HTML-элементов

При нажатии клавиши F11 отладчик переходит на одну инструкцию вперед и выполняет соответствующий код. F11 advances the debugger (and executes code) one statement at a time. Клавиша F10 (Шаг с обходом) имеет схожую функцию и также полезна при работе с отладчиком. F10 (Step Over) is a similar command, and both are extremely useful when learning how to use the debugger.

Нажимайте клавишу F11 до тех пор, пока вы не остановитесь в строке кода с инструкцией switch для значения I. Press F11 until you stop on line of code in the switch statement for a value of ‘I’. Здесь вы увидите очевидную ошибку, связанную с опечаткой. Here, you see a clear problem resulting from a typo. Вы ожидали, что код будет выполнен дальше до места, где для MyGType задается тип Irregular, однако вместо этого отладчик полностью пропускает этот код и приостанавливает работу в разделе default инструкции switch . You expected the code to advance to where it sets MyGType as an Irregular galaxy type, but the debugger instead skips this code completely and pauses on the default section of the switch statement.

Взглянув на код, вы заметите опечатку в инструкции case ‘l’ . Looking at the code, you see a typo in the case ‘l’ statement. Вместо этого она должна иметь вид case ‘I’ . It should be case ‘I’ .

Щелкните код case ‘l’ и замените его на case ‘I’ . Click in the code for case ‘l’ and replace it with case ‘I’ .

Удалите точку останова и нажмите кнопку Перезапустить, чтобы запустить приложение снова. Remove your breakpoint, and then click the Restart button to restart the app.

Теперь все ошибки исправлены и приложение выдает ожидаемые результаты. The bugs are fixed now and you see the Output you expect!

Нажмите любую клавишу, чтобы завершить работу приложения. Press any key to finish the app.

Сводка Summary

Если вы сталкиваетесь с проблемой, воспользуйтесь отладчиком и командами пошагового выполнения, такими как F10 и F11, для поиска области кода, в которой возникают ошибки. When you see a problem, use the debugger and step commands such as F10 and F11 to find the region of code with the problem.

Если выявить проблемную область кода не удается, задайте точку останова в коде, который выполняется перед возникновением ошибки, после чего используйте команды пошагового выполнения, пока проблема не проявится. If it is difficult to identify the region of code where the problem occurs, set a breakpoint in code that runs before the problem occurs, and then use step commands until you see the problem manifest. Также вы можете использовать точки трассировки для вывода сообщений в окно вывода. You can also use tracepoints to log messages to the Output window. Анализируя сообщения, которые выводятся в окно или отсутствуют в нем, нередко можно изолировать область кода, где возникает проблема. By looking at logged messages (and noticing which messages were not yet logged!), you can often isolate the region of code with the problem. Для дальнейшего сужения области поиска этот процесс может потребоваться повторить несколько раз. You may have to repeat this process several times to narrow it down.

Выявив проблемную область кода, используйте отладчик для ее детального анализа. When you find the region of code with the problem, use the debugger to investigate. Чтобы определить причину возникновения проблемы, проверьте код во время выполнения приложения в отладчике. To find the cause of a problem, inspect the problem code while running your app in the debugger:

Проверьте переменные и убедитесь, что они содержат значения того типа, который вы ожидаете. Inspect variables and check whether they contain the type of values that they should contain. Если переменная содержит недопустимое значение, найдите, где оно было задано. Для этого может потребоваться перезапустить отладчик, проверить стек вызовов или выполнить одновременно оба этих действия. If you find a bad value, find out where the bad value was set (to find where the value was set, you might need to either restart the debugger, look at the call stack, or both).

Проверьте, выполняет ли ваше приложение код, который вы ожидаете. Check whether your application is executing the code that you expect. (Так, в примере приложения должна была выполняться инструкция switch, устанавливающая тип галактики Irregular, однако нужный код был пропущен из-за опечатки.) (For example, in the sample application, we expected the code for the switch statement to set the galaxy type to Irregular, but the app skipped the code due to the typo.)

Отладчик представляет собой эффективное средства для выявления ошибок. You use a debugger to help you find bugs. Средство отладки может искать ошибки вместо вас в том случае, если ему известно предназначение кода. A debugging tool can find bugs for you only if it knows the intent of your code. Для этого вы должны указать предназначение. A tool can only know the intent of your code if you, the developer, express that intent. Этого можно добиться с помощью модульных тестов. Writing unit tests is how you do that.

Следующие шаги Next steps

Из этой статьи вы узнали общие принципы отладки приложений. In this article, you’ve learned a few general debugging concepts. Теперь вы можете приступить к изучению других возможностей отладчика. Next, you can start learning more about the debugger.

Как правильно получить код ошибки от команды git в batch скрипте?

Здравствуйте. У меня была самая банальная потребность, с помощью batch скрипта, обновлять локальный репозиторий git и в случае какой-либо ошибки возвращать лог и код ошибки. Но я натолкнулся на такую очень странную ситуацию:
Команда git возвращает ошибку (IF ERRORLEVEL 1 = TRUE, то есть код ошибки >= 1, то есть != 0), но при этом код ошибки — echo %errorlevel% выводит «0».
Пробовал другой метод проверки, использовал логическое ИЛИ (то есть выполнить вторую часть, только если предыдущая вернула ошибку, оператор «||» ) и то же самое.
Поэтому возникает несколько вопросов:
1) сам код ошибки мне не так важен, но из-за этого я сомневаюсь в том, можно ли в качестве проверки использовать «IF ERRORLEVEL 1» ? Надёжно это?
2) Есть ли какой-то способ всё-таки получить код ошибки?
3) Как такое вообще возможно?!

Все эти варианты выводят «ERRORCODE_IS_0»:

Ошибку генерю просто: невозможность fast-forward’а. Вот собственно вывод команды:
Already on ‘master’
Your branch and ‘origin/master’ have diverged,
and have 14 and 19 different commits each, respectively.
(use «git pull» to merge the remote branch into yours)
Fetching origin
fatal: Not possible to fast-forward, aborting.
ERRORCODE_IS_0

  • Вопрос задан более трёх лет назад
  • 391 просмотр

Получить код ошибки:

[команда]
set err=%errorlevel%
echo.Дальше делаем с кодом ошибки все что захотим: %err%

Обрабатывать можно как рекомендуют в справке по if /?:

goto answer%errorlevel%
:answer1
.
:answer2
.

if errorlevel 1 — вполне надежно использовать, но слишком громоздкая конструкция и одноразовая. Я обычно предпочитаю вариант с оператором ||.
Кстати, многие утилиты командной строки забивают на возврат кода ошибки 🙁

Отладка кода с Git: 3 инструмента для поиска ошибок

Здравствуйте!
Часто для поиска ошибки у клиента необходимо использовать отладчик.
Само собой разумеется что JIT-отладка активирована ( как активировать отладчик описано тут )

    1.Самый простой вариант это использовать Microsoft Script Debugger, установить его можно можно с папки (или при установке Terraosft с MSI пакета, выбрать опцию установки отладчика)

При возникновении ошибки или явного вызова отладчика (Установка точек останова в конфигурации)

Минусы в том, что он очень неудобен в использовании

2.В компонентах Office 2003/2007 есть такой инструмент как Microsoft Script Editor, который намного удобнее чем Microsoft Script Debugger (к сожалению, в Office 2010 компонент отсутствует). По умолчанию Microsoft Script Editor не устанавливается вместе с MS Office. Доставить его можно следующим образом:

Сам отладчик находится в папке

Если MSE не вызывается, следует проверить опцию

По функциональности Microsoft Script Editor почти не уступает возможностям отладки в Visual Studio

3. Установить Microsoft Visual Studio 2005/2008/2010 и использовать ее для JIT отладки

Отладка в браузере Chrome

Давайте отвлечёмся от написания кода и поговорим о его отладке.

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

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

Панель «Исходный код» («Sources»)

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

  • Работая в Chrome, откройте тестовую страницу.
  • Включите инструменты разработчика, нажав F12 (Mac: Cmd + Opt + I ).
  • Щёлкните по панели sources («исходный код»).

При первом запуске получаем следующее:

Кнопка-переключатель откроет вкладку со списком файлов.

Кликните на неё и выберите hello.js . Вот что появится:

Интерфейс состоит из трёх зон:

  1. В зоне Resources (Ресурсы) показаны файлы HTML, JavaScript, CSS, включая изображения, используемые на странице. Здесь также могут быть файлы различных расширений Chrome.
  2. Зона Source показывает исходный код.
  3. Наконец, зона Information and control (Сведения и контроль) отведена для отладки, вскоре мы к ней вернёмся.

Чтобы скрыть список ресурсов и освободить экранное место для исходного кода, щёлкните по тому же переключателю .

Консоль

При нажатии на клавишу Esc в нижней части экрана вызывается консоль, где можно вводить команды и выполнять их клавишей Enter .

Результат выполнения инструкций сразу же отображается в консоли.

Например, результатом 1+2 будет 3 , а инструкция hello(«debugger») ничего не возвращает, так что получаем undefined :

Точки останова (breakpoints)

Давайте разберёмся, как работает код нашей тестовой страницы. В файле hello.js щёлкните по строчке номер 4 . Да, щёлкайте именно по самой цифре, не по коду.

Ура! Вы поставили точку останова. А теперь щёлкните по цифре 8 на восьмой линии. Номер строки будет окрашен в синий цвет.

Вот что в итоге должно получиться:

Точка останова – это участок кода, где отладчик автоматически приостановит исполнение JavaScript.

Пока исполнение поставлено «на паузу», мы можем просмотреть текущие значения переменных, выполнить команды в консоли, одним словом, мы выполняем отладку кода.

В правой части графического интерфейса мы видим список точек останова. А когда таких точек выставлено много, да ещё и в разных файлах, этот список поможет эффективно ими управлять:

  • Быстро переместиться к любой точке останова в коде – нужно щёлкнуть по точке в правой части экрана.
  • Временно деактивировать точку – в общем списке снимите галочку напротив ненужной в данный момент точки.
  • Удалить точку – щёлкните по ней правой кнопкой мыши и выберите Remove (Удалить).
  • …и так далее.

Можно задать и так называемую условную точку останова – щёлкните правой кнопкой мыши по номеру строки в коде. Если задать выражение, то именно при его истинности выполнение кода будет приостановлено.

Этот метод используется, когда выполнение кода нужно остановить при присвоении определённого выражения какой-либо переменной или при определённых параметрах функции.

Команда Debugger

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

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

Остановимся и оглядимся

В нашем примере функция hello() вызывается во время загрузки страницы, поэтому для начала отладки (после того, как мы поставили точки останова) проще всего её перезагрузить. Нажмите F5 (Windows, Linux) или Cmd + R (Mac).

Выполнение прервётся на четвёртой строчке:

Чтобы понять, что происходит в коде, щёлкните по стрелочкам справа:

Watch показывает текущие значения выражений.

Нажмите на + и введите выражение. В процессе выполнения отладчик автоматически пересчитывает и выводит его значение.

Call Stack показывает последовательность вызовов функций.

В нашем примере отладчик работает с функцией hello() , вызванной скриптом из файла index.html (там нет функции, поэтому вызов «анонимный»).

При нажатии на элемент списка (например, на «anonymous») отладчик переходит к соответствующему коду, и нам представляется возможность его проанализировать.

Scope показывает текущие переменные.

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

В Global перечисляются глобальные переменные (т.е. объявленные за пределами функций).

Не обращайте пока внимание на ключевое слово this – его мы изучим чуть позже.

Пошаговое выполнение скрипта

А теперь давайте пошагаем по нашему коду.

В правой части панели для этого есть несколько кнопок. Рассмотрим их.

– продолжить выполнение. Быстрая клавиша – F8 .

Возобновляет выполнение кода. Если больше нет точек останова, отладчик прекращает работу и позволяет приложению работать дальше.

Вот, что мы увидим, кликнув на неё:

Выполнение кода возобновилось, дошло до другой точки останова внутри say() , и отладчик снова приостановил выполнение. Обратите внимание на пункт «Call stack» справа: в списке появился ещё один вызов. Мы теперь внутри функции say() .

– сделать шаг (выполнить следующую команду), не заходя в функцию. Быстрая клавиша – F10 .

Если мы нажмём на неё – будет вызван alert . Важно: на месте alert может быть любая другая функция, выполнение просто перешагнёт через неё, полностью игнорируя её содержимое.

– сделать шаг. Быстрая клавиша – F11 .

В отличие от предыдущего примера, здесь мы «заходим» во вложенные функции и шаг за шагом проходим по скрипту.

– продолжить выполнение до завершения текущей функции. Быстрая клавиша – Shift + F11 .

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

– активировать/деактивировать все точки останова.

Эта кнопка не влияет на выполнение кода, она лишь позволяет массово включить/отключить точки останова.

– разрешить/запретить остановку выполнения в случае возникновения ошибки.

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

Если щёлкнуть правой кнопкой мыши по строчке кода, в контекстном меню можно выбрать опцию «Continue to here» («продолжить до этого места»).

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

Логирование

Если нужно что-то вывести в консоль из кода, применяется функция console.log .

К примеру, выведем в консоль значения от нуля до четырёх:

Обычный пользователь сайта не увидит такой вывод, так как он в консоли. Напомним, что консоль можно открыть через инструменты разработчика – выберите вкладку «Консоль» или нажмите Esc , находясь в другой вкладке – консоль откроется в нижней части интерфейса.

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

Итого

Приостановить выполнение скрипта можно тремя способами:

  1. Точками останова.
  2. Использованием в коде команды debugger .
  3. При ошибке (если инструменты разработчика открыты и опция включена).

При остановке мы можем отлаживать – проанализировать переменные и пошагово пройти по процессу, что поможет отыскать проблему.

Нами описаны далеко не все инструменты разработчика. С полным руководством можно ознакомиться здесь: https://developers.google.com/web/tools/chrome-devtools.

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

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

Отладка JavaScript с помощью настоящего отладчика

Новый отладчик JavaScript , встроенный в Firefox , поможет писать код быстро и без ошибок. В последней версии отладчика Firefox мы откроем простое приложение, а затем запустим debugger.html , использовав клавиатурную комбинацию Option + Cmd + S на Mac или Shift + Ctrl + S в Windows . Отладчик разделён на три панели: панель списка файлов, панель исходного кода и панель инструментов.

Панель инструментов разделена на кнопки для вызова инструментов, выражения для отслеживания, точки остановки, стек вызовов и области.

Перестаньте использовать console.log

В этом примере мы используем debugger.html , чтобы отладить приложение по шагам и найти значение переменной.

Мы можем использовать debugger.html , чтобы заглянуть в исходный код приложения, просто добавив breakpoints . Эти точки говорят отладчику остановить выполнение программы на указанной строке. В этом примере мы добавим breakpoints на строке 13 файла app.js .

Теперь добавьте задачу в список. Код остановится в функции addTodo , и мы сможем залезть в исходный код, чтобы посмотреть введённое значение и многое другое. Наведите курсор на переменную, чтобы увидеть её значение и другие свойства. Вы сможете посмотреть свойства anchors , applets , дочерние элементы и так далее.

Вы также сможете посмотреть всю эту информацию в панели « Области ».

Теперь, когда выполнение скрипта приостановлено, его можно выполнить по шагам, используя кнопки в панели инструментов. Назначение кнопки « Возобновить/Пауза » очевидно. « Перешагнуть через » перешагивает через текущую строку кода, « Зайти в » заходит в вызываемую функцию, а « Выйти из » выполняет скрипт до выхода из текущей функции.

Также можно использовать выражения для отслеживания, чтобы следить за значением переменной. Введите выражение в поле « Выражения для отслеживания «, и отладчик будет следить за ним по мере того, как вы выполняете код по шагам. В примере, приведенном выше, можно добавить выражения « title » и « to-do «, и отладчик выдаст их значения, когда они станут доступны. Это особенно полезно в следующих случаях:

  • Когда выполняете код по шагам и следите за изменением значений;
  • Отлаживаете один и тот же кусок исходного кода несколько раз и хотите оценить одни и те же выражения;

Вы также можете использовать debugger.html , чтобы отладить приложения React/Redux . Вот как это работает:

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

Также debugger.html позволяет увидеть скрытый или сжатый код, который может вызывать ошибки. Это полезно, когда вы имеете дело с популярными фреймворками, вроде React/Redux . Отладчик знает про компоненты, на которых вы остановили выполнение кода, и покажет упрощённый стек вызовов, компонент и свойства.

Инструменты разработчика с открытым исходным кодом

Проект debugger.html был запущен около двух лет назад одновременно с полной переработкой инструментов разработчика, встроенных в Firefox . Мы хотели перестроить инструменты разработчика, используя современные веб-технологии.

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

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

debugger.html построен при помощи React , Redux и Babel . Компоненты React легковесные, тестируемые и легкие в разработке. Мы используем React Storybook для быстрого прототипирования пользовательского интерфейса и документирования общих компонентов.

Наши компоненты протестированы с помощью Jest и Enzyme , что упрощает итерации обновления пользовательского интерфейса. Это упрощает работу с различными JavaScript-фреймворками .

front-end код на Babel позволяет отображать класс компонента и его функции в левой панели. А также фиксировать breakpoints к функциям так, чтобы они не перемещались, когда вы изменяете исходный код.

Действия Redux – это чистый API для пользовательского интерфейса, но они также могут быть использованы для создания отдельного отладчика CLI JS . В хранилище Redux есть селекторы для выбора текущего состояния отладки.

Модульное тестирование вызывает действия Redux и симулирует ответы браузера. Интеграционные тесты отладчика управляют браузером с отладчиком действий Redux . Функциональная архитектура сама по себе разработана так, чтобы быть тестируемой.

Мы полагались на сообщество разработчиков Mozilla на каждом этапе. Проект был размещён на GitHub , и наша команда связывалась с разработчиками по всему миру, чтобы получить их поддержку.

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

Как разработчики, мы верим, что инструменты тем надёжнее, чем больше людей включилось в процесс их создания. Наша основная команда всегда была маленькой ( 2 человека ). Но в среднем в нашей работе принимало участие 15 разработчиков в неделю. Сообщество вносит разнообразие во взглядах, что помогает справляться с возникающими трудностями и создавать функционал, о котором мы и не мечтали. Теперь мы формируем стек вызовов для 24 различных библиотек. Мы также показываем карту привязок в WebPack и Angular в дереве исходного кода.

Мы планируем переместить все инструменты разработчика Firefox на GitHub , чтобы они могли быть использованы и улучшены широкой аудиторией.

Мы будем рады вашему участию. Зайдите на страницу проекта debugger.html на GitHub , чтобы начать. Мы создали подробные инструкции, чтобы помочь запустить отладчик на вашем компьютере. Используйте его, чтобы выполнять отладку JavaScript-кода для чего угодно: браузеров, терминалов, серверов, смартфонов, роботов. И, если вы видите, как его можно улучшить, дайте нам знать через GitHub .

Вы можете загрузить текущую версию Firefox (и инструментов разработчика) здесь .

Данная публикация представляет собой перевод статьи « Debugging JavaScript With A Real Debugger You Did Not Know You Already Have » , подготовленной дружной командой проекта Интернет-технологии.ру

Добавить комментарий