Git для вайбкодинга – защити проект от AI-косяков

Потеряли 3 дня работы, потому что курсор решил, что ваш код — это мусор. Клод агент случайно удалил половину проекта, и вы не знаете, как вернуть её назад. Знакомо?

Тогда садитесь поудобнее. Сегодня спасаем ваши проекты от исчезновения. Здорово, вайпкодеры. Если вы всё ещё не используете Git в своих проектах, то обязательно смотрите это видео до конца или сохраняйте себе в закладки, потому что это спасёт ваш проект. Всё, как обычно, с меня годнота, с вас лайк и подписка. И мы начинаем.

Давайте разберёмся, что такое Git и зачем он вообще нужен. Git — это машина времени для вашего кода. С ним вы можете сохранять каждое изменение в проекте. В Git будет храниться последовательная история всех изменений. Что-то пошло не так, сломалась нейронка, удалила половину кода. Ничего страшного, мы просто откатываемся к нужному состоянию.

Три главные причины, почему нужно использовать Git:

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

Вторая причина — эксперименты без страха. Хотите попробовать сделать фичу, но не уверены, что получится, и боитесь сломать работающий код? Ничего страшного, создаём отдельную ветку, работаем в ней, тестируем, всё хорошо — сливаем. Что-то не получилось? Возвращаемся к рабочей ветке.

Третья причина — резервная копия в облаке. Благодаря сервисам типа GitHub, GitLab или BitBucket, мы можем хранить свои проекты вместе с историей изменений в облаке. Грубо говоря, это как Google Drive, только с историей изменений. И если, не дай бог, с вашим ноутбуком или компьютером что-то случится, то вы легко сможете восстановить проект из этого облака.

Но, по большому счёту, Git для вайпкодеров — это кнопка "Откатить изменения на стероидах", которая даёт нам гибко и просто управлять версиями нашего проекта.

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

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

Первый — это коммит. Коммит — это запись об изменениях. Вы делаете какое-то изменение, коммитите его, и это изменение сохраняется в истории изменений Git. И такая запись об изменениях называется коммитом. Делаете одно изменение — закомитили. Делаете второе изменение — закомитили. Таким образом, у нас формируется история изменений, из которой складывается конечное состояние проекта. Если в какой-то момент что-то сломалось, то мы без проблем можем откатиться к какому-то коммиту в этой цепочке изменений, в котором всё работало.

Откатываться по коммитам можно, но это не всегда удобно. Поэтому давайте разберём второй термин, и это ветки. Ветки — это как бы параллельные истории коммитов. Сначала у нас будет одна основная ветка. Обычно она называется `main` или `master`. При желании можно назвать по-другому, но лучше использовать устоявшиеся названия. Предположим, мы делали какие-то изменения, коммитили это всё в ветку `main`. Там сформировалась какая-то история этих изменений. И вот у нас есть работающая версия проекта. И это состояние находится в ветке `main`.

И тут мы захотели внедрить какие-то новые фичи или, может быть, просто поэкспериментировать с каким-то функционалом. Далеко не факт, что всё сразу заработает, особенно если предполагается большой объём работы. Но нам было бы удобно сохранять промежуточные изменения на пути к реализации этого нового функционала. Но если коммитить изменения в нашу основную ветку `main`, то есть большой шанс, что мы сломаем работающую версию проекта. Чтобы этого избежать, мы создаём новую ветку, так сказать, параллельную историю развития. При создании ветки сначала она будет полностью идентична нашей основной ветке `main`. Затем мы будем коммитить наши изменения в новую ветку, а ветка `main` останется такой же, как и была. Когда мы закончим разработку нашего нового функционала, протестируем, что всё работает, то вольём наши изменения из второй ветки в нашу основную ветку. В нашей основной ветке появятся новые изменения, и мы будем уверены, что всё работает корректно. Слияние веток называется merge. Позже мы разберём этот процесс на примерах. Если мы что-то сломаем в процессе реализации нового функционала или наш эксперимент вдруг не удался, то мы просто вернёмся к нашей основной ветке, в которой всё работает. Продолжим разработку проекта из рабочего состояния, а ветку, в которой у нас что-то не получилось, мы можем просто удалить.

Третий термин, который нам нужно знать — это репозиторий. Если по-простому, то Git repository — это папка с файлами проекта и историей изменений. Репозиторий может быть локальный на вашем компьютере и удалённый. Например, он может находиться в GitHub, GitLab, BitBucket, ну или каких-то других Git-сервисах.

Если говорить про локальный репозиторий, то по сути ваша папка с проектом после инициализации в ней Git становится репозиторием. В корне вашего проекта появляется папка `.git`, и в ней как раз хранится вся история изменений: ветки, коммиты и так далее.

Если говорить про удалённый репозиторий, то его для простоты можно воспринимать как облачное хранилище. Ну типа Google Drive, только в нём ещё хранится история всех ваших изменений. Самые популярные сервисы для хранения Git-репозиториев — это GitHub, GitLab, BitBucket, ну и есть ещё другие. В принципе, можете выбрать тот, который вам больше нравится. Сегодня в примерах я буду показывать работу в GitHub. В других сервисах процесс работы будет аналогичный.

Удалённые репозитории использовать очень практично. Как я уже говорил, если вдруг, не дай бог, с вашим компьютером или проектом, жёстким диском что-то случится, то вы всегда сможете скачать актуальную версию из удалённого Git-репозитория. Кроме того, используя удалённый Git-репозиторий, вы можете работать над одним проектом вместе с другими разработчиками. Без Git совместная работа над одним проектом превратится в ад.

Как связаны удалённый Git-репозиторий и локальный Git-репозиторий? Вы можете отправлять изменения из локального репозитория, из вашей локальной папки проекта в удалённый Git-репозиторий. Для этого используется команда `git push` и получать данные из удалённого Git-репозитория в локальный репозиторий с помощью команды `git pull`. Так мы синхронизируем состояние локального и удалённого репозитория.

Не нужно пугаться команд. Дальше мы поговорим, как можно обойтись без терминала и работать с Git с помощью графического интерфейса, который нагляднее и понятнее. Но всё-таки сначала давайте поговорим про основные команды. Это нам нужно, потому что каждая команда выполняет определённое действие, например, сохранить изменения, отправить изменения в удалённый Git-репозиторий или получить изменения из удалённого Git-репозитория. И кнопки в графических интерфейсах, которые мы дальше будем смотреть и ими будем пользоваться, называются точно так же, как команды, и выполняют, соответственно, те же действия. Поэтому давайте сначала разберёмся, какие вообще действия бывают на примере команд, а потом уже перейдём к понятному интерфейсу, в котором не будем писать команды, а будем нажимать кнопочки.

Вот базовые команды, которых вам хватит в 90% случаев:

Первая команда `init`. Она инициализирует Git-репозиторий в папке вашего проекта. После выполнения этой команды, ну, у вас, собственно, появляется папка `.git` в той папке, в которой выполнили эту команду, то есть проинициализировали репозиторий. И в этой папке будет храниться вся история изменений файлов вашего проекта.

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

Команда `commit` — это, соответственно, сохранение изменений. Мы отредактировали какой-то файл или файлы, которые уже отслеживаются. Дальше, чтобы сохранить эти изменения, нужно выполнить коммит. И тем самым мы сохраняем изменения файлов в Git. На этом этапе сохранения будут зафиксированы в вашем локальном репозитории.

Но чтобы отправить на удалённый Git-репозиторий, нам нужно выполнить команду `git push`. Push отправляет новые коммиты из вашего локального репозитория в удалённый репозиторий. После выполнения команды `git push` ваши изменения появятся уже в удалённом репозитории. Ну, например, в GitHub.

Если вы работаете над проектом только на своём компьютере и работаете один, то этого уже будет достаточно. Но если вдруг вы работаете с разных компьютеров или с кем-то ещё, и у вас в удалённом репозитории появились какие-то изменения, которых ещё нету на вашем компьютере, нужно выполнить команду `pull`, то есть "спулить", получить изменения из удалённого репозитория. И после этой команды вы из удалённого Git-репозитория подкачиваете вот эти новые коммиты в свой Git-репозиторий.

В принципе, можно ограничиться уже этими командами, и это уже будет хорошо, потому что вы будете фиксировать свои изменения и в случае чего просто откатитесь к нужному коммиту. Но ранее я говорил, что это не всегда удобно и в некоторых случаях удобнее использовать ветки. То есть, если мы понимаем, что мы работаем над какой-то новой фичой и она займёт какое-то время и мы хотим изменения фиксировать, но фича не сделается за один коммит, то есть у нас будет какой-то набор изменений, прежде чем она нормально заработает. Для этого мы создаём отдельную ветку. Чтобы не сломать нашу рабочую версию. Мы создаём новую ветку. Для этого используется команда `checkout`. Вообще в Git под капотом происходят две команды: то есть это создание новой ветки и переключение в эту ветку, потому что, ну, сначала мы находимся в ветке `main`, и мы сначала создаём вторую ветку, а потом в неё переключаемся, но команда `checkout` с параметром `-b` и создаёт, и переключается в эту ветку за одну команду. С помощью команды `git checkout -b feature` мы создадим новую ветку `feature` и переключимся в эту ветку. Дальше все новые коммиты, которые мы будем делать, они будут отправляться в эту ветку. То есть это будет параллельная история вот сохранения этих изменений. А ветка `main`, наша основная, останется в прежнем состоянии рабочей версией, как и была.

После того, как мы закончим разработку новой фичи, нам захочется эти изменения перенести в ветку `main`, чтобы они появились в нашей рабочей версии. Для этого мы переключаемся в ветку `main`, выполняем команду `checkout main`. Заметьте, это та же команда, только без аргумента `-b`. То есть мы просто переключаемся в уже существующую ветку. Мы переключаемся в `main` и выполняем команду `git merge feature`. Таким образом, мы, находясь в ветке `main`, выполняем команду `merge` и мержим ветку `feature` в ветку `main`. Таким образом, в ветке `main` появляются наши коммиты, которые были сделаны в ветке, появляется наш новый функционал, и мы уверены, что всё работает корректно.

Я понимаю, что вот так с нуля все эти команды сейчас осознать достаточно сложно, но нам нужно было их проговорить, чтобы дальше уже в графическом интерфейсе всё это просто делать и понимать. В графическом интерфейсе не будет команд, там будут просто кнопки `merge`, `create new branch`, `commit`, `pull`, `push` и так далее.

А, переходим к графическим интерфейсам. Тут у нас есть два варианта. Использовать интерфейс работы с Git в нашей IDE, в которой мы разрабатываем проект. Например, это может быть VS Code или что-то от JetBrains, например, WebStorm. Ну, там PyCharm какой-нибудь есть. И достаточно много там IDE от JetBrains. Суть везде примерно одна и та же. Главное, что это интерфейс работы с Git внутри нашей IDE, ну, то есть программы, где мы пишем код.

Для графических интерфейсов есть ещё второй вариант — это программы, которые отдельно скачиваются для работы с Git. Это, например, GitHub Desktop, GitKraken, SourceTree, Fork. Ну, и их достаточно много. Они чем-то между собой отличаются. В целом, можете использовать их, но их в этом видео я разбирать не буду. На мой взгляд, это избыточно, потому что всё-таки у большинства есть IDE, и зачем вот сейчас усложнять нам жизнь, скачивать новую какую-то программу, если мы всё это можем делать в нашей основной программе, в которой мы и так работаем. Но если вам интересно попробовать, то можете скачать, посмотреть. И принцип работы там будет аналогичный. Там будут те же самые термины, те же самые коммиты, те же самые ветки. В общем, просто будет отдельная программа.

Также хочу отметить, что поскольку взаимодействие с Git вполне реально через консольные команды, оно там на самом деле достаточно гибкое, то есть мы буквально выполняем все необходимые действия напрямую через эти команды, то мы можем взаимодействовать с Git через ИИ-агентов, которые могут вызывать консольные команды. Например, мы можем попросить Claude-code закоммитить изменения или спулить или откатить изменения или попросить в чате VS Code сделать то же самое, то есть залить изменения в удалённый Git-репозиторий, подкачать изменения из удалённого Git-репозитория или откатиться к какому-то коммиту или переключиться в какую-то ветку. То есть это можно делать вербально через ИИ-агентов, просто говорить им, что мы хотим сделать.

Также нейронки уже встроены в некоторые программы с графическим интерфейсом для взаимодействия с Git, например, в GitHub Copilot, в GitKraken нейронки тоже есть, да, и в VS Code, кстати, тоже есть. И мы на них сегодня посмотрим. Ну, VS Code — это IDE, там понятно, что нейронки есть, но они там есть и для работы с Git. Вот что интересно. Но, ээ, в это я тоже сейчас углубляться не буду, просто скажу, что есть такое. То есть есть отдельные программы с графическим интерфейсом, со взаимодействием с Git. И в них, естественно, тоже встраивают нейронки, потому что нейронки сейчас везде встраивают, куда только можно. Можно пользоваться ими, но мне кажется, что сейчас разбирать отдельные программы для взаимодействия с Git — это будет избыточно.

Перед тем, как мы перейдём непосредственно к практике, давайте поговорим про базовый workflow для вайпкодеров. Простая схема, которая спасёт ваш проект. У вас есть главная ветка `main`. Это ваша рабочая версия проекта. Всё, что в `main`, всё работает. Хотите что-то поменять или внедрить новую фичу? Создаёте новую ветку, вайп-кодите обновление в этой ветке, проверяете, что всё работает, и сливаете эту ветку в `main`. Если не работает и вы не хотите больше продолжать реализацию новой фичи, то переключаемся в ветку `main`, а эту ветку фичи удаляем. Вот и всё. Это спасёт вас от ошибок нейронки, которая может потерять какие-то файлы или сломать работающий код в процессе внедрения нового функционала. Можете экспериментировать без страха, что сломаете что-то, что уже работало. И вы всегда уверены, что в ветке `main` у вас есть работающая версия проекта, к которой всегда можно откатиться.

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

Когда вы коммитите какие-то изменения, нужно написать сообщение коммита. В нём описываете то, что было сделано, исправлено, в общем, свои изменения. По-хорошему, чем подробнее вы их описываете, тем лучше, потому что если вы потом захотите куда-то откатиться, вам будет гораздо проще вспомнить, на какой коммит вам нужно переключиться. Потому что, если у вас в каждом коммите будет написано "update", то вы сильно запутаетесь, когда захотите откатиться назад. Но с другой стороны, если это какие-то супер незначительные изменения, сильно париться насчёт сообщения не надо. Главное, чтобы вам было понятно и вы понимали, что если вы потенциально захотите откатиться до этого места, то вы этот коммит найдёте и вспомните, что это именно он.

И ещё один момент связан с нейронкой. Если вы будете взаимодействовать с Git через ИИ-агента, то этот агент будет видеть в первую очередь сообщение коммита, а не его содержание. Ну, в плане изменения, которые были сделаны. В таком случае сообщение лучше писать не только понятное вам, но и чтобы ваш ИИ-агент понял, что это был за коммит. Ну, хотя бы примерно и смог его там посмотреть. Писать сообщение для коммита, на самом деле, точно так же можно с помощью нейронки. Мы это проделаем на примере чуть позже.

Теперь давайте перейдём к практике. Создадим папку проекта, инициализируем в ней Git-репозиторий, сделаем какие-то изменения в файлах, закоммитим, подключим удалённый репозиторий, будем использовать GitHub и отправим эти изменения в удалённый репозиторий.

Сейчас в VS Code я открыл пустую папку, которую только что создал. Это обычная папка, называется `sample-project`, но она может называться как угодно. Название этой папки актуально только для вашего локального компьютера. В удалённый Git-репозиторий это название не пойдёт. Как создавать удалённый Git-репозиторий, мы разберём чуть позже. Сначала давайте посмотрим, как можно локально работать с Git.

Чтобы работать с Git, нам нужно его установить. Делается это супер просто. Мы переходим на официальный сайт Git. Здесь у нас есть кнопка download. У меня for Mac. У вас, скорее всего, будет ваша операционная система. Есть Windows, Linux. Тут ничего сложного. Для Винды есть просто setup, который вы запускаете и устанавливаете как обычную программу. Также можно использовать команду в PowerShell, чтобы установить Git. Для Linux нужно будет выполнить соответствующие команды установки. Для MacOS установка происходит тоже через команды. Можно установить с помощью пакетного менеджера Homebrew. Если он у вас есть, тогда выполняем команду `brew install git`. Скачать пакетный менеджер Homebrew можно по ссылке. Вот он здесь. Он также устанавливается через команду, которую мы вводим в терминале. Можно установить через Macports, тоже Macports надо устанавливать, я им не пользовался, либо через Xcode. Также через Homebrew можно установить графическую версию Git — Git GUI. Выглядеть она будет примерно так. Наверное, интерфейс уже обновился, но нам сейчас этого делать не нужно. Я устанавливал через Homebrew. И если у вас нету этого пакетного менеджера, то установите. В принципе, он ещё вам может пригодиться. И дальше выполните команду `brew install git`. Я могу сейчас выполнить эту команду, но у меня уже Git и так установлен. Здесь запускается установка через пакетный менеджер Homebrew. И вот у меня установился Git. Окей, закрываем.

Переходим обратно в VS Code. Сейчас это обычная папка и, более того, абсолютно пустая. Чтобы сделать из этой папки Git-репозиторий, нам нужно проинициализировать в ней Git. Сделать это мы можем в терминале с помощью команды `git init`. Но поскольку я вам обещал графический интерфейс, то давайте лучше сделаем это через него. Для этого переходим вот в эту вкладку, на которой изображены ветки. Здесь у нас есть две кнопки: "Initialize Repository" и "Publish to GitHub". В первую очередь нам нужно сделать "Initialize Repository". Нажимаем. И у нас проинициализировался Git-репозиторий. Всё просто. То есть по большому счёту была выполнена команда `git init`.

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

Давайте запустим Claude и сделаем какой-нибудь простой файл для тестов. Я прошу его сделать `hello-world.html` файл. На самом деле сейчас неважно, что он сделает. Нам важно, что у нас будут какие-то файлы и в них будут какие-то изменения. То есть в вашем проекте логично будут другие какие-то файлы. Итак, Claude создал нам HTML-файл, в котором, по большому счёту, ничего нет, кроме одного заголовка "Hello World". Нас это вполне устраивает. Если у вас уже есть проект, к которому вы хотите подключить Git и работать с репозиторием, то у нас сейчас примерно похожее состояние. У нас есть какие-то файлы, они сейчас не находятся в Git. То есть, ну, просто файл в папке, и он не отслеживается Git. В вашем случае у вас были бы какие-то файлы, и вы просто с уже имеющимися файлами инициализировали бы Git, и ситуация была бы аналогичная.

Теперь, чтобы сохранить состояние этого файла, мы переходим вот в раздел работы с Git. Здесь у нас показываются сделанные изменения. Здесь напротив файла у нас написана буква `U`. Это значит, что он untracked, то есть не отслеживается Git. Мы его добавляем, нажимаем плюсик. Буква `U` заменилась на букву `A`, значит, added. То есть он добавлен в индексирование, в отслеживание Git. И давайте его закоммитим. Для этого нам нужно придумать сообщение, чтобы не придумывать самостоятельно. Здесь есть кнопочка, которая автоматически сгенерирует это сообщение. Ну, собственно, та же нейронка, которая придумывает сообщение для изменений. Нейронка написала нам сообщение. В целом нас оно устраивает. Мы действительно инициализировали какой-то базовый `index.html` и нажимаем кнопку `Commit`.

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

Если мы сейчас изменим этот файл, например, вместо "World" напишем "Vipe Coders". Теперь у нас заголовок не "Hello World", а "Hello Vipe Coders". Здесь заголовок тоже поменялся. Во-первых, у нас подсвечиваются изменения синенькой полоской. Мы можем нажать на неё и посмотреть, что изменилось. Здесь у нас строчка с "Hello World" заменилась на "Hello Vipe Coders". Также мы можем посмотреть изменения в списке изменённых файлов в этом блоке. Обратите внимание, что напротив файла появилась кнопка `M`. Это значит modified. Изменён. Мы можем два раза на него тыкнуть и посмотреть все изменения. То есть у нас строчка с "Hello World" изменилась на "Hello Vipe Coders". Это будет полезно, если вы полезете в код и начнёте что-то смотреть.

Если вы не хотите лезть в код и смотреть, что там изменилось, и вообще вы в коде ничего не понимаете, то вы можете попросить нейронку проанализировать, что изменилось, и ей будет гораздо проще это сделать, потому что она знает, что был предыдущий коммит, есть какие-то новые изменения, которые отличаются от предыдущего состояния. Она может проанализировать эти изменения и сказать вам, что изменилось. Давайте это сделаем. Спросим у Claude, какие изменения были сделаны. Ну, вообще лучше, конечно, уточнять, что изменения в Git относительно последнего коммита, но давайте проверим, насколько он поймёт такую простую формулировку. Claude понял наш вопрос, и он говорит, что было изменено две линии: line 6 и line 9, то есть изменился title, изменился H1. Дальше он простым языком говорит, что у нас изменились заголовки на "Hello Vipe Coders" вместо "Hello World", который был до этого. Естественно, если изменения будут какие-то посложнее, он будет описывать уже логику, которая была изменена, какие-то, может быть, новые фичи, которые добавились или баги, которые пофиксились, но в любом случае он объяснит, что было сделано.

Также в панели работы с Git есть ещё раздел "Agent Review". Я им мало пользовался, но, насколько понимаю, он должен проверять изменения на ошибки. Это, кстати, прикольная штука. То есть, если было много изменений, вы на всякий случай можете его прогонять. Нажимаем "Find Issues". Сейчас он просмотрит изменения, которые были сделаны. Ну, в нашем случае это два заголовка, поэтому ничего критичного случиться не должно. И он говорит, что всё о'кей, никаких проблем не было найдено.

Теперь мы можем со спокойной душой закоммитить новые изменения. Мы нажимаем плюсик, то есть, что мы хотим их закоммитить. Здесь в списке может быть много файлов, и можно коммитить не все сразу, а выбирать файлы, которые вы хотите закоммитить, изменения, которые вы хотите сохранить. Мы нажали плюсик. У нас файл перешёл в раздел "Changes". И дальше мы можем его также закоммитить. Давайте сгенерируем сообщение для коммита. Нейронка всё правильно поняла, говорит, что у нас обновились заголовки. И нажимаем "Commit".

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

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

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

Поэтому давайте создадим новую ветку. Для этого нажимаем на main. Нажимаем Create New Branch. Назвать мы её можем как угодно. Давайте назовём её experimental. Нажимаю Enter. И мы переключились в новую ветку. Называется она у нас Experimental. Сейчас она идентична ветки main, то есть в ветке. Та же самая история комтов, что и ветки main.

Давайте сделаем какое-то изменение. Попросим Клоду сделать, допустим, счётчик кликов на этой странице. Я прошу Клода сделать кнопку и счётчик кликов на этой странице. Поскольку у нас страница одна, я думаю, он не запутается и поймёт, да, он добавил какие-то стили, э, мы разрешаем ему делать изменения.

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

Теперь нам нужно закоммитить эти изменения. Делаем всё аналогичным образом. Нажимаем плюсик, чтобы добавить этот файл в комит. Генерируем сообщение. Неронка сгенерировала нам сообщение. Нажимаем коми. И комит был сделан.

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

И у нас, в общем-то, есть выбор. Либо нам всё нравится, и мы хотим эти изменения влить в нашу основную ветку, в которой всё работает, и актуальная версия — это ветка main. Либо нам что-то не нравится, новые фичи не работают, и мы не хотим больше продолжать. В таком случае мы можем просто удалить ветку Experimental и вернуться в нашу ветку main.

Чтобы удалить ветку, вот здесь вот напротив changes нужно навести, откроется дополнительное меню, нажимаем на эти три точки. Здесь в выпадающем меню выбираем branch. И здесь есть Delete brНch.

Но сейчас удалять эту ветку я не хочу. Давайте я переключусь в ветку main. Нажимаю на main.

Всё, мы в нашей работающей и актуальной ветке main. Допустим, мы хотим подлить сюда новые изменения со счётчиком из нашей ветки Experimental. Мы нажимаем на три точки, находясь в ветке main, выбираем в меню Branch и merch. То есть, помните, да, это команда Git merch. Просто здесь это через графический интерфейс.

Важный момент, вот это вот надо понимать, потому что здесь легко запутаться. Мы мержем другую ветку в ветку, в которой мы сейчас находимся. Нажимаем merch. Мы находимся в ветке main. И здесь у нас есть ветка Experimental, которую мы создавали. И есть ещё подсказочка. Вот здесь вот тоже, чтобы не запутаться. Select a branch or tag to merge from. То есть из какой ветки мы будем вливать изменения. Мы выбираем ветку experimental.

И у нас подлились изменения из ветки experimental. Теперь у нас в ветке main находятся изменения, которые мы сделали в ветке эксперимен. Мы их протестили в той ветке, решили, что нас всё устраивает, и влили эти изменения в нашу основную ветку. И теперь в нашей основной ветке работающий код с новыми изменениями.

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

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

Я буду использовать GitHub, можно использовать Gitlab, BitBcket, в общем, любой сервис для Git, но GitHub супер популярный, поэтому я разберу на его примере.

Для начала нужно зарегистрироваться. У меня уже есть аккаунт в Гитхабе. Ну, с регистрацией в Гитхабе, я думаю, вы справитесь. Точно так же, как и в Битбакете, и в любом другом сервисе. В этом нет ничего сложного.

В верхней панели Гитхаба у нас есть кнопочка с плюсиком. Мы нажимаем на неё и нажимаем New Repпоitory.

Сейчас мы будем создавать репозиторий. В первую очередь нужно вписать имя репозитория. Оно должно быть уникально в контексте ваших репозиториев. То есть у вас не может быть два репозитория с одним и тем же именем. Я написал сюда gitст. Такого репозитория у меня нет. Сейчас появится.

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

Репозиторий создан, в моём случае это приватный репозиторий. Здесь есть иконка замочка. И здесь у нас появляется инструкция с подключением репозитория к локальной папке.

Подключить вы можете по SSH либо по https. Для SSH нужно дополнительно создавать ключи в настройках профиля и подключать их на свой компьютер. Сейчас для простоты я выберу https. Ничего страшного в этом нету. Этого будет вполне достаточно.

Единственное, что при подключении вас попросят авторизоваться в Гитхабе, в вашем профиле, чтобы понять, что это вы. Меня, скорее всего, просить он сейчас не будет, но давайте попробуем. Здесь я выберу https.

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

Здесь, на самом деле, ничего сложного нету, и нас в первую очередь интересует вот эта команда Git Remote Origin и дальше URL нашего репозитория. Мы таким образом подключаем удалённый репозиторий. Вот это основная команда. И её проще прописать в терминале. То есть мы в корне проекта открываем терминал и вводим сюда эту команду. Я пока что её не выполнил.

Мы можем попробовать подключиться через графический интерфейс. Вот здесь рядом с названием нашей ветки есть иконка с облачком, и на ней написано publish to GitHub. Мы нажимаем на неё. Нас запрашивают авторизацию в Гитхабе. Мы разрешаем это сделать. Нажимаем, что продолжить с Гитхабом. У нас открывается страница авторизации Гитхаба. У меня здесь подключена двухфакторная авторизация. Сейчас мне нужно будет посмотреть этот код. Я посмотрел код. Нажимаю верифицировать.

Дальше Gitthub спрашивает у меня разрешение на создание токена доступа. В принципе, здесь основные параметры уже заполнены. Можно указать, сколько будет действовать этот accessen, поскольку я достаточно редко им пользуюсь. Я поставлю 7 дней и создать токен. У меня произошла ошибка. Он говорит, что такой токен уже был создан. Ну, давайте для примера я просто напишу два и создам этот токен. Токен был создан. Нам нужно скопировать этот ключ доступа и вставить его в поле курсоре. Нажимаем Enter, и авторизация, насколько я понимаю, прошла успешно.

Теперь давайте снова нажмём на кнопочку Publish to GitHub. Здесь курсор предлагает нам выбрать репозиторий, в который мы хотим опубликовать наш проект. По умолчанию он берёт название нашей папки, но здесь мы можем написать своё название репозитория. Вот это название будет уже зафиксировано в удалённом гите. Я написал Gitest и нажимаю на Publish to GitHub privat repository Gitest.

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

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

Но давайте всё-таки через графический интерфейс это сделаем. Нам нужно вот здесь опять же напротив changes нажать на эти три точки, выбрать пункт меню remote и нажать add remote. И здесь в появившемся окне нам нужно указать вот этот адрес, то есть и путь к нашему GitHub репозиторию.

Нажимаем три точки, remote, add remote. Вводим сюда наш адрес. Здесь он даже предложил нам выбрать. Нажимаем add remote from URL. И здесь он просит вписать нас название этого удалённого репозитория.

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

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

И сейчас мы можем запушить изменения в GitHub. То есть пока что у нас все комиты, которые есть, находятся у нас в локальном репозитории. Просто на нашем компьютере, в нашей папке папочки тоgit. Вся эта история хранится. Но мы хотим теперь отправить эти изменения, вообще код проекта в GitHub, то есть в наш удалённый репозиторий.

Чтобы отправить изменения в GitHub, можно либо выполнить команду Gitpush. Здесь у GitHub она и так уже была прописана Git Push Origin Main, но мы попробуем сделать это через графический интерфейс. Для этого нужно нажать на вот это облачко Publish Branch. Нажимаем на него. У нас появилась кнопочка Push. И нажимаем на кнопочку Push.

Давайте обновим страницу репозитория. Можем заметить, что у нас пропала информация о подключении и отобразилась информация о файлах. И сейчас у нас есть файл index HTML в ветке main. И в нём есть наш счётчик. Мы отправили командой пуш изменения на наш удалённый репозиторий. Изменения в репозитории появились, и история комитов тоже здесь появилось.

То есть вот можно заметить, что тут выбрана ветка main. Здесь показано количество комитов в этой ветке. Можем на них нажать и увидеть, что да, действительно, здесь было сделано три комита. Это инициализация вообще странички indхtmail с Hello World. После этого мы поменяли заголовок на Hello Vipe Coders. И после этого мы добавили интерактивную кнопку со счётчиком кликов.

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

То же самое мы могли бы сделать с помощью команд. То есть сначала мы бы выполнили команду Git AD, чтобы Git начал отслеживать изменения в идекс HTML. После этого мы бы закоммитили его с каким-то сообщением с помощью команды Git Commit. После этого мы бы могли создать новую ветку с помощью команды Git BНCH с параметром -bм ветки, сделать какие-то изменения. После этого влили бы нашу вторую ветку в основную ветку с помощью команды Git Merch. Добавили бы репозитории с помощью команды Git Remote AD. С помощью команды Gitpushu Origin Main мы бы установили связь между нашей веткой и удалённым репозиторием и запушили бы изменения.

Мы это делали в два клика, когда нажимали на облачко сначала publish branch и после этого нажимали на кнопку Push, которая сейчас у нас здесь и осталась.

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

Я открыл новую папку. Сам Project 2. Это пустая папка, которую я только что создал. И давайте проделаем всё то же самое, только с помощью команд.

В первую очередь я пишу команду Git и таким образом мы инициализируем Gitпозиторий локальный, как мы делали с помощью кнопочки inт репозиторий, но сейчас мы это сделали с помощью команды. Здесь Git нам подсказывает, что у нас была создана ветка матер по умолчанию. Если мы хотим переименовать её в main или в какое-то другое название, то мы можем использовать команду Git BНCH - M и Name. Давайте переименуем её в main. Просто для примера. На самом деле можно было бы оставить и мастер, но ради интереса давайте сделаем это. Я вписал команду Git BНCH - M main. И теперь та же самая ветка называется main, а не мате.

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

Чтобы добавить его в Git, нам нужно написать Git AD. Здесь мы можем либо поставить точку, и тогда мы добавим все файлы из этой папки в индексирование гита. Либо мы можем написать здесь непосредственно путь к файлу. Ну, в данном случае мы можем написать просто indкс html. Нажмём Enter. У нас теперь файл добавился. Здесь визуально отображается indeкс edit.

Теперь мы можем его закоммитить. Для этого пишем git commit - m и в кавычках пишем сообщение. Я напишу intial commit. Нажимаю Enter. Файл был закамичен. Заметьте, что изменённый файл пропал из раздела changes, а в разделе граф у нас появился наш первый комит.

Давайте создадим новую ветку и переключимся в неё с помощью команды Gitch checkout -b feature. Нажимаю Enter. Обратите внимание, что у нас поменялась ветка в курсоре. То есть всё это синхронизировано. Всё происходит в папочке тоgit, независимо от того, в каком интерфейсе мы работаем с гитом: через консоль либо через графический интерфейс.

Сейчас мы переключились в... давайте уберём там бордер rрадиус в стилях. На самом деле могут быть любые изменения. Сделаем ещё один комит. Только сейчас мы напишем remove border rрадиус. Нажимаю Enter. И мы получаем ошибку. Дело в том, что нам нужно добавить файлы, которые мы хотим закоммитить. Поэтому нам нужно опять вписать git add. Ну, давайте теперь напишем точку, если бы у нас были какие-то другие файлы.

А, кстати, давайте их создадим. Давайте создадим файл redmi. И напишем в нём Hello World. Сохраняю. Теперь у нас здесь есть два файла. И если мы визуально посмотрим, то у нас два файла, один из которых unреaked, второй из которых modified. Но чтобы закоммитить их, нам нужно их добавить в комит. То есть вы помните, что мы можем коммитить не все файлы, мы можем комитить какие-то выбранные, а какие-то оставить с локальными изменениями. Кстати, в консоли это тоже можно проверить. Для этого можем выполнить команду Git status. Нажимаю Enter. И здесь мы видим ту же самую информацию, то есть modified index html. И есть untracked файл, то есть который не отслеживается. Это redmi.

Давайте добавим оба файла. Для этого напишем git ad с точкой. Нажимаю Enter. Оба файла у нас добавились для комита. И теперь мы можем выполнить коми. В сообщении я пишу, что мы убрали бордерадиус и создали Redmi file. На самом деле, по-хорошему, это нужно было разделять на два коit. Как я уже говорил, что коit — это какое-то атомарное изменение. И в данном случае мы бы могли отдельно закоммитить indкс html с сообщением, что мы убрали бордер радиус, и отдельно закоммитить Redmi с сообщением, что мы добавили Redmi. Таким образом, у нас было бы два несвязанных друг с другом изменения. И это, наверное, с точки зрения best practice было бы лучше. Но на самом деле главное, чтобы вам было удобно. И в данном случае можем сделать так. Мы закомитили оба файла. Теперь у нас в ветке feature убран border rрадиус и добавлен файл Redmi. А в ветке main у нас только и ниши алками.

Допустим, мы хотим теперь смежить эту ветку, то есть слить изменения из ветки feature в ветку main. Для этого переключаемся в ветку main с помощью команды Gitch checkout main. Обратите внимание, что комиты, сделанные второй ветке, у нас пропали здесь в визуальном отображении, и выполняем команду Git Merge feature.

То есть Git Merge — это команда, что мы будем сливать ветку, а Feature — это название ветки, которую мы хотим влить в выбранную ветку. Выбранная ветка у нас main. Нажимаем Git Merge Feature, нажимаем Enter. И у нас появился новый комит, который был сделан во второй ветке.

Чтобы удалить ветку, мы можем вписать команду Git BНCH - D feature. Нажимаем Enter. И у нас была удалена ветка, которую мы до этого создавали.

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

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

Создаю новый репозиторий в Гитхабе, называю его Git Test 2, создать репозиторий. У нас сейчас откроются подсказки, как нам этот репозиторий подключить. И давайте проделаем эти команды в нашем терминале.

Комиты мы уже сделали. Ветка у нас итак main. Нам нужно только добавить удалённый репозиторий с помощью команды Git Remote Origin и запушить изменения. Давайте добавим наш удалённый репозиторий. Я вписываю сюда команду, нажимаю Enter. Удалённый репозиторий был добавлен. И теперь нам нужно запушить в Origin Main изменения. Нажимаю Enter. Изменения были запушены.

Давайте обновим страницу репозитория. И видим, что наши файлы в ветке main добавились в наш удалённый репозиторий. Смотрим Redmi. Тут написано Hello World. Смотрим HTML. Здесь код нашего index html команды - это хорошо.

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

Давайте сейчас попробуем проделать аналогичный процесс с помощью EИ агентов. Будем использовать-код. Хотя точно так же можно было бы использовать чат в курсоре или какого-то другого иагента, который может выполнять терминальные команды.

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

Давайте я покажу, как всё-таки из удалённого репозитория склонировать нам проект, потому что это тоже важная тема, её нужно проговорить. Допустим, мы хотим склонировать Git Test 2. Может, мы хотим поработать на другом компьютере, и у нас на нём ещё нету этого проекта. Для этого здесь открываем меню код. Нам нужно склонировать путь к нашему репозиторию. Нажимаем копировать. И склонировать его можно либо через команду Git Clon и наш репозиторий. Но давайте попросим склонировать репозиторий клода. Мы всё-таки здесь нейронки разбираем, а не в команду упарываемся. Клон My Project. И ссылку вставляю. Давайте посмотрим, как он с этим справится.

Обратите внимание, он выполняет ту же самую команду Gitlon и ссылку. Я соглашаюсь с ним. Он склонировал наш проект, но он склонировал его в папку Git Test 2. То есть команда Git Clone, она создаёт папку с названием проекта внутри папки, в которой была вызвана эта команда. То есть мы вызвали команду в папке SP Project 3, и она внутри этой папки SP Project 3 создала папку с названием нашего репозитория, в данном случае Git Test 2, и в ней уже находится наш проект.

На самом деле, мы можем сейчас эту папку просто удалить. Move to trash, и всё, у нас опять пустая папка. Никакого Gitпозитория сюда не подключено. То есть вся информация о подключении к Git была внутри папки тоgit, ну, которая была ещё внутри папки Gitest 2. Вот в нашей текущей архитектуре мы всё удалили. Никакого гита здесь нету.

Сейчас я заново открою клод, и я хочу с нуля, чтобы он инициализировал гиIT и начал с ним работать. То есть, допустим, это пустая папка проекта. Либо тут может быть уже какой-то проект, да? Давайте я сюда indкс HTML добавлю. На самом деле для примера, ну, допустим, у вас есть уже какая-то структура проекта, вы хотите к нему Git подключить. Если бы файла index HTML здесь не было, ну, логика была бы на самом деле точно такая же.

А пока он это делает, я создам ещё один Gitпозиторий, чтобы он туда залил все изменения. Назову его Git Test 3. Выбираю видимость приватный. Создать репозиторий.

Итак, CLД создал Redmi Файл. Я соглашаюсь с его изменениями. Git предлагает выполнить команду Git и ну это, собственно, то же самое, если бы мы эту команду выполняли сами в консоли. Я с ним, конечно же, соглашаюсь. Далее, он предлагает добавить файлы, чтобы они отслеживались гитом, и закоммитить их. Я с ним соглашаюсь. И он закончил. Мы можем посмотреть в разделе гита, что у нас появился новый комит, в котором, собственно, и были добавлены эти файлы. То есть он создал файл Redmi, добавил его и добавил наш индекс HTML. Всё, круто.

Теперь давайте попросим его, чтобы он добавил наш удалённый репозиторий. Для этого я копирую путь нашего удалённого репозитория и прошу его. Я пишу ему: "Добавь удалённый репозиторий и запуш всё в него". Также прикрепляю ему ссылку на репозиторий. Нажимаю Enter. И давайте посмотрим, как он с этим справится.

Во-первых, он выполняет команду Git Remote Add Origin и путь к репозиторию. Обратите внимание, это та же самая команда, что нам предлагает сделать GitHub. И дальше второй командой он предлагает запушить всё в мастер. Причём он запушит это в мастер, не в мей. Но на самом деле ничего страшного. Давайте разрешим ему это сделать. Мы могли бы указать конкретную ветку, в которую мы хотим, но поскольку там репозиторий пустой, я думаю, что и с мастером должно получиться. Нажимаем Enter. Он закончил выполнять команду.

Давайте посмотрим, что у нас появилось в репозитории. Всё прекрасно. У нас появилась ветка мастер. Причём ветки main нету. У нас есть только одна ветка мастер. Она у нас дефолтная. И в ней у нас, собственно, есть наши файлы. Всё, круто.

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

Но сейчас мы разберём ещё некоторые детали по работе с гитом, которые я тоже считаю важными. Первое из таких нюансов, то что хочется вам сказать — это файл Git Ignore. Это очень важный, на самом деле, файл, который говорит, какие папки и файлы нельзя отправлять в Git. И важный он потому, что во многих проектах есть файл environment, ну, то yf, и в нём хранятся апи ключи, и их ни в коем случае нельзя отправлять в гиIT и уж тем более в открытый гит репозиторий, потому что любой сможет посмотреть ваши ключи и воспользоваться ими. И это плохо.

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

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

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

В первую очередь, конечно, можно создать его руками. Просто создать файл тоgitignor, и он уже автоматически у меня подсвечивается логотипом гита и прописать сюда просто пути к файлам и папкам, который мы не хотим отправлять в Git. Но сейчас я его удалю и попрошу клода создать Git ignore файл. Пишу ему create gitgnore. Он меня прекрасно должен понять. И создаст какой-то стандартный git иignore, да, в котором опишет какие-то базовые названия папок и файлов, которые нельзя добавлять в Git. Я с ним соглашаюсь. У нас появляется файл Gitgnore. В нём у нас есть папка VSкод. А, и он, кстати, сразу предлагает запушить этот файл. И это правильно, потому что файл git игнор пушить надо, а вот папки, которые в нём указаны, пушить не надо. Так что да, мы соглашаемся, мы пушим его в гиIT. И давайте посмотрим. То есть есть DC Store. Это, насколько понимаю, у маков папочка иногда создаётся. Очень важно это енвы, то есть НВ yf local. И они даже если будут не в корневой папке, а где-то вложенные, тоже не будут тоже не будут добавляться в гиIT. Здесь есть также папка modules, логибага, какие-то ошибки. ярна папочка buildди. В общем, папки, которые в гиit обычно не добавляются, и это очень удобно. Например, если у вас приложение использует а ключ от какой-то нейронки, то, конечно, вам в гиit его добавлять не надо. То есть вы локально его в прописали, но в гите его хранить не нужно, особенно если у вас открыты репозиторий.

Если мы обновим репозиторий в Гитхабе, то видим, что добавилось файл gitgnore. И здесь, в общем-то, все наши изменения присутствуют. Да, это очень важный файл, и его стоит добавлять.

Следующее, что хочется отметить - это возможные конфликты. Если вы работаете над проектом один, если вы не делаете параллельно нескольких новых фичей, то, скорее всего, этих проблем у вас не будет. Конфликты появляются, когда у нас есть две ветки, в которых параллельно происходят какие-то изменения в одних и тех же файлах. Например, у нас есть ветка main. Мы создали от неё ветку с какой-то фичой, в ней делаем какие-то изменения. параллельно какие-то изменения происходили в мейне, либо была создана ещё одна ветка, из которой после этого изменения в мей были влиты. Получается, что у нас в одном и том же файле в двух ветках были параллельно сделаны какие-то изменения. После этого мы их пытаемся слить в одну. И получается, что Git не знает, какие изменения использовать. То есть у нас в одной ветке были изменения в этом файле, и в другой ветке были изменения в этой файле. Что из этого главнее, Git. Иногда понимает. Ну, то есть это, если явные разные куски кода, тогда он нормально это обработает. Но если, допустим, была изменена одна и та же функция, ну или кусок кода, неважно, то гиту будет сложно определить, что из этого корректно, и он попросит помочь нас решить этот конфликт.

Давайте сейчас попробуем воссоздать эту ситуацию. Для этого из мастера текущего создадим новую ветку Create New Branch. назову её фичер. И здесь я подредактирую ээ какуе-нибудь свойство. Можно было бы сейчас через нейронки делать, но для демонстрации конфликта это в целом избыточно. Я просто один и тот же файл поменяю. То есть вместо диплейфлекс напишу здесь блок. В общем, изменили какую-то строчку кода в одном файле. Сейчас я его закомичу. Перехожу сюда, нажимаю плюсик. Это плохое сообщение для комита, но для примера пойдёт. Нажимаю комит. И я закоммитил в ветку feature это изменение. Теперь я переключусь обратно в ветку master. В ней у нас по-прежнему дисплейфлекс. Ну, логично, мы сделали изменение в другой ветке. И создам из ветки мастер ещё одну ветку. Назову её фир 2. И здесь я изменю это свойство на диплей inлаline блок. Суть в том, что мы одну и ту же строчку меняем в разных ветках параллельно. И тоже закамичу это изменение. Добавляю файл, пишу сообщение display, нажимаю commit. Окей. Сейчас у нас получается следующее. У нас есть ветка мастер, у которой начальное рабочее состояние. Есть ветка feature о, в которой мы поменяли строчку. Есть ветка фир 2, в которой мы поменяли ту же самую строчку.

Сейчас мы переключимся обратно в ветку мастер и вмержем сюда ветку Future 2. Неважно какую, важно, что у них были изменения в одном и том же файле. Выбираю пункт меню Branнch merch и выбираю Future 2. Ветка успешно вмерлась. В ветке мастер стало свойство дисплей inline блок. А теперь я хочу вмежить сюда фиature один. И да, вам может показаться, что это сюр какой-то. Зачем создавать две ветки, в которых я поменял одну и ту же строчку? Но в реальной ситуации это будет не одна строчка, а больше. То есть и это может быть даже не один файл, а ещё дополнительно какие-то файлы. И те файлы смертся нормально. А вот с этой строчкой будет проблема, потому что она была изменена в двух разных ветках параллельно. Но для простоты эксперимента я сейчас не делаю каких-то дополнительных изменений.

Теперь мы находимся в ветке master, и я хочу сюда вмерть ветку featur. Выбираю пункт New Branch, нажимаю merch и выбираю feature. И у нас произошёл конфликт. Отображается он следующим образом. У нас была изменена одна и та же строчка кода. То есть в Head у нас был disдий inline блок, а в ветке Fature у нас в строчке написано блок. Здесь у нас есть два варианта. Первый - это Resolve and Merge Editor. Это ручное управление. Давайте попробуем это сделать. Я нажал Resolve Merch Editor, и у нас здесь подсвечивается слева то, что у нас было в ветке feature, справа изменение feature 2, посередине у нас результат. То есть здесь мы можем хоть руками прописать inлайблок или что-то ещё. Можем хоть всю строчку Можем хоть всю строчку поменять и нажать complete merch. Мы можем сразу нажать Complete Merch, то есть тогда у нас сейчас дисплейфлекс в реальте будет. Но нам сейчас это не так интересно.

Давайте нажмём на кнопку ресет вместо того, чтобы решать конфликт руками. На самом деле, иногда всё-таки надо, конечно, посмотреть глазами, в чём конкретно проблема, но если мы не понимаем вообще код и у нас произошёл этот мерчконфликт, мы можем нажать на кнопку Resolve in chat. Тогда у нас появляется сообщение в чате курсора Resolve merch conflict. Точно также мы можем в clклод написать Resolve the merch conflict. Enter. Clмвить Display Flex. На самом деле это вообще начальное состояние, и в нём как бы корректно всё отображалось. И на самом деле другие стили, вот Flex Direction и Align Items, они подразумевают, что здесь должен быть Flex. Ну поэтому он предложил вообще поменять его на флекс и решить этот конфликт таким образом. И на самом деле, в данном случае он будет прав, потому что оба этих изменения, они здесь неправильные. Но здесь я не хочу с ним соглашаться. Вот пока что. И я хочу вместо того, чтобы, ну, можно было бы согласиться, и он бы решил: "Давайте нажмём Resolve in this chat". Сейчас я тут всё сотру. Resolve in chat. И нажимаю отправить. Посмотрим, как этот конфликт решит курсор. Курсор тоже исправил нам конфликт. Он на самом деле достаточно долго думал. Мне кажется, если бы здесь был выбран не Авто, а 4 и5, то было бы гораздо быстрее. Но я ради эксперимента оставил авто, который был выбран изначально. Но решил конфликт он следующим образом. Точно также поставил Display Flex. Ну и в целом он прав. Нельзя с ним спорить, это корректное свойство.

Можем посмотреть на изменения в файле index html. И здесь было добавлен поле Display flex. Давайте нажмём continue. Он говорит, что у нас были какие-то несохранённые вкладки, но мы можем их позакрывать здесь. Нажмём Don't save, да? И вот индекс HTML стал с полем Displayф. Ну, курсор что-то криво добавил. Мне не очень нравится, как работает режим авто. Я обычно на Set 4.5 нахожусь. Ну, давайте здесь две табуляции сделаем и нажимаем continue. Continue. А, ну, две табуляции я, видимо, сделал уже отдельно. Но суть в чём? Мы пофиксили мер конфликт, и это состояние закамичено.

Можем увидеть в графической визуализации, как это было сделано от комита с Gitnore. Мы в отдельной ветке добавили Display Inline, потом вмержили её и в данном случае просто появился комит с Display Inline в цепочке комитов. После этого мы в другой ветке сделали дисплейблок и вмерли эту ветку в нашу основную. И сейчас в нашей основной ветке мастер, ну, актуальное состояние с исправленным конфликтом. Здесь написано диплейф. Ну, давайте я ещё закомичу этот оset, нажму коми. Всё. И теперь, чтобы эти изменения появились в нашем GitHub репозитории, то есть в удалённом репозитории, нам нужно сделать push. То есть нажимаем на кнопочку push. отправляются изменения в удалённый репозиторий. Смотрим, количество комитов обновилось и состояние нашего проекта тоже обновилось. Если мы посмотрим на список комитов, то увидим здесь как раз те же самые комиты, которые были сделаны у нас локально. После команды Gitpush. Ну, после выполнения этого действия нас эти комиты отправились в наш удалённый репозиторий, и теперь они находятся здесь.

Вот ещё какой есть момент. Допустим, вы работаете с проектом, удалили какой-то нужный код, у вас что-то сломалось, в общем, не работает, и вы эти изменения не комитили, то есть они только у вас локально. А в последнем комите в ветке всё хорошо работало, и вы хотите откатиться. Делается это очень просто. Мы опять же переходим в раздел работы с гитом, выбираем тот файл, который мы хотим откатить, и здесь есть кнопочка discard changes. Мы нажимаем на неё, подтверждаем, и у нас файл восстанавливается в состоянии, в котором он был при последнем комите. То есть изменения, которые мы внесли в процессе работы, которые мы никуда не сохраняли, не отправляли, они просто вот локально у нас, мы можем откатывать таким образом.

Если вы работали в одной ветке, не создавали новых веток, делали какие-то комиты и всё-таки поняли, что хотите откатиться к предыдущему комиту, сделать это можно следующим образом. То есть вот в истории камитов локально у себя на компьютере, либо можете посмотреть в удалённом гитрепозитории, нам нужно найти тот комит, до которого вы хотите откатиться, и найти здесь его айдишник. Допустим, мы хотим вообще к комиту инициализации откатиться. Мы наводим на него, видим здесь ID этого комита. Нажимаем, чтобы скопировать. И нам нужно выполнить команду Git Reset с параметром hard и вписать сюда айдишник комита. Да, вот он такой большой. Если мы сейчас выполним эту команду, то гит откатится к этому комиту и удалит комиты, которые были после него. Чтобы этот откат произошёл и в удалённом репозитории, нам нужно будет потом запушить эти изменения. Но тут будьте очень осторожны, потому что, особенно, если вы работаете с другими людьми, и если вы так откатите основную ветку, ну, возможны проблемы, которые потом уже будут непоправимы. Поэтому лучше всё-таки под новые фичи, где вы сомневаетесь создавать новые ветки.

Давайте сделаем следующим образом. Сейчас мы откатимся к предыдущему комиту, чтобы у нас ещё один в запасе остался. Я сейчас скопировал айдишник комита второго. Нажимаю Enter, и мы к нему откатились. То есть здесь у нас в графе показано, что в удалённом репозитории у нас ещё есть тот комит. И чтобы заменить локальным состоянием удалённой репозиторий, нам нужно выполнить следующую команду Git Push параметром Force Origin Main, потому что по факту у нас локально два комита, на удалённом сервере три комита, и мы же не можем его просто так переписать. Но с помощью параметра Force можем. Нажимаем Enter. И на нашем удалённом репозитории удалился последний комит. То есть, то есть мы взяли локальное состояние проекта и заменили на удалённом репозитории состояние на наше. Но это очень опасная штука, и лучше её лишний раз не использовать. Лучше, конечно, ветками оперировать, так будет безопаснее.

Давайте попробуем сейчас сделать то же самое через клод. Я скопирую айдишник первого коммита. Я пишу клоду: "Откатись до комита с айдишником и запуш в удалённый репозиторий". Нажимаю Enter. Посмотрим сейчас, что он сделает. Возможно, он уточнит у нас, точно ли мы хотим запушить заменить или как мы хотим это сделать. Давайте посмотрим. Во-первых, он предлагает gitхар, это верно. То есть мы сейчас локально откатываемся до нашего первого комита. И в графе мы можем видеть, что у нас так и получилось. Локально у нас нету последнего комита. То есть последний комит локально у нас - это вот, ну, вот этот первый в данном случае. И теперь он предлагает нам сделать git push Origin Main с параметром Force with leas. Это почти то же самое, что Forcebce, но немного более безопасный параметр. То есть он применяет форс только, если удалённая ветка в том же состоянии, в котором мы последний раз её скачивали. Если кто-то за это время сделал какие-то изменения, то он не будет forфорс выполнять, но в данном случае он это сделает. Я ему разрешаю. И теперь у нас и локально, и удалённо в репозитории только один комит.

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

Что мы сегодня поняли? Гит - это не так уж и сложно, тем более, когда под рукой есть иагент, который может выполнить все сложные команды и решить конфликты. Но использование гита даёт вам уверенность, что вы не потеряете свой проект. Даже если вы где-то накосячили, у вас всё равно есть эта история изменений, и так или иначе вы сможете откатиться к нужному этапу, когда всё работало корректно и ничего ещё не было сломано. Более того, если вы храните свой проект в удалённом репозитории, вы сможете скачать его на любой другой компьютер, работать совместно с другими людьми и быть увереным, что даже если с вашим компьютером что-то случится, у вас есть проект в удалённом репозитории, который вы всегда сможете из него восстановить. Для вайпкодеров гит - это страховка и суперсила. Да, вы можете откатываться в контексте одного чата в клоде, в курсоре, в каких-то других сервисах, но это всего лишь контекст одного чата. Но как только вы создаёте новый чат, история изменений пропадает, поэтому вам нужен гит. И с нейронками это просто мастх, без него никак.

Надеюсь, у меня удалось доступно и просто объяснить, как можно использовать гит в своих вайп-кодерских проектах. Если у вас остались вопросы, пишите их в комментарии. Ну или задайте своему иагенту. Подписывайтесь на канал, чтобы не пропустить новые видео. Ставьте лайк, чтобы YouTube рекомендовал вам больше годного контента. Подписывайтесь в Telegram-канал Годный вайпкодинг. В нём я публикую полезные материалы по вайп-кодингу. Также у нас есть вайп-кодерский чатик, в котором можно пообщаться с другими вайп-кодерами, позадавать вопросы, поотвечать ответы. Иногда там даже публикуют какие-то предложения о вайпкодерских проектах. Так что подключайтесь к нашему вайпкодерскому комьюнити. А на этом я с вами прощаюсь. Всем годного кода и до скорых встреч.