Лекция 0. ИИ и Git

ИИ и GitЯзыковые модели в разработке и контроль версий
Вячеслав Федоров
Лекция 0
Разработка и применение ПО
в физических исследованиях
+-
Изложение. Нулевая лекция открывает курс и посвящена двум инструментам, с которых начинается любая работа с кодом: помощникам на больших языковых моделях и системе контроля версий Git. Знаки на титуле — плюс и минус из вывода git diff, которыми отмечаются добавленные и удалённые строки.
Демонстрации. Слайды с розовым выделением слова «Демонстрация» отмечают места, где изложение прерывается для работы в терминале виртуальной машины lab или в редакторе кода. На слайдах с записью справа проигрываются те же команды, поэтому демонстрация видна и без живого терминала.

СодержаниеДва инструмента, с которых начинается работа с кодом
01
ИИ в разработке
02
Устройство модели
03
Инструменты ИИ
04
Основы Git
05
Ветки и слияние
06
Совместная работа
Изложение. Лекция состоит из двух половин. В первой рассматривается, откуда появились помощники на языковых моделях, что известно об их влиянии на скорость работы, как устроена модель и какие формы принимают инструменты. Во второй половине рассматривается система контроля версий Git: её устройство, ветки и слияние, совместная работа через удалённые репозитории. Половины связаны: работа с ассистентом, правящим десятки файлов за раз, безопасна только в репозитории под контролем версий.

Цель лекцииПрофессиональный минимум: ассистент на языковой модели и контроль версий
Инструмент усиливает того, кто понимает, что делает, и подводит того, кто не понимает. Ответственность за строку, сгенерированную моделью, остаётся на подписавшем работу.
Изложение. Обсуждение ИИ-инструментов нередко сводится к одной из двух крайностей: либо код теперь пишет нейросеть и учиться незачем, либо инструмент непригоден для серьёзных задач. Обе позиции опровергаются фактами: инструмент установлен у большинства разработчиков, а результаты его применения измерены и опубликованы. Поэтому изложение строится на измерениях.
Код, который студент не может объяснить, нельзя сдавать независимо от того, кем он написан: ответственность за строку, сгенерированную моделью, остаётся на подписавшем работу. Git при этом обеспечивает обратимость: всё, что сделано ассистентом, видно в истории и откатывается одной командой.

ИИ в разработкеИстория, распространение и измерения
01
ИИ в разработке
Устройство модели
Инструменты ИИ
Основы Git
Ветки и слияние
Совместная работа
Изложение. Первая часть посвящена тому, откуда появились помощники на языковых моделях и что известно об их влиянии на работу программиста — не по впечатлениям, а по измерениям.

Хронология
развития
2012
AlexNet
победа глубоких свёрточных сетей на графических ускорителях в ImageNet
2014
GAN
убедительное порождение данных нейросетями
2017
Трансформер
статья «Attention Is All You Need»: архитектура современных моделей
2018–2020
Масштабирование
рост качества с числом параметров, объёмом данных и вычислений; GPT-2 и GPT-3
2022
ChatGPT
дообучение под диалог и удобный интерфейс к существующей модели
Пояснение
Между научной идеей и инструментом на рабочем столе проходят годы: трансформеру к выходу ChatGPT было уже пять лет.
Изложение. Нынешний подъём растянут на десятилетие, однако до 2022 года он почти не выходил за пределы исследовательских лабораторий. В 2012 году сеть AlexNet выиграла соревнование ImageNet и показала, что глубокие свёрточные сети, обученные на графических ускорителях, решают задачи компьютерного зрения лучше прежних методов. В 2014 году Ян Гудфеллоу предложил генеративно-состязательные сети: нейросети начали порождать данные, а не только раскладывать их по классам. В 2017 году статья «Attention Is All You Need» ввела архитектуру трансформера, лежащую в основе практически всех больших языковых моделей. В 2018–2020 годах были обнаружены законы масштабирования, связывающие качество модели с числом параметров, объёмом данных и вычислительным бюджетом, появились GPT-2 и GPT-3.
ChatGPT в 2022 году стал прорывом не архитектуры, а дообучения под диалог и удобного интерфейса к модели, существовавшей и раньше.
К заявлениям руководителей индустрии о скором «взлёте» и сингулярности целесообразно относиться с поправкой на их заинтересованность в притоке инвестиций: речь идёт об инструменте с конкретными сильными и слабыми сторонами.

Скорость
распространения
5
дней
понадобилось ChatGPT, чтобы набрать миллион пользователей; Instagram — около двух с половиной месяцев
2/3
разработчиков
уже применяли ИИ-инструменты в работе по опросу Stack Overflow 2024 года
1/7
разработчиков
собирались начать применять ИИ-инструменты по тому же опросу
Тот же опрос: инструментами пользуются охотно, однако коду, предложенному моделью, не доверяют и перепроверяют его.
Для физика
Инструмент, освоенный большинством коллег, становится частью профессионального минимума, как двадцать лет назад система контроля версий.
Изложение. Миллион пользователей ChatGPT набрал за пять дней; Instagram потребовалось около двух с половиной месяцев, Airbnb и Netflix — годы. Этой скоростью объясняется и объём инвестиций в дата-центры и обучение моделей. По опросу Stack Overflow 2024 года, охватившему десятки тысяч человек, около двух третей разработчиков уже применяли ИИ-инструменты в работе и ещё примерно каждый седьмой собирался начать; в следующих выпусках опроса доля растёт. Тот же опрос показывает, что инструментами пользуются охотно, однако коду, предлагаемому моделью, не доверяют и перепроверяют его.
Инструмент, освоенный большинством коллег, становится частью профессионального минимума, подобно тому как это произошло с системой контроля версий двадцать лет назад; отказ от него требует обоснования.

Ощущения и
измерения
Замер
19 %
медленнее выполнялись задачи с ассистентом
Ощущение участников
20 %
ускорения — по оценке тех же разработчиков
METR, 2025: опытные разработчики проектов с открытым кодом решали задачи в собственных хорошо знакомых репозиториях; ассистент разрешался или запрещался по случайному выбору.
01
Ощущение ускорения не заменяет измерения
помогает ли инструмент, устанавливается только замером
02
Выигрыш зависит от знания задачи
в незнакомой библиотеке и шаблонном коде он реален, в своём коде у эксперта — нет
Изложение. В 2025 году организация METR провела эксперимент со строгим контролем. Опытным разработчикам, годами ведущим проекты с открытым кодом, давали задачи в их собственных хорошо знакомых репозиториях; часть задач, выбранная случайным образом, решалась с ИИ-ассистентом, часть без него. С ассистентом задачи выполнялись примерно на 19 % медленнее. Важна не сама цифра, а знак, противоположный ожиданиям и авторов, и участников. Те же участники после эксперимента были уверены, что ИИ ускорил их работу примерно на 20 %: ощущение разошлось с замером почти на 40 процентных пунктов.
Результат получен на экспертах в знакомом им коде, где человек и так работает близко к пределу, а ассистент добавляет накладные расходы: прочитать фрагмент, проверить и исправить. Он ничего не говорит о ситуации, где разработчик осваивает незнакомую библиотеку, пишет шаблонный код или работает на неродном языке программирования: там выигрыш реален.
Отсюда два вывода: ощущение ускорения не заменяет измерения; выигрыш тем меньше, чем лучше разработчик знает задачу, и тем важнее умение отличить дельное предложение от правдоподобной ошибки. Умение пользоваться ИИ является отдельным навыком, осваиваемым так же, как отладчик или система контроля версий.

Устройство моделиТокены, обучение, ошибки, агенты
02
ИИ в разработке
Устройство модели
Инструменты ИИ
Основы Git
Ветки и слияние
Совместная работа
Изложение. Вторая часть содержит минимум сведений об устройстве языковой модели, без которого невозможно понять ни её сильные стороны, ни отказы, обусловленные самим устройством.

Предсказание
следующего токена
Текст запроса
Токенизатор
Трансформер: слои внимания
Вероятности следующего токена
Выбранный токен
дописывание токена к тексту и повторение цикла
Пояснение
Диалог, генерация кода и объяснения надстроены над одной задачей: продолжить имеющийся текст.
Пояснение
Внимание позволяет связать определение функции в начале файла с её вызовом в конце.
Изложение. Большая языковая модель решает одну задачу: предсказывает по имеющемуся тексту, какой фрагмент будет следующим. Диалог, генерация кода и объяснения надстроены над этим механизмом. Текст разбивается токенизатором на токены, токены преобразуются в векторы и проходят через десятки слоёв трансформера. Ключевым механизмом внутри является внимание (attention): при обработке каждого токена модель взвешивает, насколько для него важен каждый из остальных, и благодаря этому связывает определение функции в начале файла с её вызовом в конце. На выходе получается распределение вероятностей следующего токена; выбранный токен дописывается к тексту, и цикл повторяется, пока ответ не завершён.

Токены и
язык запроса
Русский, токенизатор cl100k_base: 26 токенов на 9 слов
Git
·х
ран
ит
·с
н
им
ки
·про
ект
а
,
·а
·не
·раз
лич
ия
·м
еж
д
у
·вер
с
ия
ми
.
Русский, токенизатор o200k_base: 15 токенов
Git
·хран
ит
·сним
ки
·проекта
,
·а
·не
·различ
ия
·между
·версия
ми
.
Английский, оба токенизатора: 12 токенов на 10 слов
Git
·stores
·snapshots
·of
·the
·project
,
·not
·differences
·between
·versions
.
· — пробел в начале токена. Токенизаторы OpenAI: cl100k_base (GPT-4) и o200k_base (GPT-4o).
Пояснение
Цена запроса и заполнение контекстного окна считаются в токенах: один и тот же текст на русском обходится дороже.
Изложение. Модель работает не со словами, а с токенами — фрагментами текста, выделенными токенизатором. Частые слова английского языка обычно занимают один токен, а кириллица, представленная в словарях моделей хуже, разбивается на более мелкие части. На слайде одна фраза разбита двумя токенизаторами OpenAI: в cl100k_base, применявшемся в GPT-4, русская фраза из девяти слов занимает 26 токенов, почти по три на слово, а её английский перевод из десяти слов — 12. В более новом o200k_base кириллица представлена лучше, и та же фраза занимает 15 токенов, однако и здесь она дороже английской. Цена запроса и заполнение контекстного окна считаются в токенах, поэтому один и тот же текст на русском обходится дороже и быстрее заполняет контекст.
Разбиение получено библиотекой tiktoken; у моделей других разработчиков токенизаторы свои, и числа будут другими.

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

Уверенные
ошибки
Модель обучена порождать правдоподобное продолжение, а не истинное; механизма проверки фактов у неё нет.
01
Выдуманный аргумент функции
в документации его нет, но «логично было бы иметь»
02
Несуществующая ссылка
правдоподобный адрес статьи или страницы документации
03
Перепутанный коэффициент
формула выглядит уверенно, программа выдаёт числа
04
Несуществующая библиотека
осмысленное название; обнаруживается при первом импорте
Для физика
Несуществующая библиотека обнаруживается сразу, а перепутанный коэффициент может дойти до отчёта. Сведения ассистента о физике, численных методах и API проверяются по документации.
Изложение. Здесь заключена главная причина, по которой ИИ-ассистент не заменяет понимания. Модель обучена порождать правдоподобное продолжение, а не истинное, и механизма проверки фактов у неё нет. Если правильный ответ ей неизвестен, она не сообщит об этом, а сгенерирует то, что выглядит как правильный ответ. Такие выдумки называют галлюцинациями; в программировании они принимают узнаваемые формы: аргумент функции, придуманный по аналогии; правдоподобная, но выдуманная ссылка; формула с перепутанным коэффициентом; библиотека с осмысленным названием, которой не существует.
Для физиков: несуществующая библиотека обнаруживается на первом же импорте, а перепутанный коэффициент в научном коде может остаться незамеченным — программа запускается, выдаёт числа, числа попадают в отчёт. Всё, что ассистент сообщает о физике, численных методах и API библиотек, проверяется по документации и здравому смыслу; код, в котором разработчик не разобрался, в проект не включается.

Демонстрация:
цепь Маркова
01
Корпус: главы книги об ИИ и Git
02
Начало корпуса
03
Текст из 40 слов
04
Второй запуск: другой текст
Что наблюдается
Каждая пара соседних слов взята из книги, поэтому текст звучит связно, но утверждения в нём порождены случаем.
root@lab — запись со стенда
Демонстрация. Корпус составлен из глав книги об ИИ и Git, всего около пяти тысяч слов. Программа запоминает, какое слово за каким встречалось в тексте, выбирает случайное стартовое слово с заглавной буквы и затем каждый раз случайно выбирает одного из встречавшихся преемников. Каждая пара соседних слов на выходе взята из книги, поэтому текст звучит связно и в стиле источника, однако утверждения в нём порождены случаем: например, «Программа запускается, выдаёт числа, числа попадают в общий репозиторий». Это простейшая языковая модель; большие модели учитывают несравнимо больший контекст, но принцип правдоподобного продолжения тот же.
Домашнее задание. Такую программу предстоит написать самостоятельно, поэтому её код на слайде не показан.

Характеристики
модели
01
Размер
число параметров — от единиц миллиардов до триллионов; чем больше модель, тем тоньше улавливаемые зависимости, но тем дороже и медленнее работа
02
Контекстное окно
сколько токенов модель видит за раз, включая вопрос, файлы и ответ; детали из середины длинного контекста удерживаются хуже
03
Рассуждение
модели, порождающие промежуточные шаги, сильнее в многошаговых задачах, но отвечают дольше и стоят дороже
Пояснение
Названия моделей и цены меняются каждые несколько месяцев; сравнение по качеству, скорости и стоимости ведут независимые площадки artificialanalysis.ai и openrouter.ai.
Изложение. Характеристики модели складываются из трёх составляющих. Размер — число обучаемых параметров, от единиц миллиардов до триллионов: чем модель больше, тем более тонкие зависимости она способна уловить, но тем дороже и медленнее её работа; для простых задач небольшая модель отвечает быстрее и дешевле при том же результате. Контекстное окно — число токенов, которое модель видит за раз, включая вопрос, приложенные файлы и собственный ответ; это главный практический предел, и чем ближе к нему, тем хуже модель удерживает детали из середины контекста. Способность к рассуждению: часть моделей обучена перед ответом порождать промежуточные шаги, такие модели сильнее в математике и отладке, но отвечают дольше и стоят дороже.
Названия моделей и цены здесь не приводятся: они устаревают быстрее, чем пишется текст. Выбор модели для работы с кодом делается прогоном двух-трёх кандидатов на собственных типичных задачах.

Запрос и
контекст


ПриёмСуть
Zero-shotвопрос без примеров; достаточно для типовых задач
Few-shotодин-два примера в нужном формате
Chain-of-thoughtпросьба рассуждать по шагам; в рассуждающих моделях встроена

Пояснение
Качество ответа определяется не изяществом формулировки, а тем, что модель видит: нужный файл, сообщение об ошибке целиком, фрагмент документации.
Для физика
Трейсбек прикладывается целиком, а не пересказывается по памяти.
Изложение. Способы формулировать запрос называют промтингом. Zero-shot — вопрос без примеров, работает для типовых задач; few-shot — один-два примера в нужном формате, повышающие шансы получить ответ по образцу; chain-of-thought — просьба рассуждать по шагам, помогающая в многошаговом выводе и встроенная в рассуждающие модели.
Качество ответа определяется не изяществом формулировки, а тем, что модель видит. Если ей предоставлены нужный файл, сообщение об ошибке целиком и фрагмент документации, то и посредственный запрос даёт результат; без них модель начинает додумывать недостающее. Этот подход называют контекст-инжинирингом, и он важнее промтинга.

Приём	Суть
Zero-shot	вопрос без примеров; достаточно для типовых задач
Few-shot	один-два примера в нужном формате
Chain-of-thought	просьба рассуждать по шагам; в рассуждающих моделях встроена

Агенты
Задача
Выбор действия моделью
Инструмент: файлы, команды, поиск
Готовый результат
вызов
результат
чтение и запись файлов, запуск команд и тестов, поиск по репозиторию
Важно
Агент выполняет команды в системе пользователя: его допускают только в репозиторий под контролем версий.
Изложение. Агентом называют языковую модель, помещённую в цикл и снабжённую инструментами чтения и записи файлов, запуска команд и поиска по репозиторию. Модель получает задачу, выбирает инструмент, анализирует результат и по нему решает, что делать дальше, пока задача не решена. Этот цикл превращает чат в инструмент, способный самостоятельно найти ошибку в проекте, исправить код и запустить тесты.
Главный риск состоит в том, что агент выполняет команды в системе пользователя. Первое правило работы с агентом: допускать его только в репозиторий под контролем версий. К этому правилу лекция возвращается во второй половине.

Инструменты ИИФормы, правила, MCP, Copilot
03
ИИ в разработке
Устройство модели
Инструменты ИИ
Основы Git
Ветки и слияние
Совместная работа
Изложение. Инструменты меняются каждые несколько месяцев, поэтому в третьей части важнее запомнить не названия, а формы, в которых ИИ приходит в разработку, и правила безопасной работы с ними.

Три формы
инструментов
01
Плагин к редактору
работает в привычной среде: VS Code, JetBrains, Neovim
GitHub Copilot
02
Редактор вокруг ассистента
модель видит проект целиком; большинство таких редакторов выросло из VS Code
Cursor, Windsurf
03
Терминальный агент
работает в каталоге проекта: правит файлы, запускает тесты; подходит для кластера по SSH
Claude Code, Aider, Gemini CLI
Пояснение
Границы между формами размываются: редакторы получают агентный режим, агенты — интеграцию с IDE. Выбор определяется тем, где ведётся работа.
Изложение. ИИ приходит в разработку в трёх формах. Первая, наиболее простая для входа, — плагин к редактору: он устанавливается в привычную среду (VS Code, JetBrains, Neovim) и работает внутри неё; наиболее известный пример — GitHub Copilot. Вторая — редактор, спроектированный вокруг ассистента, в котором модель видит проект целиком, а не только открытый файл; большинство таких редакторов выросло из VS Code, поэтому переход почти не требует привыкания (Cursor, Windsurf). Третья — терминальный агент, работающий в командной строке в каталоге проекта: он читает и правит файлы, запускает тесты и разбирает вывод (Claude Code, Aider, Gemini CLI).
Для физиков: терминальный агент лучше остальных форм подходит для больших проектов и удалённых машин без графической оболочки — обычной ситуации при работе на кластере по SSH.

Глубина
вмешательства
01
Автодополнение
продолжение по ходу набора; серый текст легко принять без чтения
02
Правка выделенного
«добавь обработку ошибок», «векторизуй этот цикл»
03
Чат по проекту
вопрос со ссылками на файлы и трейсбеком
04
Агентный режим
читает файлы, вносит правки, запускает тесты и исправляется сам
меньше самостоятельности
больше самостоятельности, меньше контроля — тщательнее проверка
Изложение. Набор возможностей у всех инструментов примерно одинаковый, различается глубина вмешательства в код. Автодополнение предлагает продолжение по ходу набора; подсказка серым текстом выглядит правдоподобно, и её легко принять без чтения. Правка выделенного: разработчик выделяет фрагмент и указывает, что с ним сделать. Чат по проекту позволяет сослаться на файлы и подходит для вопроса, почему программа завершается с ошибкой, с приложенным трейсбеком. В агентном режиме задача ставится целиком, а агент сам читает нужные файлы, вносит правки, запускает тесты и исправляет код по непройденным тестам.
Чем ниже по этому списку, тем больше инструмент делает сам, тем меньше контроля остаётся у разработчика и тем внимательнее необходимо проверять результат.

Правила
проекта
Файл правил в корне репозитория (пример договорённостей группы):
- Код на Python 3.12, стиль — PEP 8, длина строки 79 символов.
- Единицы СИ везде, кроме энергии частиц: она в МэВ.
- Массивы обрабатываем векторизованно, циклов по элементам не пишем.
- Новый код сопровождается тестом в tests/.
- Данные экспериментов в репозиторий не коммитим.
Пояснение
Агент добавляет файл правил к каждому запросу: договорённости группы не повторяются вручную.
Важно
Файл игнорирования исключает из передачи модели пароли, токены, персональные данные и неопубликованные сырые данные: отправленное вернуть невозможно.
Изложение. Зрелые инструменты читают из репозитория файл с правилами, описывающий, как принято писать код в проекте; агент добавляет его к каждому запросу, и повторять одно и то же не приходится. Сюда записываются договорённости группы: версия языка и стиль кода, система единиц, приёмы обработки массивов, требование сопровождать код тестом, запрет на фиксацию данных экспериментов.
Парным механизмом является файл игнорирования по образцу .gitignore. В него заносится всё, что не должно передаваться в модель: файлы с паролями и токенами, персональные данные, неопубликованные сырые данные экспериментов и материалы, закрытые соглашением с институтом. Отправленное вернуть невозможно, а скомпрометированный токен придётся перевыпускать.

MCP:
подключение инструментов
Без протокола: интеграция для каждой пары
Редактор
Агент
Чат
База данных
Вики группы
Архив установки
С MCP: одна реализация инструмента для всех клиентов
MCP
Редактор
Агент
Чат
База данных
Вики группы
Архив установки
Для физика
MCP-сервер к архиву телеметрии установки позволяет спросить у агента, что происходило с током в магнитах в ночь неудачного запуска.
Изложение. Model Context Protocol (MCP) — открытый протокол, предложенный Anthropic в конце 2024 года и принятый остальными участниками отрасли. Инструментов, нужных агенту, много: база данных, система управления задачами, архив системы управления установкой, документация в вики. Клиентов, которым нужен такой доступ, тоже много. Без общего протокола пришлось бы писать интеграцию для каждой пары «клиент — инструмент», и число таких пар растёт как произведение двух растущих списков. MCP вводит единый интерфейс: инструмент, написанный один раз в виде MCP-сервера, доступен любому клиенту, поддерживающему протокол.
Для физиков: MCP-сервер, обращающийся к архиву телеметрии установки, позволяет спрашивать у агента, что происходило с током в магнитах в ночь неудачного запуска, вместо того чтобы каждый раз заново писать разбор журналов.

Меры
предосторожности
01
Только под контролем версий
всё сделанное агентом видно в git diff и откатывается одной командой
02
Чтение перед принятием
отказаться от непонятной правки дешевле, чем впоследствии искать в ней ошибку
03
Мелкие шаги
результат задачи «вынеси в функцию и добавь тест» вычитывается, задачи «перепиши модуль» — нет
04
Разрушительные команды — за человеком
удаление файлов, git push, отправка данных наружу
05
Ответственность на разработчике
автор кода — тот, кто поставил под ним коммит
Изложение. Пять правил работы с агентами действуют с первого дня. Всё, сделанное агентом, должно быть видно в git diff и откатываться одной командой, поэтому агент работает только в репозитории под контролем версий. Непонятную правку дешевле отвергнуть, чем впоследствии искать в ней ошибку. Задачи ставятся мелкими шагами: результат задачи «перепиши весь модуль» невозможно вычитать в разумное время, а задача «вынеси этот кусок в функцию и добавь тест» проверяется легко. Удаление файлов, git push и отправка чего-либо наружу остаются решением человека, а не агента. Автором кода считается человек, поставивший под ним коммит: ссылка на то, что так предложил ассистент, не принимается ни при ревью, ни в статье.

GitHub
Copilot
Плагин к редактору, дописывающий код по контексту всего файла. Первая версия вышла в 2021 году, на полтора года раньше ChatGPT.
Под тем же названием сегодня существуют чат по проекту, агентный режим, агент для командной строки и ревью pull request.
Для физика
Начинать лучше с автодополнения: оно требует меньше всего доверия к модели.
Подключение
01
Аккаунт на GitHub
02
Расширение «GitHub Copilot» в VS Code
03
Вход через GitHub по запросу расширения
04
Student Developer Pack на education.github.com: полный тариф вместо бесплатного
Изложение. Для студента наиболее простым началом является плагин к редактору. GitHub Copilot, созданный компанией GitHub совместно с OpenAI, работает как автодополнение, видящее контекст всего файла, а не только набираемую строку; первая версия вышла в 2021 году, на полтора года раньше ChatGPT. Под тем же названием сегодня существуют чат по проекту, агентный режим, агент для командной строки и автоматическое ревью pull request, то есть все три формы инструментов.
Бесплатный тариф предоставляется любому владельцу аккаунта GitHub и ограничен числом автодополнений и запросов в чат за месяц; студенту, оформившему Student Developer Pack, предоставляется полный тариф. Для подключения в VS Code устанавливается расширение «GitHub Copilot» и выполняется вход через GitHub.
Начинать лучше с автодополнения: оно требует меньше всего доверия к модели, а к остальным формам можно перейти после того, как выработан навык чтения предложенного кода.

Приёмы
работы
Комментарий задаёт намерение, ассистент предлагает продолжение (пример из главы книги):
# Напиши функцию для расчёта среднего значения списка
def calculate_average(numbers):
    return sum(numbers) / len(numbers) if numbers else 0
Пояснение
Управление ассистентом возможно только через контекст: открытый файл, соседние вкладки и комментарии разработчика.
01
Точная формулировка задачи в комментарии
02
Чтение предложения целиком: пустой список, деление на ноль
03
Проверка тестом, а не взглядом
04
Передача шаблонной работы: аргументы, форматы, графики
05
Рассмотрение не только первого варианта
Изложение. Управление ассистентом возможно только через контекст, поступающий модели на вход: открытый файл, соседние вкладки и комментарии разработчика. Комментарий с намерением задаёт задачу, и ассистент предлагает продолжение; в примере из главы книги учтён граничный случай пустого списка, и именно такие случаи проверяются при чтении.
Пять рабочих привычек: точная формулировка задачи; чтение предложения целиком с вниманием к граничным случаям — пустому списку, делению на ноль, отсутствующему файлу; проверка коротким тестом на паре значений вместо проверки взглядом; передача ассистенту шаблонной работы — разбора аргументов командной строки, чтения форматов данных, однотипных графиков; рассмотрение не только первого варианта.
Польза на этапе обучения складывается из трёх составляющих: не требуется каждый раз искать порядок аргументов в документации, работа с пустым файлом начинается с предложенной заготовки, а предложения показывают, как принято писать на плохо знакомом языке. Всё это работает только при условии, что предложенное читается: предложение, принятое без чтения, приходится отлаживать позже.

Демонстрация:
ассистент в редакторе
01
Файл с константой g и комментарием-задачей
02
Предложение ассистента
03
Чтение: радианы, g, угол 90°
04
Тест: v0 = 10 м/с, 45° → 10,19 м
05
Чат: объяснение ошибки по трейсбеку
Проверка
Дальность при v0 = 10 м/с и 45° равна v0²/g ≈ 10,19 м; предложение принимается только после этого теста.
VS Code с расширением GitHub Copilot — показ вживую
import math
 
g = 9.81  # м/с²
 
# Дальность полёта тела, брошенного
# под углом angle (градусы) со скоростью
# v0 (м/с) с поверхности земли
def flight_range(v0, angle):
 
 
def test_flight_range():
    assert abs(flight_range(10, 45) - 10.19) < 0.01
Демонстрация. Показ выполняется вживую в VS Code с расширением GitHub Copilot. В файле заданы константа g и комментарий с задачей: дальность полёта тела, брошенного под углом к горизонту. После строки def ассистент предлагает тело функции серым текстом. До принятия предложения проверяются перевод градусов в радианы, используемое значение g и поведение при угле 90°. Затем запускается тест: при v0 = 10 м/с и угле 45° дальность равна v0²/g ≈ 10,19 м. Во второй части показа в чат передаётся трейсбек целиком, например от вызова со строкой вместо числа (TypeError), и ассистенту поручается объяснить причину.
Предложение модели каждый раз разное, поэтому на показе проверяется результат, а не совпадение с заготовкой.

Типичные ошибки
ассистента
01
Неэффективность
лишний проход или лишняя копия: незаметно на учебных объёмах, мешает на рабочих
02
Устаревшие приёмы
старого кода в обучающих данных больше, чем свежего; сверка — с документацией
03
Выдумывание
несуществующие методы и аргументы; неверная формула молча возвращает правдоподобное число
Пояснение
Помогает привычка запускать написанное: вызов придуманного метода сразу завершается ошибкой, а неверную формулу выявляет тест.
Изложение. Ошибки ассистента делятся на три вида, и все три обнаруживаются чтением и запуском. Наиболее безобидна неэффективность: предложение решает задачу, но лишним проходом или лишней копией; на учебных объёмах это незаметно, на рабочих начинает мешать. Второй вид — устаревшие подходы: в обучающих данных старого кода больше, чем свежего, поэтому ассистент предлагает приёмы, от которых в библиотеке уже отказались. Наиболее опасно выдумывание: модель уверенно называет библиотеки, методы и аргументы, не существующие в природе, и выглядит это так же, как верный ответ. Метод, придуманный моделью, приводит к ошибке при первом же вызове, а неверная формула молча возвращает правдоподобное число — её выявляет только тест.

ИИ в учёбе и
науке
Порядок освоения — от задач, где ошибку легко заметить:
01
Шаблонный код: форматы данных, конвертеры
02
Объяснение чужого кода
03
Документация и тесты к работающему коду
04
Отладка по трейсбеку целиком
05
Автоматизация рутины вокруг расчётов
Важно
Правило курса: каждая сданная строка понятна студенту и объясняется на защите; без объяснения задание не засчитывается.
Для физика
Физические формулы и численные схемы у ассистента без проверки не берутся: ошибка в коэффициенте не остановит программу, но испортит расчёт.
Изложение. Применять ИИ при выполнении заданий курса допускается при одном условии: студент обязан понимать каждую сдаваемую строку и уметь её объяснить. На защите задания будет задан вопрос, почему здесь сделано так; отсутствие объяснения означает, что задание не засчитано, кем бы ни была написана строка.
В научной работе начинать целесообразно с задач, в которых ошибку легко заметить, постепенно расширяя область применения: шаблонный код (разбор форматов данных, переименование файлов, конвертеры), объяснение скрипта, доставшегося от предшественника, документация и тесты к собственному работающему коду, отладка с трейсбеком целиком, автоматизация рутины вокруг расчётов — запуск серий, сбор результатов, сводные графики.
Модель сильна настолько, насколько задача похожа на встречавшееся в обучающих данных: она может неожиданно скомбинировать известные приёмы, но нового метода не изобретёт. Постановка задачи, выбор модели явления и физическая интерпретация результата остаются за исследователем.

Основы GitСнимки, три состояния, базовый цикл
04
ИИ в разработке
Устройство модели
Инструменты ИИ
Основы Git
Ветки и слияние
Совместная работа
Изложение. Вторая половина лекции посвящена системе контроля версий Git. Четвёртая часть посвящена её устройству и базовому циклу работы: настройке, фиксации изменений, просмотру истории и исключению файлов из репозитория.

Назначение
контроля версий
Каталог курсовой работы с расчётами:
processing.py
processing_new.py
processing_final.py
processing_final_v2.py
thesis_final_v2_FINAL(2).py
thesis_final_v2_FINAL(2)_fixed_mass.py
Каким из файлов построен третий рисунок статьи, через месяц не помнит никто, включая автора.
01
История вместо множества файлов
один processing.py, все прошлые версии — в Git; любые две сравниваются построчно
02
Воспроизводимость расчётов
хеш коммита рядом с результатом позволяет восстановить код, построивший график
03
Совместная работа
изменения нескольких человек объединяются; видно, кто, что и зачем изменил
Пояснение
Репозиторий на сервере служит и резервной копией: выход из строя диска перестаёт быть катастрофой.
Изложение. Git — распределённая система контроля версий: она хранит историю изменений файлов, позволяет вернуться к любой прошлой версии и объединяет работу нескольких человек над одним проектом. Для научной работы Git является таким же обязательным инструментом, как Python или LaTeX.
Типичный каталог курсовой работы с расчётами содержит шесть версий одного скрипта. Через месяц требуется перегенерировать третий рисунок для статьи, и никто, включая автора, не помнит, каким из файлов он построен; при этом «финальная» версия даёт другой хвост распределения, поскольку правка константы, сделанная в процессе работы, осталась неучтённой.
Контроль версий решает три проблемы. В проекте хранится один processing.py, а все его прошлые версии остаются в Git. Каждое состояние проекта имеет уникальный идентификатор — хеш коммита; запись «Рисунок 3 построен на коммите a3f2c17» и является воспроизводимостью. Git объединяет изменения нескольких человек и показывает, кто, что и зачем изменил, поэтому пересылать архивы code_v7_new.zip по почте не требуется.

Снимки, а не
различия
a4e6e8f
Добавлен расчёт энергии пучка
processing.py — новый
cdf6ff6
Добавлено описание проекта
processing.py — ссылка
README.md — новый
73315e0
Дополнено описание проекта
processing.py — ссылка
README.md — изменён
родитель
родитель
Пояснение
Коммит — снимок всего проекта с автором, датой, сообщением и ссылкой на родителя. Объект адресуется хешем SHA-1; в командах достаточно первых 6–8 символов.
Для физика
Хеш рядом с результатом делает расчёт воспроизводимым: «Рисунок 3 построен на коммите a3f2c17».
Изложение. Устройство Git основано на трёх идеях, из которых выводится почти всё поведение команд. Первая: Git хранит не патчи к предыдущей версии, а снимки. Каждый коммит представляет собой состояние всего проекта в момент фиксации плюс метаданные: автор, дата, сообщение и ссылка на родительский коммит. Неизменившиеся файлы не копируются: коммит ссылается на уже сохранённые объекты, и репозиторий не разрастается. На схеме файл processing.py сохранён один раз, а два следующих коммита ссылаются на тот же объект.
Каждый объект адресуется хешем SHA-1, строкой вида a3f2c17b… из git log; в командах достаточно первых 6–8 символов. Хеши на схеме взяты из записи демонстрации веток и слияния.

Три
состояния
Рабочий каталог
обычные файлы, которые правит разработчик
Индекс
изменения, отобранные в следующий коммит
Репозиторий .git
все зафиксированные снимки проекта
git add
git commit
git restore
git restore --staged
Пояснение
Индекс позволяет зафиксировать часть накопленных правок: исправление формулы одним коммитом, эксперименты с графиками — другим.
Изложение. Вторая идея: файлы проекта находятся в трёх зонах. Рабочий каталог содержит обычные файлы, которые редактирует разработчик. Индекс (staging area) — промежуточная область перед коммитом: командой git add в него помещаются изменения, которые войдут в следующий снимок. Репозиторий находится в скрытом каталоге .git и хранит все коммиты; git commit фиксирует содержимое индекса как новый снимок.
Обратные стрелки соответствуют отмене: git restore --staged возвращает в индекс версию файла из последнего коммита, оставляя правки в рабочем каталоге, а git restore возвращает файл рабочего каталога к версии из индекса, и правки, не добавленные в индекс, при этом исчезают.
Индекс кажется избыточным до тех пор, пока не потребуется зафиксировать часть накопленных правок: исправление формулы одним коммитом, эксперименты с графиками — другим.

Разовая
настройка
Автор коммитов и имя главной ветки:
git config --global user.name "Lev Landau"
git config --global user.email "l.landau@g.nsu.ru"
git config --global init.defaultBranch main
Новый репозиторий или копия существующего:
git init
git clone https://github.com/nsu-phys/beam-dynamics.git
Пояснение
Имя и почта попадают в каждый коммит; main — имя главной ветки, принятое на GitHub.
Пояснение
git init создаёт в текущем каталоге скрытый каталог .git; git clone копирует проект вместе со всей историей.
Изложение. Перед первым коммитом Git настраивается один раз на каждой машине: задаются имя и почта автора, попадающие в каждый коммит, и имя главной ветки main, принятое на GitHub. Ключ --global записывает настройки в файл пользователя, поэтому они действуют во всех его репозиториях.
Работа с проектом начинается одним из двух способов. Команда git init превращает текущий каталог в репозиторий, создавая в нём скрытый каталог .git. Команда git clone копирует существующий проект с сервера вместе со всей историей и сразу запоминает адрес, откуда выполнено копирование.

Базовый
цикл


КомандаНазначение
git statusсостояние всех трёх зон и следующий шаг
git add processing.pyдобавление файла в индекс
git add -pотбор изменений по частям
git commit -m "…"фиксация снимка с сообщением
git log --onelineистория, по строке на коммит
git log --oneline --graph --allвесь граф с ветками
git diffизменения, ещё не добавленные в индекс
git diff --stagedизменения, которые войдут в коммит
git show a3f2c17изменения, внесённые коммитом

Пояснение
git status вызывается до и после каждой операции: он показывает состояние зон и подсказывает следующую команду.
Для физика
git diff a3f2c17 HEAD -- processing.py показывает, как файл изменился со времени старого коммита.
Изложение. В этом цикле проходит почти вся повседневная работа. Команда git status показывает состояние всех трёх зон и подсказывает следующий шаг; на первых порах её имеет смысл вызывать до и после каждой операции. git add помещает в индекс файл или каталог целиком, а git add -p позволяет отобрать изменения по частям. git commit -m фиксирует снимок с сообщением.
Для просмотра истории служит git log: с ключом --oneline — по строке на коммит, с ключами --graph --all — весь граф с ветками. git diff показывает изменения, ещё не добавленные в индекс, git diff --staged — то, что уже в индексе и войдёт в коммит, git show — что сделал конкретный коммит.
Для физиков: git diff со старым хешем и именем файла показывает, как изменилась обработка со времени расчёта, результат которого требуется воспроизвести.

Команда	Назначение
git status	состояние всех трёх зон и следующий шаг
git add processing.py	добавление файла в индекс
git add -p	отбор изменений по частям
git commit -m "…"	фиксация снимка с сообщением
git log --oneline	история, по строке на коммит
git log --oneline --graph --all	весь граф с ветками
git diff	изменения, ещё не добавленные в индекс
git diff --staged	изменения, которые войдут в коммит
git show a3f2c17	изменения, внесённые коммитом

Демонстрация:
первый репозиторий
01
Имя, почта и главная ветка main
02
git init в новом каталоге beam
03
git status: неотслеживаемый файл
04
git add и первый коммит
05
Правка константы и git diff
06
Второй коммит и git log --oneline
Что наблюдается
git diff показывает прежнюю строку со знаком «−» и новую со знаком «+»; git log выводит оба коммита с сокращёнными хешами.
root@lab — запись со стенда
Демонстрация. Сначала задаются имя и почта автора и имя главной ветки. В новом каталоге beam выполняется git init и создаётся файл processing.py с константой энергии пучка. git status сообщает, что коммитов ещё нет, а файл не отслеживается, и подсказывает команду git add. После git add и git commit появляется первый коммит; Git выводит его сокращённый хеш и отмечает, что это корневой коммит (root-commit).
Затем константа меняется с 1.0 на 1.2, и git diff показывает прежнюю строку со знаком «−» и новую со знаком «+». Второй коммит фиксирует правку с сообщением, объясняющим её причину. git log --oneline выводит оба коммита, новый сверху; пометка HEAD -> main означает, что текущее положение — ветка main.

.gitignore:
исключение файлов
# байткод и кеши Python
__pycache__/
*.pyc
.ipynb_checkpoints/
# виртуальное окружение
.venv/
# данные измерений и результаты расчётов
data/
*.h5
*.root
*.npz
# тяжёлые артефакты: чекпойнты, дампы
checkpoints/
*.ckpt
# служебные файлы редакторов и ОС
.idea/
.vscode/
.DS_Store
# служебные файлы LaTeX
*.aux
*.synctex.gz
Важно
В репозитории хранится написанное вручную — код, тексты, конфигурации — и не хранится измеренное на установке или полученное расчётом. Сам .gitignore фиксируется в репозитории: правила общие для группы.
Изложение. Git отслеживает только явно добавленные файлы, однако git status перечисляет всё содержимое каталога, от кешей Python до гигабайтных файлов с данными. Файл .gitignore в корне проекта задаёт, что нужно игнорировать. На слайде приведена заготовка для научного проекта: байткод и кеши Python, виртуальное окружение, данные измерений и результаты расчётов, тяжёлые артефакты, служебные файлы редакторов, операционной системы и LaTeX.
Критерий следующий: в репозитории хранится написанное вручную (код, тексты, конфигурации) и не хранится измеренное на установке или полученное расчётом. Сам .gitignore фиксируется в репозитории, поскольку правила исключений являются общими для всей группы.

Демонстрация:
.gitignore
01
Каталоги data и __pycache__ с файлами
02
git status --short: два неотслеживаемых каталога
03
Два правила в .gitignore
04
В списке — только .gitignore
05
Коммит .gitignore и чистый рабочий каталог
Что наблюдается
После записи правил git status перестаёт показывать данные и кеши, а сам .gitignore попадает в репозиторий.
root@lab — запись со стенда
Демонстрация. Исходное состояние — репозиторий beam с одним коммитом, содержащим processing.py. В нём появляются файл данных data/run1.h5 и байткод в __pycache__. Краткий вывод git status --short помечает неотслеживаемые каталоги знаками «??». После записи двух правил в .gitignore данные и кеш из списка исчезают, а неотслеживаемым остаётся только сам .gitignore. Он фиксируется коммитом, после чего git status сообщает, что рабочий каталог чист.

Ветки и слияниеГраф коммитов, merge, конфликты
05
ИИ в разработке
Устройство модели
Инструменты ИИ
Основы Git
Ветки и слияние
Совместная работа
Изложение. Пятая часть посвящена третьей идее устройства Git — графу коммитов — и работе с ветками: созданию, слиянию и разрешению конфликтов.

Граф
коммитов
A
B
C
F
D
E
main
HEAD
fft-filter
01
Коммит
снимок со ссылкой на родителя; у коммита слияния F два родителя
02
Ветка
подвижный указатель на коммит, файл размером 41 байт внутри .git
03
HEAD
текущее положение в графе, обычно указывает на ветку
Изложение. Третья идея: каждый коммит ссылается на родителя, поэтому история образует направленный ациклический граф (DAG). Пока над проектом работает один человек, граф вырождается в цепочку; ветки заставляют его ветвиться, слияния — сходиться. На схеме от коммита B ответвлена ветка fft-filter с коммитами D и E, а коммит слияния F объединяет её с основной линией.
Ветка — подвижный указатель на коммит, файл размером 41 байт внутри .git. Копия проекта при создании ветки не создаётся, поэтому ветки создаются мгновенно и без затрат. HEAD указывает на текущее положение в графе.

Работа с
ветками
Для проверки другого алгоритма фильтрации сигнала не требуется комментировать половину файла: эксперимент ведётся в ветке, названной по его сути.
git branch                  # список веток, звёздочка — текущая
git switch -c fft-filter    # создание ветки и переход на неё
# ...правки и коммиты в ветке...
git switch main             # возврат на main и прежний вид файлов
Пояснение
git switch появился в Git 2.23; в старых руководствах те же действия выполняются командами git checkout -b fft-filter и git checkout main.
Важно
Если незафиксированные правки конфликтуют с содержимым другой ветки, git switch откажется переключаться; поэтому перед переключением правки фиксируются коммитом.
Изложение. Ветка позволяет экспериментировать, не затрагивая работающий код: для проверки другого алгоритма фильтрации сигнала не требуется комментировать половину файла, достаточно создать ветку, названную по сути эксперимента. git branch выводит список веток и отмечает текущую звёздочкой, git switch -c создаёт ветку и переходит на неё. После возврата командой git switch main файлы рабочего каталога мгновенно принимают тот вид, который они имеют в main.
Команда git switch появилась в Git 2.23; в старых руководствах те же действия выполняются командами git checkout -b и git checkout. Если незафиксированные правки конфликтуют с содержимым другой ветки, Git откажется переключаться, поэтому перед переключением правки фиксируются коммитом.

Слияние
веток
Fast-forward
A
B
D
E
main до
main
fft-filter
main без изменений: перемещение указателя вперёд, без новых коммитов
Коммит слияния
A
B
C
F
D
E
main
main с изменениями: коммит слияния F с двумя родителями
git switch main
git merge fft-filter        # слияние fft-filter с main
git branch -d fft-filter    # удаление ненужного указателя
Изложение. Когда эксперимент в ветке завершён успешно, ветка вливается обратно: на main выполняется git merge fft-filter, после чего ненужный указатель удаляется командой git branch -d.
Возможны два случая. Если main с момента ветвления не изменялся, Git передвигает указатель вперёд (fast-forward), и новых коммитов не появляется. Если изменялся, создаётся коммит слияния с двумя родителями, и граф сходится в одну линию. Удаление ветки после слияния не удаляет ни одного коммита: исчезает только указатель, а коммиты остаются в истории main.

Демонстрация:
ветки и слияние
01
Ветка fft-filter и коммит с фильтром
02
Возврат на main и правка описания
03
git merge: коммит слияния
04
git log --oneline --graph --all
05
Удаление указателя fft-filter
Что наблюдается
Граф в выводе git log повторяет схему: две линии расходятся после общего коммита и сходятся в коммите слияния.
root@lab — запись со стенда
Демонстрация. Исходное состояние — репозиторий beam с двумя коммитами: расчётом энергии пучка и описанием проекта в README.md. В нём создаётся ветка fft-filter, и в неё фиксируется заготовка фильтра на основе быстрого преобразования Фурье. После возврата на main правится описание проекта, и правка фиксируется коммитом уже в main: ветви разошлись. Команда git merge создаёт коммит слияния и сообщает, что слияние выполнено стратегией ort. В выводе git log --oneline --graph --all псевдографика повторяет схему со слайда: линии расходятся после общего коммита и сходятся в коммите слияния. git branch -d удаляет указатель fft-filter и печатает хеш, на который он указывал.

Конфликты
слияния
В двух ветках изменена одна и та же строка integrator.py:
<<<<<<< HEAD
dt = 1e-12  # шаг для жёсткой задачи
=======
dt = 5e-12  # компромисс между точностью и скоростью
>>>>>>> step-tuning
Пояснение
Конфликт является не ошибкой, а вопросом к разработчику: Git не выбирает вариант самостоятельно.
01
Выбор верного варианта или объединение обоих
02
Удаление маркеров
03
git add integrator.py
04
git commit: завершение слияния
Важно
git merge --abort откатывает слияние целиком, пока оно не завершено коммитом.
Изложение. Если в двух ветках изменены одни и те же строки, Git не выбирает версию самостоятельно и вставляет в файл маркеры, размечающие оба варианта: между <<<<<<< HEAD и ======= находится версия текущей ветки, между ======= и >>>>>>> — версия вливаемой.
Конфликт является не ошибкой, а вопросом к разработчику. Файл редактируется: остаётся правильный вариант или комбинация обоих, маркеры удаляются. Затем git add помечает конфликт разрешённым, а git commit завершает слияние. Если принято решение отказаться от слияния, вместо этих двух команд выполняется git merge --abort; после git commit этой команде отменять уже нечего.
Чем мельче коммиты и чем чаще выполняется слияние веток, тем реже возникают конфликты и тем проще они разрешаются.

Демонстрация:
конфликт
01
Ветка step-tuning: шаг 5e-12
02
main: та же строка, шаг 1e-12
03
git merge: конфликт в integrator.py
04
Маркеры в файле
05
Выбор варианта, git add, git commit
06
Граф с коммитом слияния
Что наблюдается
Git останавливает слияние и ждёт решения разработчика; коммит слияния фиксирует это решение.
root@lab — запись со стенда
Демонстрация. Исходное состояние — новый репозиторий beam с одним коммитом, содержащим integrator.py со строкой dt = 1e-12. В ветке step-tuning шаг интегрирования увеличивается до 5e-12, а в main та же строка получает другой комментарий при шаге 1e-12. git merge сообщает о конфликте содержимого в integrator.py и останавливается. cat показывает маркеры: версия HEAD, то есть main, сверху, версия step-tuning снизу. Файл записывается заново с выбранным вариантом, git add помечает конфликт разрешённым, а git commit --no-edit завершает слияние со стандартным сообщением Merge branch 'step-tuning'. Граф в git log показывает коммит слияния с двумя родителями.

Совместная работаУдалённые репозитории, fork, исправление ошибок
06
ИИ в разработке
Устройство модели
Инструменты ИИ
Основы Git
Ветки и слияние
Совместная работа
Изложение. Шестая часть посвящена удалённым репозиториям, схеме fork и pull request, хорошим практикам и исправлению ошибок. В завершение части рассматривается порядок работы с ИИ-агентом в репозитории.

Удалённые
репозитории
Локальный репозиторий разработчика
Удалённый репозиторий: GitHub, GitLab, машина группы
Локальный репозиторий коллеги
git push
git pull
git push
git pull
git remote -v                   # список удалённых репозиториев
git remote add origin <адрес>   # привязка к серверу
git push -u origin main         # отправка main и запоминание связки
git fetch                       # загрузка коммитов без изменения файлов
git pull                        # fetch и слияние с текущей веткой
Пояснение
Ритм работы: в начале сеанса git pull, по окончании git push. Чем чаще синхронизация, тем меньше конфликтов.
Изложение. Пока коммиты находятся только на машине разработчика, нет ни резервной копии, ни совместной работы. Удалённый репозиторий (remote) хранит копию проекта на GitHub, GitLab или на институтской машине группы. После git clone в списке удалённых репозиториев уже есть origin — адрес, откуда выполнено копирование; локальный репозиторий привязывается к созданному на сервере командой git remote add.
git push -u origin main отправляет ветку main на сервер, а ключ -u запоминает связку, после чего достаточно git push. git fetch безопасен всегда: он лишь обновляет локальные сведения о сервере, после чего коммиты коллег можно изучить командой git log origin/main. git pull объединяет fetch с немедленным слиянием. Типовой ритм работы: в начале сеанса выполняется git pull, по окончании — git push.

Демонстрация:
удалённый репозиторий
01
Голый репозиторий ~/server/beam.git в роли сервера
02
git remote add и git push -u
03
Клон коллеги: правка и git push
04
git fetch: коммит коллеги в origin/main
05
git pull: перемотка вперёд
Что наблюдается
После git fetch рабочие файлы не изменились, а коммит коллеги уже виден в origin/main; git pull переносит его в main.
root@lab — запись со стенда
Демонстрация. Исходное состояние — репозиторий beam с одним коммитом, содержащим processing.py. Роль сервера играет «голый» репозиторий без рабочего каталога, созданный командой git init --bare на той же машине; с GitHub всё происходит так же, отличается только адрес. Репозиторий beam привязывается к нему как origin, и git push -u отправляет ветку main. Коллега клонирует репозиторий в отдельный каталог, выносит число частиц в константу, фиксирует правку и отправляет её на сервер.
В исходном репозитории git fetch скачивает новый коммит, не трогая рабочие файлы; git log main..origin/main показывает коммиты, которые есть на сервере, но ещё не влиты в main. git pull выполняет слияние; поскольку main с тех пор не изменялся, указатель передвигается вперёд (Fast-forward).

Fork и
pull request
01
Fork
кнопкой на GitHub создаётся личная копия репозитория
02
Клон и ветка
форк клонируется, в новой ветке фиксируется исправление
03
Push в форк
ветка отправляется в личную копию
04
Pull request
предложение включить коммиты: описание и дифф
05
Ревью
владельцы пишут замечания, новые коммиты обновляют PR
06
Слияние
одобренный PR вливается в основной репозиторий
Пояснение
По этой схеме работает весь open source: исправление одной строки в документации scipy проходит тот же путь. Задания курса сдаются так же.
Изложение. В чужой репозиторий, будь то библиотека наподобие numpy или проект соседней лаборатории, напрямую отправлять коммиты нельзя. Стандартный механизм состоит из шести шагов. Кнопкой Fork на GitHub создаётся личная копия репозитория. Форк клонируется, создаётся ветка, фиксируется исправление, и ветка отправляется в форк. Затем открывается pull request — предложение включить коммиты в основной репозиторий, сопровождаемое описанием и диффом. Владельцы читают код и пишут замечания; автор дополняет ветку новыми коммитами, и PR обновляется автоматически. Одобренный PR вливается в основной репозиторий.
По этой схеме работает весь open source и заметная часть открытой науки. Внутри своей группы обычно отправляют коммиты в общий репозиторий, однако правки всё равно оформляются ветками и PR ради ревью. Задания курса сдаются так же: форком репозитория задания.

Хорошие
практики
01
Атомарные коммиты
одно логическое изменение на коммит; проект запускается в каждом коммите
02
Сообщение с причиной изменения
заголовок до 50 символов, не более 72; что изменилось, покажет дифф
03
Большие файлы вне истории
сырые данные, HDF5, ROOT, модели — в Git LFS или DVC
04
Секреты вне репозитория
пароль, попавший в историю, удалить почти невозможно
Неинформативно
fix · fix2 · wip · изменил всякое
Информативно
Увеличен шаг сетки: старый не помещался в память на кластере
Изложение. Коммиты делаются атомарными, по одному логическому изменению: «Исправлена нормировка спектра» и «Добавлен скрипт карты магнитного поля» — два коммита, а не один «изменил всякое». Атомарный коммит можно понять, откатить или перенести целиком; кроме того, желательно, чтобы проект в каждом коммите хотя бы запускался, тогда любая точка истории пригодна для поиска момента, в который возникла ошибка.
Сообщение коммита объясняет, зачем сделано изменение: что изменилось, и так покажет дифф. По общепринятому соглашению заголовок укладывается в 50 символов и не превышает 72. По истории из fix, fix2 и wip через полгода восстановить ход работы уже невозможно.
Git создан для текста и плохо работает с большими бинарными файлами: каждый попавший в историю гигабайт останется в ней навсегда. Для версионирования больших файлов рядом с кодом существуют Git LFS и DVC. Пароли, токены и ключи фиксировать недопустимо: удалить секрет из истории почти невозможно, а клоны коллег успевают разойтись.

Исправление
ошибок

СитуацияКоманда
Испорченный файлgit restore file.py — потеря правок
Лишнее в индексеgit restore --staged file.py
Опечатка в сообщении или забытый файлgit commit --amend — до отправки
Отмена коммита с сохранением измененийgit reset --soft HEAD~1 — правки в индексе
Удаление последнего коммита с правкамиgit reset --hard HEAD~1 — потеря правок
Отмена отправленного коммитаgit revert a3f2c17 — обратный коммит
Смена ветки при незаконченных правкахgit stash, затем git stash pop
Пропавшие коммитыgit reflog и git reset --hard <хеш>
Важно
git reset --hard без предупреждения уничтожает незафиксированную работу: перед ним вызывается git status. Историю, уже отправленную коллегам, не переписывают.
Изложение. Зафиксированное в коммите почти невозможно потерять: Git скорее сохранит лишнее, чем удалит нужное. В таблице собраны типовые ситуации. git restore возвращает файл к версии из индекса, и правки, не добавленные в индекс, при этом исчезают. git commit --amend исправляет последний коммит, пока он не отправлен на сервер. git reset --soft HEAD~1 отменяет последний коммит, оставляя его изменения в индексе, а git reset --hard HEAD~1 удаляет его вместе с изменениями. Уже отправленный коммит отменяется командой git revert, создающей новый коммит с обратным изменением, без переписывания истории. git stash прячет незаконченные правки, git stash pop возвращает их.
Если коммиты пропали, git reflog показывает журнал последних положений HEAD. Коммит, недостижимый ни через ветку, ни через тег, хранится в журнале около месяца, после чего удаляется сборщиком мусора, поэтому этот приём действует ограниченное время.
Историю переписывают reset, --amend и rebase; в ветках, уже отправленных на сервер и полученных коллегами, их не применяют: коллегам придётся разбираться с разошедшимся графом.

Ситуация	Команда
Испорченный файл	git restore file.py — потеря правок
Лишнее в индексе	git restore --staged file.py
Опечатка в сообщении или забытый файл	git commit --amend — до отправки
Отмена коммита с сохранением изменений	git reset --soft HEAD~1 — правки в индексе
Удаление последнего коммита с правками	git reset --hard HEAD~1 — потеря правок
Отмена отправленного коммита	git revert a3f2c17 — обратный коммит
Смена ветки при незаконченных правках	git stash, затем git stash pop
Пропавшие коммиты	git reflog и git reset --hard <хеш>

Демонстрация:
исправление ошибок
01
Отладочная строка и git restore
02
Опечатка в сообщении и --amend
03
git reset --soft: изменения снова в индексе
04
git reset --hard HEAD~1: удаление коммита
05
git reflog и возврат по HEAD@{1}
Что наблюдается
Удалённый коммит остаётся в журнале reflog и возвращается по нему; незафиксированные правки так не восстанавливаются.
root@lab — запись со стенда
Демонстрация. Исходное состояние — репозиторий beam с одним коммитом, содержащим processing.py со строкой E0 = 1.0. В processing.py дописывается отладочная строка; git status --short помечает файл буквой M, а git restore возвращает его к зафиксированной версии. Затем правка константы фиксируется с опечаткой в сообщении, и git commit --amend заменяет сообщение; хеш коммита при этом меняется, поскольку это уже другой коммит. git reset --soft HEAD~1 возвращает изменения в индекс (буква M в первой колонке), после чего коммит создаётся заново.
git reset --hard HEAD~1 удаляет последний коммит вместе с правками: в git log остаётся один коммит. git reflog показывает журнал положений HEAD, в котором удалённый коммит по-прежнему присутствует под именем HEAD@{1}, и git reset --hard HEAD@{1} возвращает историю.

Агент в
репозитории
Коммит: точка возврата
Правки агента
git diff: чтение каждой правки
Принятие: git add -p, git commit
Отказ: git restore .
Пояснение
git add -p позволяет принять часть правок агента и отвергнуть остальные.
Важно
git restore не удаляет новые файлы, созданные агентом: их перечисляет git status.
Изложение. Две половины лекции сходятся в одном порядке работы. Перед поручением агенту рабочий каталог приводится к чистому состоянию: всё нужное зафиксировано коммитом, который служит точкой возврата. Агент вносит правки, после чего git diff показывает каждую изменённую строку, и каждая из них читается. Принятые правки добавляются в индекс, при необходимости по частям командой git add -p, и фиксируются коммитом с сообщением, объясняющим изменение. Отвергнутые правки отменяются командой git restore .; новые файлы, созданные агентом, эта команда не удаляет, их перечисляет git status.
Такой порядок делает работу агента наблюдаемой и обратимой: всё, что он сделал, видно в git diff и git status, а правки отслеживаемых файлов отменяются одной командой.

Заключение01
Языковая модель порождает правдоподобное продолжение, а не истинное: результат проверяется тестом и документацией.
02
Ощущение ускорения не заменяет измерения; выигрыш тем больше, чем менее знакома задача.
03
Качество ответа определяется контекстом: файлом, трейсбеком, фрагментом документации.
04
Git хранит снимки проекта, а ветки являются лёгкими указателями, поэтому эксперименты ведутся в ветках.
05
Агент работает только в репозитории под контролем версий: каждая правка видна в git diff и отменяется.
Ответственность за код несёт тот, кто поставил под ним коммит.
Изложение. Из первой половины лекции следуют три вывода. Языковая модель порождает правдоподобное продолжение, а не истинное, поэтому всё, что она выдала, проверяется тестом и документацией. Ощущение ускорения не заменяет измерения, а выигрыш от ассистента тем больше, чем менее знакома разработчику задача. Качество ответа определяется не формулировкой, а контекстом, который видит модель.
Из второй половины следуют ещё два. Git хранит снимки проекта, а ветки являются лёгкими указателями, поэтому любой эксперимент ведётся в ветке. Агент допускается только в репозиторий под контролем версий, где каждая его правка видна в git diff и отменяется одной командой.
Следующая лекция, «Как организован Linux», начинается с процесса загрузки системы.

Домашнее заданиеГенератор текста на цепи Маркова
01
Программа с двумя аргументами: имя файла с корпусом и длина результата в словах
02
Тексты на двух корпусах разных авторов, не менее ста тысяч слов каждый
03
Сравнение цепочек по два и по три слова: изменение связности и его причина
04
Случай слова, встретившегося один раз в самом конце текста
Сдача через Git
Форк репозитория задания, решение в отдельной ветке
Атомарные коммиты с сообщениями, объясняющими изменения
.gitignore, исключающий кеши Python и виртуальное окружение
Pull request с описанием решения
Объяснение на защите каждой строки, в том числе предложенной ассистентом
Репозиторий: github.com/phys-dev/markov-chain-task · главы «Технические основы» и «Коллекции»
Домашнее задание. Требуется реализовать на цепях Маркова генератор текста: программу, которая читает корпус, запоминает, какое слово за каким встречалось, и выдаёт новый текст. Программа принимает имя файла с исходным текстом и длину результата в словах; стартовое слово выбирается случайно среди слов с заглавной буквы. Тексты подбираются самостоятельно: подойдёт любая книга с «Проекта Гутенберг» или lib.ru при условии, что авторы различны, а объём составляет не менее ста тысяч слов. В отчёте сравниваются цепочки по два и по три слова и объясняется, что меняется в связности текста и почему, а также даётся ответ на вопрос, что произойдёт, если слово встретилось в тексте один раз и оказалось последним.
Решение сдаётся через Git по схеме со слайда о fork и pull request: форк репозитория задания, отдельная ветка, атомарные коммиты с осмысленными сообщениями, .gitignore и pull request с описанием. Пользоваться ИИ-ассистентом можно при условии, что каждая строка решения понятна автору и объясняется на защите.

Типичные
ошибки
01
Короткий корпус
на тексте в несколько тысяч слов цепочки по два-три слова почти дословно повторяют источник
02
Старт со строчной буквы
текст начинается с середины фразы
03
Один коммит на всё решение
история не показывает хода работы, откатить отдельный шаг нельзя
04
Сообщения fix и wip
из истории непонятно, что и зачем изменено
05
Кеши и окружение в коммите
__pycache__ и .venv попадают в репозиторий без .gitignore
06
Код ассистента без понимания
строка, которую автор не может объяснить, не засчитывается
Изложение. На слайде приведены ошибки, наиболее часто допускаемые при выполнении задания. На коротком тексте у большинства пар слов единственный преемник, и цепочки по два-три слова почти дословно повторяют источник, поэтому объём корпуса не меньше ста тысяч слов. Стартовое слово со строчной буквы начинает текст с середины фразы. Решение, сданное одним коммитом, не показывает хода работы и не позволяет откатить отдельный шаг; сообщения fix и wip не сообщают, что изменено. Без .gitignore в репозиторий попадают __pycache__ и виртуальное окружение. Код, предложенный ассистентом и не понятый автором, на защите не засчитывается.

Источники1
Книга курса: главы части «ИИ для разработки» и глава «Git»
phys-dev.github.io/soft-dev-book
2
Vaswani A. et al. Attention Is All You Need. – 2017
arxiv.org/abs/1706.03762
3
METR. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. – 2025
metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study
4
Stack Overflow Developer Survey 2024
survey.stackoverflow.co
5
Anthropic. Building Effective Agents. – 2024
anthropic.com/engineering/building-effective-agents
6
Model Context Protocol
modelcontextprotocol.io
7
Chacon S., Straub B. Pro Git. – 2nd ed.
git-scm.com/book/ru/v2
8
Learn Git Branching — тренажёр по веткам
learngitbranching.js.org
Изложение. Основой лекции служат главы книги курса, посвящённые ИИ в разработке и системе контроля версий Git. Архитектура трансформера описана в статье Vaswani и соавторов, данные о распространении инструментов взяты из опроса Stack Overflow 2024 года, результат о скорости работы — из эксперимента METR 2025 года. Для самостоятельного изучения агентов рекомендуется статья Anthropic «Building Effective Agents», для Git — книга Pro Git на русском языке и тренажёр Learn Git Branching, в котором ветки, merge и rebase показаны на живом графе коммитов.

Спасибо за вниманиеВопросы
phys-dev.github.io/soft-dev-book
HEAD
Изложение. Надпись на последнем слайде — HEAD, указатель на текущее положение в графе коммитов: с него начинается любая работа с репозиторием. Лекция завершается ответами на вопросы по её содержанию и по домашнему заданию.