GIT, GitHub, GitLab. Полный АКТУАЛЬНЫЙ гайд ЗА ПОЛТОРА ЧАСА. Без этого выгонят с работы.

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

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

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

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

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

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

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

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

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

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

Теперь посмотрим визуально на то, что такое коммит, а потом уже пойдём к коду. Итак, смотрите, я сделал небольшую демку. Это лендинг такой международной корпорации, которая называется Bergard. Защитим бобров вместе. Вот есть бобр и есть небольшой лендинг. И тут у меня отладочные кнопки коммит 1, коммит 2, коммит 3, которые не включены в сайт, но при нажатии на них я могу посмотреть состояние этого сайта на разных коммитах.

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

Вот я сейчас нахожусь на первом коммите. Нажимаю на коммит 2. Смотрите, добавили шапку. Добавили ещё какие-то определённые подразделы. И сайт заканчивается у нас тем, что нас поддерживают: Майкл Джексон, Анна Новак. Хорошо. Нажимаю коммит 3, и появилось ещё ниже. Теперь появился футер. Отлично. То есть вот три коммита, разные, и видите разное состояние сайта. То есть каждый коммит несёт в себе какой-то определённый код. Вот коммит 2 несёт, например, код шапки и пары блоков. Коммит 3 — это футер, чисто футер. Отлично. Теперь вы имеете общее представление о том, что такое Git и для чего он нужен. Даже визуально посмотрели, как между коммитами можно переключаться и смотреть в разные точки истории проекта. Самое время пощупать всё это руками с самых азов и понять, как же нам с ним жить.

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

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

Вот я сейчас нахожусь на первом комите. Вот нажимаю на коit 2. Смотрите, давайла шапка. Добавили ещё до допразделы какие-то определённые. Вот. И сайт заканчивается у нас тем, что нас поддерживают. Вот Майкл Джоксон. Вот Майкл Джонсон, например, и Анна Новак.

И теперь погнали к практике. Важно понимать, что Git — это просто технология, а репозитории, созданные по этой технологии, могут храниться где угодно. Поэтому у нас и есть GitHub, GitLab, Bitbucket, господи, прости, и ещё много других. Соответственно, на одном из таких хабов нам и нужен свой аккаунт, и мы сделаем аккаунт на GitHub. Вот их сайт — предлагаю вам пройти несложную процедуру регистрации и стать счастливым обладателем аккаунта на GitHub. После регистрации вы сможете нажать в правом верхнем углу плюсик и выбрать New repository, создать свой новый репозиторий, который мы назовём Bamer Defender. Как вам такое имя? Да, мне кажется, кайф. Создаём его. Теперь вы увидели кучу команд, которые, возможно, вас могут испугать. И я предлагаю вообще не обращать на них внимания, потому что начнём мы наш путь изучения с визуального, с помощью дружелюбнейшей программы GitHub Desktop. Вот её сайт. Просто введите GitHub Desktop и скачайте для своей системы. Всё.

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

И в итоге вы получите вот такую дружелюбную программку. Об интерфейсе мы поговорим дальше. Теперь, после того как вы её скачали, возвращаемся обратно в наш репозиторий. Здесь мы должны получить ссылку, которая начинается с https. Мы её копируем: нажимаем HTTPS и копируем саму ссылку. Идём в эту супердружелюбную программку и добавляем Add → Clone repository, и можем просто указать URL, например. Вот так.

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

Нажимаем Clone. Что такое клон? Мы клонируем код с репозитория, стягиваем его себе. Это называется в Git клон. Ещё одно новое слово в нашем Git-лексиконе. Теперь я в редакторе кода открою эту папку, куда я склонировал репозиторий, и мы начнём там делать всякое. Вот я открыл папку в моей IDE, которая называется WebStorm. И WebStorm сразу же создаёт папку .idea, потому что в ней есть те файлы, которые ему нужны, его файлы, на которые он опирается, чтобы индексировать всё и отображать и так далее и тому подобное. В общем, внутренние файлы программы. И тут мы уже можем посмотреть, как работает Git, потому что в GitHub Desktop уже появилось пять changed files, да, он увидел, что какие-то новые файлы добавились. И вот, видите, что они действительно есть, их содержимое видно и так далее. Если что, я разделил экран на две части, как видите — GitHub Desktop и WebStorm. Теперь давайте создадим index.html файл, просто HTML-файл, и, разумеется, он тоже появится сразу же здесь. В этом файле пока ничего не будет, но мы потренируемся и уже сделаем первый свой коммит, в котором будет информация о том, что мы добавили пустой файл index.html. Итак, смотрите, внизу у нас есть Summary. Нужно как-то назвать сообщение коммита. Description заполнять необязательно. А вот тут мы напишем: "Add index.html file", чтобы в истории коммитов любой другой человек мог посмотреть и увидеть, что этот коммит делает. Этот коммит добавляет index.html-файл.

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

И теперь погнали практике. Важно понимать, что гит - это просто технология, а репозитории, созданные по этой технологии, могут храниться где угодно. Поэтому у нас и есть GitHub, GitLab, GitBcket, Господи, прости, и ещё много других. Соответственно, на одном из таких хабов нам и нужен свой аккаунт,

и мы сделаем аккаунт на гитхабе. Вот их сайт предлагаю вам пройти несложную процедуру регистрации и стать счастливым обладателем аккаунта на гитхабе. После процедуры регистрации вы сможете нажать в правом верхнем углу плюсик и нажать New Repпоitory, создать свой новый

репозиторий, который мы назовём Bamer Defender. Как вам такое имя? Да, мне кажется, кайф. Создаём его. Теперь вы увидели кучу команд, которые, возможно, вас могут испугать. И я предлагаю вообще никакого внимания на них не обращать, потому что начнём мы наш путь изучения с

визуального изучения с помощью дружелюбнейшей программы GitHub Desktop. Вот её сайт. Просто введите GitHub Desktop и скачайте для своей сети. Всё.

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

Мы её копируем. Просто вот нажимаем https и копируем саму ссылку. идём в эту супердружелюбную программку и добавляем add clone repository и можем просто указать урл, например. Вот так вот.

Нажимаем клон. Что такое клон? Мы клонируем код с репозитория, стягиваем его себе. Это называется в гите клон.

Ещё одно новое слово в нашем Gitлексиконе. Теперь я в редакторе кода открою эту папку, куда я склалонировал репозиторий, и мы начнём там делать у всякое. Вот я открыл папку в моей IDE, которая называется Webstorm. И Webstorм сразу же создаёт папку то, потому что в

ней есть те файлы, которые ему нужны, его файлы, на которые он опирается, чтобы индексировать всё и отображать и так далее и тому подобное. В общем, внутренние файлы программы. И тут мы уже можем посмотреть, как работает Git, потому что в GitHub десктопе уже

появилось пять changed Files, да, он увидел, что какие-то новые файлы добавились. И вот видите, что они действительно есть, их содержимое видно и так далее. Если что, я разделил экран на две части, как видите, да, на GHub Desktop и Webstorm. Теперь давайте

создадим INDК HTML файл, просто файл htmльки, и, разумеется, он тоже появится сразу же здесь. В этом файле пока ничего не будет, но мы потренируемся и уже сделаем первый свой комит, в который будет содержать информацию о том, что мы добавили пустой

файл index html. Значит, смотрите, внизу у нас есть summary. Мы должны как это назвать, какое-то сообщение комита должно быть. Description заполнять нам не обязательно. А вот тут мы добавим, что add index htmlфайл, чтобы просто в истории комитов любой другой человек мог

посмотреть и увидеть, что этот кот делает. Этот комит добавляет индекс htmlфайл. Всё. Здесь мы можем выбрать те файлы, которые пойдут в этот комит.

Давайте пока мы уберём все эти ID, что с ними делать, мы разберёмся позже, но сделаем комит чисто из индекса HTML. Вот могу нажать кнопку commit one file to main.

Нажимаем publish points. Всё это произошло. Теперь мы можем перейти в вкладку History и увидеть, что здесь есть Commit. Это indкс html. Вот он так и называется. IV Черняков, его автор just now. Это, то есть сейчас произошло. Что произошло? Добавился

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

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

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

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

Давайте посмотрим, как это выглядит. Вот просто шапка BG, да, и кнопки, которые ничего не делают, просто вот начало. То есть представим, что задача первого разработчика была сделать эту шапку. Вот он сделал своё дело и хочет сделать commit, а именно add header, да, и

делает commit file to main. Всё, push origin push. Соответственно, ещё одно слово в нашем лексиконе - это push. Push - это что? Толкнуть, да? Протолкнуть.

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

истории. У нас есть первый комида. indкс htmlфайл, другой adheader. И здесь уже есть нечто более интересное. Он показывает плюсиками. Видите, такие-то строки были добавлены. Ага, всё понятно.

Давайте сделаем ещё один комит, который удалит, например, какую-то часть кода. А именно у нас здесь mobileменю есть.

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

я, видимо, заменил это пустую строку, на самом деле. Поэтому он показывает плюс, что пустая строка будет добавлена вместо этого. Убираем.

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

Всё очень просто. И давайте его возьмём и создадим этот комит. Delete mobile menu пушу. Пушу комит. Видите, уже когда практика, он соёт практика, практика.

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

Теперь смотрите, вот эти вот файлы. ID, оно уже начинает немножко раздражать, что они будет висеть всё время, я их просто не комичу. Да. Во-первых, давайте, почему я их не комичу? Потому что я работаю на вебшторме. Кто-то может работать, не знаю, на ВС-коде, кто-то на

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

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

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

Очень просто. есть функция в гиitте git ignore. В корне проекта создаётся файл тоgit ignore.

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

Например, я могу ввести э вот так вот. Точка, сама папка. Оп, видите, всё пропало, да? И Git игнор файл сам появился, потому что он будет игнорировать всё, что связано с папкой и идея. Я очищу. Они опять снова появятся

как бы готовыми закомититься, да? Поэтому идеи мы оставляем. Точно также я могу взять и поставить сюда на индекс HTML. Всё, чик он тоже гит игнорится.

Зачем? Можем сделать паттернами. Можем поставить звёздочкой HTML, то есть все HTML-файлы получатся, да? В общем, тут а гигнор воспринимает много паттернов, но в основном этот файл вам не нужно так писать вот руками. Он либо генерится уже за вас, на рабочем месте уже есть, либо

вот вы так постепенно его соберёте, либо можно найти готовые такие файлы для различных языков, различных типов проектов, фреймворков и так далее. Где уже прописаны те файлы, которые явно не нужно пушить репозиторий. О'кей. HTML я удаляю, а ID оставляю. Теперь, чтобы это

сохранить, мне нужно сделать комит с гит игнором. И он будет называться, смотрите, мне даже предлагает сам GitHub desktop назвать его create ignore. Да, пожалуйста. Всё, create ignore.

Чик. Всё, мы запушили коit с gitгнором. Теперь нас больше не будет беспокоить этот файл. Можем дальше продолжать работать с HTML. Теперь сразу же коротко представим простую рабочую ситуацию.

Когда вы удалили мобильное меню, да, и прибежал менеджер, сказал: "Ты что, какого чёрта ты удалил мобильное меню?

Возвращай быстро". Что можем сделать? У нас же есть история гита. Мы идём в историю Git, находим этот коit del Delete Mobile menu кликаем правой кнопкой мыши и можем сделать revertes in commit. Нажимаем.

И он создал комит, который ревёртит этот комит, понимаете? То есть это не просто типа стирание комита из истории и всё. И живём спокойно. Тут полностью трекается история. То есть мы трекаем новое действие которое собственно отменяет предыдущие действия. Это также как в

фотошопе дунду, знаете, стрелочка назад, стрелочка вперёд в Экселе, в любой программе. На самом деле что-то очень сильно похожее. О'кей. Также пушим это изменение. Нажимаем push. И теперь у нас комит с ревёртом.

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

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

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

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

будут вместе делать комиты в репозитории, да, которые начнут с друг другом конфликтовать. Типа здесь изменена двадцать пятая строчка, здесь двадцать шестая, подожди, это уже строчка двадцать шестая, а двадцать пятая надо поменять. Здесь пару символов меняется и 100, в общем, будет какая-то

прямо запутка с теми змеями, куда что идёт и как и почему. Поэтому придумали ветки. Что такое ветки? Сейчас объясню вам. С помощью одного файла. В нём будут невероятно художественные суперграфики нарисованы. Смотрите, если у нас код, предположим, этот код мы прямо вот так и

напишем, что этот код - это просто шапка сайта. Шапка сайта добавилась, да? Отлично. Это был первый наш комит.

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

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

одним кодом одновременно? С помощью ветвистости. То есть, смотрите, вот здесь на этапе гитнора мы делаем ответвление на блок с бобром. Чик. Блок с бобром. И также на этапе гитгнора мы можем сделать ответвление на блок. Наша миссия.

Вот. Слушайте, ну неужели это не прозене искусство? Посмотрите, зачем эти все невероятные анимации? У нас есть текстовые файлы, можно делать аски анимацию. То есть мы здесь сделали ветку, которую будем в которой будем разрабатывать блок с бобром, а здесь

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

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

каждом комите. Ну что могу сказать? Talk is chip show me deкод. Давайте посмотрим, как это будет выглядеть в гите. Чтобы создать новую ветку, я просто нажму сюда и нажму New Branch.

Назовём её Bever Block. Вписываю имя собственно ветки. Нажимаю Create branch. Он мне предлагает изменение, которые здесь есть: оставить на мейне или забрать с собой в Bблок. Я выберу по умолчанию оставить на мейне. Switch branch. Отлично, я поменял ветку. Сейчас

всё будет понятно, не волнуйтесь. Я могу сразу нажать Publish Branch. Он просто зальёт на GitHub известие о том, что, посмотри, создалась новая ветка. И теперь давайте я добавлю наши новые изменения кода. Чик. Добавил.

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

Защитим бобров вместе. Давайте сделаем первый комит. Комит будет такой: старт бивер блок. Блок. И я сразу сделаю пуш. Теперь покажу вам наглядно про ветки. Вот у нас есть наша ветка Bблок. Если я переключусь в ma, то в мейне у нас нет этого блока и в

истории нет этого комита, да? А если я переключусь обратно на берблок, вот, пожалуйста, вот отличие между ветками.

Старт beвер блок, пожалуйста. Всё. То есть смотрите, то на чём базировалась ветка, именно на этих пяти комитах у неё осталось, и в ней появляется новая ветка. Но при этом, если в ветке main мы сделаем какое-то новое изменение, давайте любое абсолютное изменение, а

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

Комичу. Давайте взглянем на историю. Вот он. Три высказательных знака. Но если я переключаюсь на ветку Bблок, то тут нет этого комита, потому что он взял эту точку во времени, где был Rever Delete Mobile menu, и от неё отпачковался. У

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

этой ветки, которые были после и которые все были созданы ветки, будут перенесены в эту ветку. Ну, мы до этого дойдём скоро совсем. Просто сейчас мы с вами сделаем ещё одну ветку на основе ветки main. Для этого мы переключаемся ветку

main, делаем new branch, и это будет mission block. Mission block. Create branch. Отлично. Создали брен. У неё уже, видите, есть три восления знака, потому что она в эту точку времени была создана. Именно я добавлю код секции mission. Посмотрим, как он

выглядит. Вот наша миссия. Отлично. Кто-то выполнил задание, добавил, значит, эту секцию. Давайте это и закоммитим.

Start mission block. О'кей. Тоже publish брен сделаем. И он сразу паблишет вместе с комитом.

Теперь перейдём в ветку биверблок обратном, что мы в ней, и посмотрим, что нет картинки. Давайте добавим картинку. Это очень просто. Я добавляю картинку. Вот.

О'кей. Да. Вот куolл PNG. Вот видите, бобёр. И теперь всё нормально. Бобёр здесь. Шикарно.

Я делаю picture. Да, ещё один комит. Всё, мы с вами тренируемся, стремимся. Комиты, комиты, комиты. Но в итоговой версии, как вы помните, бобёртом у нас летает.

Интересно, почему? Наверное, потому что были добавлены какие-то стили. Давайте добавим стили. Я даже уже заранее напишу commit message. Это animation. Я добавил код всевозможных анимаций именно вот этой волны и того, что у нас бобёр немножко летает. Это не урок по HTMлю

или ЦСУ. Это знания применимые для всех языков программирования. Поэтому мы не углубляемся в это. Просто добавил какие-то строчки кода. Вот, как можете видеть. Всё, я их добавил и здорово.

Комечу, что добавил анимацию. Тем временем в мишн блоке, в мишн блоке напоминаю, что он здесь человеку тоже потребовалось внести какие-то изменения в стиле, и он их внёс. Давайте так напишу update styles.

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

Предлагая для этого всего воспользоваться интерфейсом Гитхаба. Вот мы перешли на GitHthub. И он даже нам показывает, что смотрите, есть бирблок, такая ветка, что в неё пушнули 1 минуту назад и 52 секунд назад пушнули в ветку Mission Bлоck. И предлагает прямо

сравнить и сделать пулреквест. Чтобы вы понимали, GitHub не мог быть, ну, просто вот как все. Надо было что-то вот эко вот вот необычное что-то сделать.

Поэтому в Гетлабе мы имеем нормальный нейминг же квест. То есть запрос с Мёрж, да, слияние веток. Request то же самое.

То есть запросом слияние двух веток в Гитхабе называется request. Поэтому PR или MR, вот здесь может быть разница, но это одно и то же. Я предпочитаю говорить мge request, всегда говорю смёржить MR и так далее. Никогда не использую

терминологии пулреквеста, пиара и так далее. Давайте не будем поддаваться на это упрощение, когда нажмём здесь кнопку. Всего лишь создадим отдельно.

Переходим во вкладку PL requests. Нажимаем New P request. И здесь смотрим, у нас есть ветка Base MAIN, да, и вот стрелочка, да, в неё надо что-то влить.

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

Ставим биверблок. И смотрите, что происходит. Он сейчас проверяет, возможно ли это смёржить. Пишет, что able to merge, всё можно. Показывает комиты, которые будут смёржены, и дальше показывает код, который привносит этот merg quest. Собственно, код этого блока нового и код стили и вот картинку,

которую он не может ээ показать здесь, но coнг, да, всё нормально. Отлично. Нажимаю create request. Всё, по request созда не не создан ещё. Надо как-то назвать его, пускай будет так называться. Create pull request. Всё, он у нас создан. Он будет висеть и создан.

Шикарно. Мы можем просто взять и смёржить это дело. Видите, конфликтов он не нашёл, поэтому как бы можно смёржить.

Всё о'кей. Поэтому могу нажать merge p request. Нажимаю confirm merche. Подтверждаю. Pull request access val merched. Теперь можем сделать следующее.

Можем перейти в ветку main. И в ветке main, в ветке main нам нужно сделать ещё одно новое действие, которое мы узнаем в гите. Это пулol. Если пуш - это отправка комитов, то пул - это стянуть сервер.

Да, стянуть. Gitup desop. Это делается просто кнопкой. Вот F Origin. Мы можем нажать. Опа. Pull Origin. Четыре комита. Можно запулить. Я пулю.

Смотрим историю. Здесь интересные вещи. Смотрите, когда был reве delete mobile menu, мы сделали comit start beвер block блок, да? Потом мы переключились на ветку main, сделали комит с тремя знаками, а потом всё остальное доделали.

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

запись в истории, что вот этот мёрш был то, что он показывает, видите, что добавилось. Вот что добавилось. И вот что добавилось. Вот он здесь есть.

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

далеко не сейчас. О'кей, давайте небольшой подытог. Что вы только что увидели? У нас был код, да, в основной главной ветке. Мы создали новую ветку, в ней поразбатывали, поразрабатывали, поразрабатывали, никому не мешая. И потом единожды в один момент времени

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

Да. Вот вы тот разработчик, который разрабатывает блок нашей миссии. Вы ещё не закончили. И вам говорят: "Слушай, там сильно изменился.

Подтяни себе его. Подтяни себе его, подтяни изменения, как угодно". Говорят, что вы можете сделать. Мы находимся на ветке Mission Block. Тут можем у GitHub desktop сделать branch и update from main. Нажимаю update from main. Пабам.

One conflicted file. В индексе HTML какой-то конфликт. Ну что ж, конфликты можно решать в визуальном режиме, например, в вашем редакторе кода. И в принципе, мне кажется, все редакторы кода поддерживают разрешение конфликтов.

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

merg mission block, toду, warning, тата. Можно нажать зелёную вкладку resolve conflicts и будет идеальный интерфейс.

Смотрите, здесь он показывает, что у косфликт в файлекс HTML. Мы можем нажать merch строеточим. Что он сделает? Он покажет нам. То есть разницу. У нас есть change mission block, change from main, которые летят, а среднее - это вот то,

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

разрулить. Единственное, что она не всегда делает это чётко. И сейчас она сделала это не совсем чётко. Видите, я могу добавить это зелёное и это зелёное.

И вот он мне ставил, пихнул куда-то не туда. А мне нужно, на самом деле, было это сделать вот так. И видите, я в итоге в центральной колонке могу сам просто переписывать код. Это будет тот код, который есть. Вот я вот тут удалю.

Отлично. А внизу красное- это прямо конфликты. Помните, как я вам и говорил, да, что как так? Он же типа на восемьдесят шестой строке это писал, а здесь типа здесь это написано. Так оно же, ну оно же никак никак что. А то, что

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

делать? Вот, пожалуйста, здесь этот конфликт присутствует. Как мы можем поступить? Можем нажать стрелочки здесь и стрелочки здесь. Он просто поставит одно под другое. Всё. То есть конфликта нету. Типа оставить и то, и другое. И теперь я могу нажать apply.

Он всё это заплал. Смотрим. Опа. All conflict resolve continue merche. И теперь можем запушить этот комит. Теперь мы подтянули главную ветку в mission block. Всё, теперь у этого разработчика есть та версия кода, которая не будут конфликтовать, когда пройдёт время

слияния. Опять же показываю вам отдельно. И для тех, кто более опытный, конечно, это создало дурацкий ещё один мёр комит. Вот, пожалуйста. Которого хотелось бы избежать, потому что опять же у нас история становится какой-то грязненькой, некрасивой, да? Merch pool

request, merch branch main intermission block. Обо всём этом позже. Сейчас мы просто учимся хоть как-то работать с гетом. Дальше мы станем профи Wizard с такой вот шапкой. Прямо вообще супер всё будет хорошо. Давайте теперь возьмём и смёржем эту ветку тем же самым образом,

который мы делали до этого. Предлагаю вам это самому сделать, обогнав меня. New request делаем.

Ветка у нас будет mission block. Create p request. Будет mission block. Create p request. И нажимаем merch p request. Confirm. Merche.

Pull request. Successfully merged and closed. Мы можем перейти теперь в main, посмотреть. Пулим изменения. Помните, да? Четыре комита. Пум-пум-пум. Сколько комитов теперь? И теперь у нас есть и первый блок, и наша миссия. Вау! Шу! Ещё раз была одна ветка, распачковалась, да, на

две. Они всёвсё сделали и постепенно слили одну ветку и другую ветку. Всё, теперь у нас одна ветка с полным кодом.

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

main есть такоя вот странная штука. View stash changes. Могу показать ш. И там в стеше тот самый бранш, где я вам всё супер с помощью аски символов рисовал, как же оно всё-таки работает. Смотрите, этого файла сейчас нет в проекте, но я

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

Пишем в поте лица наш код на любом языке программирования. C++, Go, Java, неважно. И в какой-то момент что-то в коде сломалось, и вы такие: "Блин, наверное, это из-за меня, но надо точно удостовериться. Возьму-ка я и засташу свои изменения". Как это делается здесь?

Я просто нажимаю вот на верхнюю строчку, где changed files. Ну, видите, могу нажать либо discard all changes, значит, отменит их просто все, они всё в утиль улетят, либо Stash All Changes. Они такие: "Опа!" и временно скрылись.

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

полезно, когда вы не понимаете, то ли БК или фронт сломался, да, и что не с вами связано, север там не отвечает, что-то такое, то ли это всё-таки вы накосячили.

Поэтому прикольно свой ку-то откатить, посмотреть, точно ли это не из-за него или это из-за него. А, о'кей, хорошо.

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

main или вот я переключаюсь на ветку mission block, мне забрать их с собой? Могу забрать их с собой. Вот забрал.

Давайте обратно их верну на main. Опять заберу их с собой, то есть. И теперь смотрите, если, например, я переключусь на другой блок, оставив мои чинжи, да, в мейне, остави их тут, не беря с собой, то при печении обратно на мей они будут

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

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

нам точно не нужны все эти изменения, то можем всегда сделать discard changes. Are you sure? Yes, I'm sure. Всё. А принте мы пока оставим. Причём давайте, э, пускай оно будет у нас засташенное висеть для будущих объяснений, которые нам скоро понадобится. И мы плавно

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

проекты. Давайте сделаем ветку, в которых будут наши projects, и сделаем ветку, где будут facts, да, факты о бобрах. О'кей, погнали. Делаем это вместе. Лишняя практика для вас. Если кому-то это что-то наскучило, то можете, в принципе, а проматывать или на

ускоренном посмотреть. Итак, сделаем, не знаю, фактS блок, да, фактS блок. Ветку сделаем create branch. О'кей, всё, даже запушим эту ветку, пускай она будет там лежать у нас. Возвращаемся обратно в main и делаем ещё одну ветку. Эта ветка у нас будет projects projects

точка. Ой, блок. Угу. Отлично. Создали ветку Project Block. тоже запушили её. В ней давайте уже добавим частично код проектов. Э, значит, где у нас тут? Так, вот я вставил секцию проектов. Смотрите, что у нас получилось. У нас есть наши

проекты. И пока только две карточки, да? Сделал специально не все. О'кей. Я делаю комит, в котором будет написано, что add не давайте, как как всё у нас делается.

Start projects block. О'кей. Пушим. Origin запушили. Тем временем, тем временем в факт, факт, кстати, у нас я букву ти пропустил.

Какой-то факт блок получается. О'кей, здесь ничего такого нет. И я только собираюсь разрабатывать, и мне мой коллега говорит: "Слушай, я там уже начал разрабатывать следующий блок, да, чтобы, ну, не было конфликтов, чтобы ты нормально его вставил. Подтяни себе

изменения. У меня пока там один комит. Можешь его черепикнуть. Черепикнуть. Мы такие: "М, мы же профессионалы, мы просто визарды гита, мы знаем, что это такое". Всё очень просто. Мы идём в ветку, которую нам указал человек.

Указал онм project блок, да, что в ней работает. Мы находим это commit. Вот start project block, да, и мы делаем вот так вот правой клавишей и cherrypck commit. Он нам предлагает chrip commit to a branch. В какую бренчу-то? Вблок,

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

дополнительных полуреквестов каких-нибудь, не подтягиваем изменения туда, создавая лишний этот коitм мge, просто чисто аккуратно берём комит и перемещаем. Периодически в работе вам это 100% понадобится, когда нужно небольшой кусочек функционала перетянуть себе ветку и с ним разработка пойдёт плавнее. Можно будет просто легче

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

Всё, вот у них теперь история выровнялась благодаря этому переносу комита. Отлично. Видите, всё просто. Всё просто. Чем теперь, прежде чем углубляться в гиit, нам нужно разобраться с ещё одним концептом, который называется rebase. С ним мы тоже разберёмся в визуальном режиме, а потом

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

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

Соответственно, давайте я в двух словах это сделаю. Вот переключимся на, например, на факсблок, да, я могу сделать new брен. Видите, он меня спрашивает, на основании мейна делать или на основании факблок. Давайте на основании факблок сделаем.

Только я сделаю факт с блок 2. Вот такая вот create branch. Всё, у меня есть новая ветка факт блок в 2. Она основана на ветке факт блок.

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

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

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

Давайте посмотрим, что такое реbйс на нашей суперсхеме. Итак, её сначала я выровняю быстренько. Перемотает этот момент.

О'кей. От блока наша миссия. Мы с вами сделали новую ветку, и в неё мы уже успели сделать а старт.

Старт наши проекты. Вот уже успели начать делать. Теперь я что предлагаю вам сделать? Мы с вами сделаем продолжение некоторое. То есть добавим э карточку. Карточку там две у нас есть.

Давайте карточку три добавим, третью и просто добавим ещё карточку четыре. Вот. То есть у нас будет ещё два комита.

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

у нас получится так, что а есть в одной ветке три комита, но параллельно ей делались другие комиты. Теперь, если мы будем вливать эту ветку в нашу ветку main, произойдёт Merger quest, который мы уже делали. Мы уже с вами это видели.

в истории комитов, когда делали три восскательных знака, да, что они объединились, что был startт BL, start mission block, это picture. Это всё оно объединилось и встало по времени, как оно выстраивалось. Вы это могли видеть буквально там сколько, 10 минут ролика

назад. Хорошо. А и создался вот такой вот омерзительный комит. Merge p request. Потом ещё бренчи другие мёржили, тоже были мержи. Ещё мжкве quest другой. В общем, всякое всякий ужас. Как работает? Он помогает от этого всего избавиться. Давайте рассмотрим

самому слово rebase, да? То есть перебазировать, да? Перебазировать. В чём суть? Объясняю. Давайте из этимологии пойдём, почему команда называется BAS, а у вас всё встанет на места. Значит, сейчас эта ветка бейзится, да, базируется на вот этом комите. Отсюда она была отпачкована.

- это перенести её базу. То есть мы можем вот так вот сделать, сдвинуть её сюда. То есть не мёрзть всё, да?

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

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

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

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

он делает, когда нужно ребейзнуться. Вот смотрите, у нас ситуация вот такая, да? То есть он отсюда отпачковался. Мы когда делаем реbйс вот этой ветки в ветку main, то есть в эту ветку, опять же, ребейс может быть между другими разными

ветками, тут просто для примера. При ребейзе что мы делаем? Он переключается на последний комит этой ветки. То есть мы переключились с этой ветки на эту и встали на последний комит. И начинает комит за комитом постепенно проигрывать вот эти комиты. Типа этот применил, этот

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

поменяются. Это будут как бы новые комиты для системы. Почему новые комиты для системы? Потому что комит себе хранит своего родителя. Родители заменились, соответственно, комит уже другой. У него уже другой родитель. Всё.

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

Вот. Чик-чик-чик. И видите, всё, выстрелов. То есть была витвистость некоторая, да? И мы чик сдвинулик, всё в прямую линию сделали. Соответственно, что чего мы добиваемся? Мы добиваемся того, что у нас ровная история изменений идёт. Абсолютно абсолютно ровная. Да. Мы

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

Вот. Кроме того, типа, где был мёр, ну насколько она нужна, не знаю, не нужна.

О'кей, всё, погнали делать. Значит, этот текстовый файл мы уже с вами классный. Мы можем засташить его. Засташили.

Отлично. Теперь давайте здесь, пока мы в ветке main, мы добавим как раз-таки код футера. Да, погнали. Добавим код футера в самый низ. Вот код футеры. Я его добавил. Только давайте разобьём его на два комита специально. Вот мы таким

образом вот этот пока частично код поставим у себя. Мы пишем с вами, делаем комит startр, пушим, а сразу же добавляем назад код, который я подудалил. Тут, видишь, соцсети всякие добавились. Facebook, Twitter, Instagram наши суперорганизации по охране бобров.

И пишем, например, end footter, то есть второй комит. Всё, зандили. Теперь я переключаюсь в project. И здесь мы добавим с вами карточки, которые мы тогда удалили.

Так, вот добавили одну карточку. Смотрим. Да, их стало три. Как договаривались с вами, делаем add 3.

Пушим и давайте добавим четвёртую карточку. Добавляем четвёртую карточку. Так, вот она, четвёртая карточка. Центре реабилитации бобров.

[музыка] Карф добавил. Теперь давайте ещё раз, перед тем, как мы начнём всё это жёстко ребейзить, посмотрим, что мы сейчас имеем.

Сейчас мы с вами имеем вот такую картину. От блока нашей миссии отпачковались. У нас был старт наших проектов. Добавили карточку три, добавили карточку четыре.

И здесь вот разница. Теперь мы будем ребейзить ветку с проектами с мейном. Так вот, чтобы было вот так. Всё. Как мы это будем делать? В приложении GitHub Desop. Переключаемся на project. Значит, мы оставляем наши changджи здесь в стаж. У нас есть в

складка branch и есть rebase current branch. Нажимаем Rebase current branch. Выбираем ветку main. This will update project block by applying its three commits on top of main. То есть это the updated project blockр commitв наверхмейна. То есть наверх

мейна. Видите? А уже закрыл. То есть наверх мейна, что означает? Что у нас было ещё два комита после отделения, да?

И мы сдвигаем, то есть наверх добавляем. О'кей, нажимаю rebase. Вы готовы? Нажимаю I to want rebase. Да, мы у нас есть конфликт. У нас есть конфликт. И видите, потом мы можем сделать continue rebase. Как я вам говорил, это какой-то конфликт возник.

Мы его должны поменять и продолжится. Почему? Потому что он постепенно применяет по одному комитику. И мы смотрим, решаем конфликты. Итак, перешли в webшторм, нажали кнопку, нажали.

Сейчас посмотрим, что у нас здесь. Что-то вообще неважное, а зато вот здесь важное. Здесь футер, здесь project. Я говорю, что нужно и то, и то оставить. Всё, apply.

Так, теперь смотрите, он попросил меня сделать какой-то commitмеage. Сейчас вы увидите, что это такое. Я просто нажимаю, нажимаю continue rebasing, потому что start project block меня устраивает название.

Всё, нажимаем continue. Rebase successful. Rebased successful. Всё, посмотрим на историю, да, что он предлагает мне. Вон видите, там пять отправить, три получить, что-то в этом роде. Что тут произошло? Он мне сделал fotтер and footter, да? То есть он

теперь они есть в этой ветке, да? Потому что он историю переписал, как будто бы они начались с них. Дальше сверху идут комиты. Как было написано, он топ, да, на топ, то есть startфтер. Fotter - это есть топ мейна. На него пошли start

project. И что есть интересное, смотрите, вот project block. Помните, у нас высвестилась такая штучка про конфликт.

Я написал конфликт, но он не создал отдельный комит, который решает конфликт. Он start project блок, видите, в этом комите добавил уже всё, что нужно, потому что футер здесь уже есть, да? То есть rebase он чётко помогает нам сделать историю, выпрямить её. Теперь мы

нажмём Pull Origin. Так, после получается синхронизаций всего это дело. репозиторий. Всё, всё у нас обновилось.

Посмотрим, что у нас там в репозитории. Давайте поставим. Получается, что это у нас? Project block, да?

А this branch 3 commit head of main. Ну всё отлично. Она просто commit head of main и всё имеет, не более. Переключимся в main. Всё нормально, всё клёво. Давай теперь попробуем сделать merge request comp request. Окей. Project block create

request. Прямо в мей. Да. Что требуется? Просто посадить наверх три комита. Да. РЖQUст. Всё, я мёрз. Тем временем хочу залететь в ме.

Мы смёржили иреквест закрылся. Принимаем изменения. Ну и вот смотрите, у нас есть чистая история. Start footter and footter start project block car 3C car 4. Всё здесь в ветке main.

Соответственно, что Rebase позволяет всё сделать ровненько. А, кстати, надо же визуал показать, поэтому вот смотрите, наши проекты, наши проекты. И вот, пожалуйста, Bergгаard. Всё здесь.

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

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

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

блок. Ну фа. О'кей, о'кей. FS, да, делаю для неё пореквест. Вот она на один комит впереди э мейна. Здесь добавляется просто блок фактов, да? Я создаю request.

И теперь я в целом могу его смжить, да, вот когда он проверит ability to merge.

И смотрите, теперь, если я буду это всё смрживать в интерфейсе GitHub и нажму на эту кнопку, то произойёт вот что. Create merge commit. All commits from this branch will be added to the base branch with the merch commit. То есть он

сделает merch commit всё-таки. То есть мы всё делали, чтобы этого не было, но он сделает его. Дальше есть другой вариант скch. Что такое сквош? Тут всё просто. Сейчас отдельно тоже посмотрим.

Можно взять вот у вас четыре комита есть, и вы такие: "Что историю раздувать? Все четыре комита ядел блок фактов". Ну ладно. И можно все четыре комита сделать в сквош. Вы превратите в один комит, да, просто для удобства истории. Да, у вас будет история из

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

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

На секундочку. И дальше у нас есть вариант rebase and merch. The one comment from this branch will be rebased and based branch. Давайте попробуем.

Именно так сделаем. Rebase and merch. Нажимаю confirm. Rebase and merch. Так, погнали теперь ветку main и попробуем посмотреть, что у нас там новый новенького. Один комит.

Ну всё, вот он факт. 4 минуты назад пролетел, да? Угу. Предыдущий мёрш - это зафакапленный как разтаки мёрш. Таким образом, вот видите? То есть, короче, сделал вот здесь как надо, всё получилось хорошо. Нажал бы просто мgeш, я получил

бы вот такой мёж пореквест. И какой-то весь смысл ребейза как будто бы убит. Да, ну не убит до конца, но история некрасивая. Некрасивая. Теперь насчёт сквоша. Смотрите, я перешёл в ветку фактS block. О'кей.

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

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

четвером их завоём и сквошним. Скш комит вот summary. А плюс 1 2 3 4 факт, да?

Скш комит скш процес чик. Всё, вот они все стали одним комитом. Мы должны сделать пуш чпонькс. Всё, теперь это один комит. В общем, у нас было четыре комита, два запушенных, два незапушенных, и мы все их вместе сделали в один комит и

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

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

Код мы можем получить, видите, написано clone, потому что есть такая команда Git Clone. Мы сейчас ей будем ей пользоваться. И можно склонировать по HTVPS, по SSH, как раз-таки тому самому супербезопасному варианту. И GitHub SLI - это как раз-таки просто

вспомогательная программа для Гитхаба. Мы не будем её рассматривать, это нам не нужно. Раз уж консолью, то всё по хардкору, всё по-нормальному. Итак, начнём рассматривать с https. Я взял, скопировал то, что он мне подсказывает в этот путь.

И как мы это будем делать? Этот терминал у меня открыт слева. Я сделаю следующим образом. А если вы не знаете команд, то CD - это change directory. То есть поменять директорию. Я хочу перейти в а рабочий стол, и там я сделал для вас

папку git examples. Git examples. Вот в ней мы будем творить всевозможное безобразие. Теперь, значит, тут пишем Git Clone, команда Git Clone, да, и просто вставляем вот этот вот HTP штуковину.

Нажимаем Enter. Он просит у меня usernрame. Смотрите, неважно, я специально введу неправильные username и password. И вот что мне напишет, что поддержка аутификации по пасворду, по паролю, да, она уже давно removed. Она 13 августа двадца первого года. То есть это прошлый

век, дружище, прошлый век, да, у тебя там она failed, потому что неправильно вёл логин пароль, но задумайся, задумайся, это прошлый век, давай по SSH. Ролик и так очень большой. Я не буду говорить про шифрование, что зашключи, только скажу пару вещей, что

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

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

по ним всё о'кей, отдавай код без вопросов. Давай сначала попробуем, не имея никаких SS ключей, скопировать всё это. Я выбираю вариант SS. Вот он мне показывает GitHub, тампыры, всё вот, что мне нужно. Я пишу то же самое: Git

clone. И вот так вот он пытается склонировать. Потом мне говорит, что permission dened public key, то есть видите, публичный ключ есть. Публичный ключ, есть приватный. Вот, в общем, публичный ключ не подошёл. Да, давайте сообщим Гитхабу наш публичный ключ,

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

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

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

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

правильно? Чтобы вы хоть что-то понимали, что вообще происходит. Дальше - C. И тут пишем свой email. У меня будет вот такой email. Как вам мой email? Вот.ru. Вот. Вот такой вот.

Давайте сделаем чуть поменьше Shift, чтобы всё влезало. И я после этого вот закрытие кавычки нажму Enter. Generatic public private ID 255 Kpayer. Вот он. Ко сделает нам пару ключей. Смотрите, он предлагает это поместить вот в такой файл. Давайте

сделаем всё-таки ещё больше. Вот так. Вот в такой файл user ачерняков sштпрестап. Я вам предлагаю взять то же самое, но чуть изменить.

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

пишет туда, куда он сохранит. Если я просто нажму Enter, то есть по умолчанию, но я могу вместо этого ввести. А куда дальше? Он предлагает мне ввести пасфразу, да, для этого просто нажимаете Enter. Никакой пастфйз нам не нужен. Нам хватит самой безопасности

этого ключа. Всё, у нас такой причудливый рисунок получился. Вот что-то он там сгенерил себя. И теперь пишем следующие строчки. Это опять же тоже можно всё найти в интернете, но у вас это будет здесь видео. Ава SS Agent.

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

пишем следующую команду Sad AD и добавляем вот наш новыиспечённый файл. Он был там в конце у нас было нижнее подчёркивание GH, да, points identity edit. Всё, отлично. Теперь нам нужно взять этот ключ публичный и сообщить его Гитхабу, как мы это будем делать. Есть

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

ID 25519, да, GH, да, всё супер он. И нам нужно взять вот точка pu, то есть публичный ключ. Нам надо увидеть, как выглядит.

Вот так он выглядит. Вот эта строчка с безумным ключом. Это вот оно. Теперь мы просто идём в GitHub. В гитхабе мы берёмпу settings.

В settingсах у нас будет SH GPG ключи. Можем сделать новый SS ключ. Добавить сюда этот ключ. Я вам так палю спокойно, потому что я его удалю после записи видео. Понятно? Вот так вот. А дальше можем ввести, давайте он будет

называться просто имя, чтобы его отличать. MacBook это сашки. Он просит GitHub Mobile, я беру свой телефон, потому что на телефон в GitHub мобайле может прийти такая такой род авторизация. Я должен здесь подтвердить, что действительно какой-то шключ ввожу, потому что секюрность должна быть

секюрной. Понятно? Вёл вот я это число. Опа, всё сразу всё само сделалось. Отлично. Теперь смотрите, что я делаю.

Возвращаюсь назад, нажимаю кнопку стрелку наверх. Я возвращаюсь к этому. Git clone gitub. Вот наш ССШ команда.

Нажимаю, он думает чик. Но при этом он всё скачивает. Смотрите, всё скачал. Теперь что можем посмотреть?

Вот, э, lssдержимой папки. Вот BER Defender у нас есть. Всё, он склонировался весь код отсюда. И вам это понадобится, потому что, ну, все репозитории будут, разумеется, приватные. Поэтому вы попадёте там на работу или вы уже на работе, но делаете

это всё через GitHub despop или с помощью https. Имейте в виду, что можно так и саш ключ сделать, закинуть в свою учётную запись в вашем Gitхабе, Гитлабе, неважно, и всё будет работать. Кстати, про GitLab. Ну и давайте сразу

посмотрим, как это делается на Гитлабе. Я зашёл на GitLab, но не на обычный Gitlab, а на Gitlab.ru, потому что это наш, собственно, GitLab, который поднят для нужд менторинга.

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

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

Гitlлабе смотрим. Значит, у нас есть Edit profile, там есть s. Вот сюда добавляем новый ключ. Можем его просто ещё раз скопировать, потому что там будут валидаться, он не пропустит. Простой отключу. Он даже называет его сразу, видите, тайтм последней строкой. И можем

сделать add key. Всё отлично. У нас теперь новый SH ключ добавлен. Вот тут на данный момент третий. На мене мы практикуемся с гитом, настраиваем все ACD пайплайны и, в общем, всё деплоием там. Фам-фа-фа, у нас там кружочки и так

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

GitLab, GitHub, BitBcket или какой-то ваш самоопальный Git, неважно. Поэтому GitHub desktop работает и с Gitлабом тоже. Так что расслабьтесь. Прога классная, удобная, очень сильно дружелюбная. Так, ну теперь мы начинаем постепенное путешествие в GLU гита.

Также будем идти быстро и постепенно наращивать темп и накал тех знаний, которые мы знаем. Как вообще создать GitHub репозиторий вообще? Что такое GitHubitory? Это тупо папка, внутри которой есть другая папка, которая называется точкаit. Вот сейчас будем это смотреть. Значит, смотрите, что я

сделаю. Я, во-первых, нахожусь сейчас в Git examples папке. Вот на всякий случай она у меня тоже открыта здесь в проводнике, чтобы была. И в ней я могу сделать так. Makear MKIR такая команда.

Аgit назову. Вот видите, создалась папка git. Да, команда не соврал это и делает. Перешли в testgit. И тут мы можем сделать git init initialized empty git repository. Вот здесь. Отлично. И видите, даже написал точка git. Значит, в чём прикол? Если

откроем test git, видим, что там появилась папка тоggit. То есть всё, всё, что отличает обычную папку от GitHub репозиitor, наличие папки то.

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

Значит, во-первых, вы можете заметить, что здесь почему-то нет ээ тоit файла папки. И обычно скрывают идшки. Я вам покажу, как в вебшторме её показать. А то, какая она показывается в других видшках, это уже надо вам загулить будет. вашей любимый editor file types

ignore file and folders. И вот обычно она здесь лежит как бы как игнорируемая. Вот точка git. Можем её удалить. Я потом это верну, потому что действительно она никому не нужна, но нам будет нужна для наглядности. Вот мы можем шик

посмотреть. Вот вся информация про Git репозитория лежит вот тут. О'кей. Хорошо. Теперь, значит, смотрите, мы создадим новый, пускай уж будет HTML-файл, неважно. Index.html.

Отлично. И в него добавим что-нибудь из нашего соседнего проекта с бобрами. Просто чтобы было просто, чтобы какое-то наполнение было. Вот hero action. Всё, мне достаточно будет.

Просто добавлю вот her action. Всё, теперь какое-то наполнение есть, какой-то код, в котором можем работать. Скажу вам, что у файлов в гите есть три состояния. Это untracked, staged и tracked. Ну, то есть закомиченные. Итак, разбираемся с первыми, с Untract. У Git есть такая

команда Git status, чтобы посмотреть статус вообще файлов, что там происходит. Открываем его и видим, что у нас есть антре файлы, это DC Store и ID.

И по факту, по факту тот, который изменённый файл, вот сейчас вот INDК HTML, он тоже untracked, потому что, ну, мы с ним ничего не сделали пока ещё. Это просто те файлы, которые, если мы сейчас их удалим, то всё, они пропадут

навсегда. Они не успели попасть в историю гита. То есть антрек, да, они антречены, за ними никто не следит. Вот если даже переводить так впрямую.

Давайте с вами проведём маленькое упражнение. Вот смотрите, вот эти два файла вот тоcstore. Они нам будут мешать, что бы мы могли бы с ними сделать, чтобы гиit их игнорировал. Подсказка, конечно, сделать git игнор. И давайте я просто сделаю git

игнор на этот счёт. Всё, теперь смотрите, я вызвал gitстатус ещё раз. У нас вот есть R красиво модиfй, да? Git ignore и index. Всё, чедж, которые должны быть закомичены.

Хорошо. Второе состояние - это staged. И тут, кстати говоря, мы приходим к вопросу, которые часто задают, что такое индекс. Вот часто слышат, да, что есть какой-то индекс в гите, что-то такое. В общем, stage area и индекс - это одно и

то же. И индекс - это промежуточная область в гите, где хранятся подготовленные файлы, которые готовы к комиту. И как же файлы перевести в состояние stage? Как добавить их в индекс? Есть простая команда git add. Тут мы пишем тот файл, который

можно перевести. Например, индекс индекс html добавил. Давайте ещё раз сделаем git status. И мы видим, что модий у нас остался только git ignore. Чтобы добавить абсолютно все файлы, мы можем использовать git add и ставим точку.

Точка просто рекурсивно пройдёт в и вообще все файлы, которые были модиfy, добавит в staж. Всё, ещё раз. Git status. Всё, у нас теперь есть два файла новых. Отлично. Теперь осталось перевести их в третье состояние, то есть трек. Их надо закомитить, то есть

сделать комит. Как делается коit не в GitHub desktop, а в консоли. А вот сейчас мы посмотрим. Но сначала мы откроем GitHub Desktop, чтобы он визуально нам показывал. У вас было больше понимание о том, что же происходит, когда мы вводим эти самые

команды. Вот я открыл GitHub Desktop. Он не становится меньше, поэтому извините, это минимум. Вот у нас есть два файла, да, change files. Вот они добавлены.

Шикарно. Как делать коit? Пишу git commit. Неожиданно, да? Дальше - m - это message означает. кавычках могу написать message э my awesome commit, как вам такое, мой восхитительный комит. Нажимаю Enter, они добавились, видите, create mode, git ignore, все дела, всё, они добавились.

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

аккаунт его запихнёт туда и всё это запушит. Соответственно, пушить - это уже отдельная тема. Это комиты уже созданные. Куда-то заливать на другой удалённый сервер. А мы можем нажать history и увидим, что вот my awesome commit. Всё, коit создан. Вот так всё

просто содаётся. То есть мы берём, делаем git add, то, что нужно в коit добавить. Соответственно, считай вот как чекбоксы мы здесь всё выделяем, да? То есть добавляем. Дальше мы делаем git commit. Всё, оно полетело внутрь.

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

комита вы могли видеть, что есть какой-то F5 961 и так далее. Вот он тоже здесь написано F5 691. Что же это такое, в конце концов? Это уникальный идентификатор хэш. Опять же, это не про шифрование, это не про хэширование, да,

лекция, поэтому я не могу вам тут полностью рассказать, что такое хэш. Но в двух словах, хэш - это результат хэш-функции. Вау, да, странно, да?

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

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

поговорим. Смотрите, давайте попробуем сделать хэш из файла index HTML. Да, смотрите, у нас есть такая утилита SHA сам, да, это как раз-таки хэш. Здесь дальше можем указать, какой именно алгоритм хэширования. И у нас Gitthub использует, по-моему, ша, но это

неважно. Там дальше ша 256 идёт, по-моему. Неважно. Это просто разные алгоритмы хэширования. Как же так же, как вот с созданием массаж ключа говорил, что мы выбирали алгоритм. Также здесь есть разные алгоритмы, да. Вот здесь мы возьмём Ша1, А1 и дальше путь к файлу. Вам не нужно

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

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

То есть это сколько это там, не знаю, дай бог, 1% файла я поменял на, скорее всего даже меньше. Ну а хэш полностью другой. Вот 0,3 Е7 FD. В общем, он абсолютно абсолютно другой. То есть хэш - это про уникальность. Вот у каждого

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

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

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

Вот так вот. И мы его закоммитим. Как это делается? Давайте, помните, как я делаю gitстатус. Мне не обязательно нажимать. Я так понимаю, что там есть незакомеченное, поэтому Git Ad делаю.

Всё сделал. Git commit. Э-э, message file. Всё, я добавил mdфаilй. Тут, кстати, смотрим, вот коммит новой появился. Всё, отлично. У меня есть два комита. Теперь, как и сказал ранее, каждый комит - это снимок вашего репозитория на момент создания комита. То есть это не

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

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

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

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

символов, но можно и по полному хэшу обращаться к комиту. Что мы можем сделать с комитом? У нас есть такое такая команда catфаile, git catфай. Дальше пишем пишем вот хэш commit. Написали хэшмета. Таким образом можем посмотреть, что вообще в

этом комите. Есть его дерево. Сейчас объясню, что такое дерево - это папка, образно говоря. Есть его парент. Парент у нас его, как вы понимаете, что это ролиский комит, правильно? Его автор есть вот Ай Черняков, да, и есть комитер

тоже А Черняков. И тут написано, собственно, а дата в формате таймте, даже с вот моим часовым поясом п 0. Вот сообщение комита. Мы можем сделать с git catфайл и взять туда любой другой хэш передать, потому что всё есть файлы.

Кстати, вам нужно просто это понять, да, что всё в гите есть файл. Git создал Linux Storws. Он же создатель, соответственно Линукса операционной системы. И в операционной системе Linux есть парадигма, да, что всё есть файл. И как вы думаете, он перенёс своё детище

на систему Git? Да, перенёс. Потому тоже здесь всё есть файл. Значит, также можем взять файл к хэшу три, обратиться и увидим, что в этом три, да, собственно, в содержимом комите есть все файлы. То есть мы вроде бы с вами закомимтили

только PMD, а там есть всё: икс, и G иignгнор, и, пожалуйста, всё можно посмотреть. А вот блоб, да, сейчас по с вами поговорим про то, что такое блоб. Я сначала могу взять этот PMD, также взять его ш, сделать gitcatфайл

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

Соответственно, теперь плавно подойдём к блобу, но сначала я в визуальном опять же режиме покажу вам эту папку Git. В чём её прикол? В папке Git есть много чего. Есть gitookки, потом в будущем научите им пользоваться. Это что делать

там до комита, после комита, перед комитом и так далее. Всякие инфо, логи, это всё нам понятно. Нам нужно вот этот файл, объекты. В объектах есть такие причётливые папки 6B, 09 25 51, что-то такое. Теперь давайте попробуем найти совпадение. 25. Смотрите, 25 6,

смотрите-ка, где-то было 6B. Вот 6B и так далее. То есть первые два символа ХШ - это под папка, где лежит. А дальше вот такая штука пошла. Видите, здесь лежат, что мы не можем это посмотреть, потому что просто бинарные данные. Всё, там у

нас внутри лежат нолики, единички. Соответственно, как на самом деле под капотом работает гит? В гите есть несколько основных типов объектов. Это объект блоб, объект 3, объект комит. И между ними можем жонглировать, там ещё другие есть, но они не столь важны. И

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

вычисляется хэш. Хэш, нужно для чего? Для адресации, чтобы понять, где в блобе это там он лежит. Вот, вот он лежит, пожалуйста. Где этот блобчик лежит? В какой папке и в каком там дальше бинарном файле. Есть три. Три - это

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

создам какой-нибудь, не знаю, там, index.js. JS. И вот у меня, соответственно, будет индекс JS-то будет один блоб, да, с хэшом, но сама папка src это будет как раз-таки объект 3. Она провест в объект 3, в котором будут храниться хэшики его содержимого, либо

других три, то есть вложенных папок, либо хэшики конкретных файлов, уже как файлы indдекс HTML. Ну и у нас есть объект комита, который ссылается также на какой-то там три, на роильский комит и так далее. В общем, у нас есть некий

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

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

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

Вопрос мой был такой: "Так, это что получается? Вот я сделал индекс HTML, дописал в него отдельную строчку, и у меня не хранится изменение этой строчки, а хранится два файла: весь индекс HTML и весь индекс HTML вместе со моей

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

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

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

из этих блобов. Вот чем на самом деле гита и на самом деле и занимается. И ещё что важно в этом блоке, что хотел, чтобы вы понимали, что это просто структура папок то. Гиit, которая от нас скрыта. И пускай будет скрыт, нам толаза-то не

нужно, но просто тут никакой магии нет. Абсолютно просто здравая и хорошая идея. Теперь погнали поговорим про ветки.

Значит, я введу команду клиarр, чтобы всё очистить, и поговорим про ветки. Так, сначала у нас там есть одно новое изменение srcдекс, да? А давайте сделаем gitш, да? Чик. Опа, всё застшилось, видите? Gitsш. Ещё одну команду узнали, как она пишется. Хорошо, теперь создадим

новую ветку. Git. Всё просто вообще. Git branch и название ветки. Конечно же, конечно же. Пиу создали ветку, смотрим, отсчитываем мы на мейне. Упа. А мы просто создали ветку, мы не переключились на неё. То есть если в GitHubскоcop мы создаём

ветку и сразу на ней оказываемся, то здесь не так. Соответственно, а там это одна кнопка, здесь у нас несколько команд. Хотя при этом есть команды, как создать и сразу переключиться. Но смотрим, всё по порядку. Git checkout, да? То есть попросить счёт уйти.

Checkout pew switch to branch pe git brch lк main и pw сейчас на пи. Отлично. Хорошо.

Вот мы переключились на ветку пи. И давайте теперь посмотрим, где же могут храниться ветки. Что такое ветка? Как вы думаете, что может быть веткой? Это в нашей папке гит есть ревс. И тут у нас есть heads. И там есть пиу. Всё, пиу.

Попробуем открыть. Что мы видим? Какой-то хэш. Фу. Давайте посмотрим, что за хэш. Мы же с вами же вообще крутые.

Catфile, да? Точка p. Посмотрим на этот хш. И что у нас такое? Этом файл. А, так это что? Внутри ветки хранится просто хэш последнего комита, с которого она была создана, получается. А, вау, никакой магии опять, представляете?

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

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

Вот таким образом создался файл po.txt с надписью, то есть эхо, как бы эхо, да, вывести вот этот вот знак больше, который здесь является именно стрелкой, да, начинает перенаправить вывод в во что? В новый файл. То есть такая вот

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

Соответственно, у нас есть какое-то разночтение, да, это у нас ээ не застйжено всё, поэтому давайте поместим это в индекс. После этого сделаем git commit m том m expрименs.

О'кей, сделали комит. Да, всё супер. Теперь смотрите, я сделаю git checkout main. В Gitch main я сделаю ещё один такой файл. Просто смотрите, сейчас вы поймёте, что я делаю. Другой файл сделаю и хочу сделать, собственно, Git и Experiments 2. Пускай будет сделал новый

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

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

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

будете доходить, вы разберётесь и без меня. Там ничего такого прямо суперсложного нет, просто не очень удобно и всё. Особенно конфликты решать, там что-то выбирать. Зачем нам это нужно? А я вам хотел показать другое. А гита есть такая команда Git Log. И у неё

есть куча, абсолютная куча вообще параметров. Вот, давайте сделаем oneй. Сейчас всё опять же поймёте. Граф и decorate и ещё и all. Да, да, отлично. Оно, смотрите, он мне показывает комитики и пытается нарисовать граф. То есть здесь слишком маленькое дерево у нас, но

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

есть э у них хэши. Попробуйте потом на каком-нибудь своём проекте ввести вот этот вот gitlog в онлайнграф decorate all, посмотреть, какая там будет великолепие. Давайте тоже сотрём всё. И я вам хотел рассказать про config. Значит, что такое GitCfig? Gitig - это некая структура

данных, ключ значения, на которую опирается Git при своей работе. То есть у нас есть глобальный конфиг гита на уровне Cстемы и локальный на уровне вашего репозитория. Вот смотрите, например, есть Gitcig. Можем у него взять команду GET и взять, например,

user.name. Получим Иван Черняков. При этом, что интересно, мы можем задать, э на уровне локального конфига любую фигню. То есть можем взять add, сделать а local, взять то же самое user.name и сделать его ратата.

Всё, он сделался. Теперь, теперь что хотел вам показать из прикольного. Мы берём какой-нибудь файл, опять создаём вот такой вот. Да, давайте теперь по 3 сделаем. Создали, да? Мы делаем git add, мы делаем git commit а то m значит

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

Сделаешливый комит и всё. То есть это это просто мм внутри файла, как я вам опять уже сказал, да, всё время толдычу это, что гиit - это всё про файлы, всё есть файл. В этом файлике мы просто написали чужое имя и всё, и кого-то

подставили. Не, ну конечно, не так, но вот видите, ротата какой-то. Дальше, так как Git Config - это тоже файл, открываем Git, ищем Config. Смотрите-ка, вот он, пожалуйста, nameратата.

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

добавит новую строчку. Вот могу вам доказать. Видите, новая строчка добавилась. Соответственно, у нас опять же есть для комита что-либо. Git мы сделаем и сделаем git commit test name 2.

Видите, всё другое имя. То есть это просто опять же вот такая штуковина. Если я эту секцию удалю, а и сделаю, давайте ещё раз то же самое git commit ээ и сделаем getomit test name 3.

То всё, он возьмёт просто глобальное глобальное значение с глобального конфига. Иван Черняков. Всё. Вот что хотел сказать про гит, потому что если вы когда-то сделали какой-то свой супер аннигилятор 3.000 ник и пришли на работу и вас комит идут с ником Суперннигилятор

3.000, вам могут сказать: "Слушайте, а кто такой Супернигилятор 3.000? У нас вроде Петя устроился". И вас попросят: "Слушай, поменяй, пожалуйста, в гимя". Э Пётр Васильев, не знаю, да? И вы знаете, как это сделать? Вы просто ведёте команду, просто сделаете гит.

config add да global user.name и сделайте пётр Пётр Пёрт. Пётр Василиев. Всё, у вас будет Пётр Васильев, и все будут довольны, что вы вообще чётко всё называете своими именами. Так, продолжаем разбирать вопросы, которые были заданы на менторинге. чтобы ролик

получился максимально плотным. Значит, что такое head? Вы можете часто видеть такое, опять же. Head, по факту это просто указатель на последней комит активной ветки. Почему? Доказываю вам.

Вот, значит, у нас папка git. Вот есть head. В хеде у нас есть ref. Refs head main. Да, мы уже с вами знаем, что это ветка main. И у неё будет что? Хэш последнего комита. Всё. То есть почему

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

вами будем писать, что обычно вы можете нагуглить такую команду, как git reset hard head. Нажали, всё, всё это удалилось, потому что он у нас перешёл вот сюда. А это что у нас? Давайте не будем, э, пребывать в неведении.

Это у нас test name 3, последний комит, то есть, а, git reset hard head, то есть git reset на head последний комит. Сюда мы можем вписать в целом любой другой хэш комита. Давайте проверим. Это это не должно быть для вас магической надписью.

Это просто тупо скидывание до призлённого комита. Вот мы скинули, вот взяли хэш комита. Чик, всё, хд. Теперь вот этот комит, так же как и было до этого. То есть просто мы тут заменяли это словом head, да? Частор, всё.

Значит, хард у нас просто очищает полностью индекс. А если мы делаем софт, то индекс остаётся нетронутым.

Соответственно, я предлагаю вам что сделать? Поэкспериментировать с этими вещами. Вот также мы можем через тильду ещё делать, то есть можем сделать git setхар head и ввести, например, тильду два. Это значит два коммента. Чик сделали.

Смотрите видите? Всё, к чёрт твой матери ещё улетело на тест namйм, то есть потому что я на два комита откатился. Head и два комита.

Смотрим, что здесь произошло. Вон видите, что произошло? Два комита ушло. Вот так. Что через тильду можно указать количество комитов, куда нам вообще откатываться? Только я вас прошу, вот это вот с этим не экспериментировать на рабочих проектах, потому что, видите,

все изменения просто удалились. Вообще всё не сохранены изменения, удалены, всё, всё к чёртом матери стёрто. Поэтому так делать не надо. Вот посмотрим в историю. Их нет. Всё этих кометиков с софтом. Всё несколько иначе.

Экспериментируйте, пожалуйста. Не будем растягивать это видео. Дальше давайте сразу с вами проговорим. Git reверт comit, да, както зареверситить.

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

опять же -э всё быстро это показывать. Черри пик. И беру комит. Вот его хэш.

Чик. Что произошло? Я сюда черепикнул комит. Всё. То есть я, находясь в ветке main, дал ему хэш комита из другой ветки, и он его сюда перенёс. Всё. То есть GitHub Desktop делает то же самое, просто вот этими командами оперирует,

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

Возьмём вот Experims 2, возьмём его ш и переключимся на этот кот. Да, мы можем переключаться прямо на кота, то есть git checkout комита. Чик, я здесь, смотрите.

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

Типа здесь мы выпустили версию 1.0, да, сделали тег. Смотрите, он появился. Вот версия 1.01. Дальше я могу сделать git checkout main. Вернуться в нормальное состояние, пожалуйста. Вот мы здесь. И теперь прикольно, что вот версия один там где-то будет называешь версия 2 или

там, не знаю, версия 1 то 1.2, не знаю, любые, в общем версии, куча версионеров и просто могут быть теги, например, сделали такую фичу, поставили такой тег, если нужно к ней вовращаться. Почему?

Потому что очень удобно возвращаться к версии с тегами. Мы бежа пишем Git checkout, не ищем никаких там хэшей, комита, ничего этого, а просто пишем G checkout и пишем просто название тега V001. Да, ну б, ну, вы поняли. Чик.

Всё, я вернулся сюда. Всё, кайф, да? Вообще кайф. Супер. Теперь давайте отмотаем на main. И что мы, например, можем сделать с тегами? Можем ввеститег.

Просто будет вот список тегов. Вот один тег здесь всего лишь. Хорошо. Ещё можем удалить тег. То есть можем сделать git тег defис d как удаление, да? И прописываем просто v 0.

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

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

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

нигде нет. Он у нас только на компьютере есть. Что мы можем сделать? А можем сделать мы достаточно интересную вещь.

Мы с вами возьмём два терминала. Один будет в нашем тестгиitте, другой на папке выше. Git examples. Создадим папку remote test. Git создали. Теперь перейдём в неё. В неё перешли. В ней создадим репозиторий. Всё, в ней создался новый репозиторий. Теперь в нём

сделаем git remote add origin. То есть, что мы делаем? Git в remote, то есть что-то удалённое. Это добавь Origin.

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

что? Вот сейчас, пожалуйста, уберите беременные женщин и детей от экранов, потому что могут просто начать взрываться головы. Мы просто добавляем не GitHub, не Gitlab, а тупо папку на нашем компьютере. То есть берём теestgit. Добавили. Чтобы посмотреть, что мы там добавили, берём git remote.v.

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

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

Git, fch, папам. Он какие-то 17 объектов получил и так далее. Что-то скачал. Вот у него есть есть ветки main. Весь ветки пи. Супер. Так, теперь давайте возьмём ветку main себе заберём. То есть мы можем взять git, Pull, Origin, main.

Чик, забрали. Теперь давайте я сделаю ls. Это посмотреть ээ файлы. И тут лежит у нас индекс HTML, PVMD, поxt, по 2TXT.

Чтобы вы понимали, что я не какой-то иллюзионист маковолшебник пожалуйста вот наша папка. Вот test Git, да? Вот теest remote Git. Всё.

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

сейчас с вами, получается, сымитировали GitHub и GitLab. Всё. Соответственно, теперь, если мы хотим что-то выложить, мы просто добавим, сделаем вот вместо, э, git remote origin вот это вот мы просто добавим, собственно, тот самый Origin, который нам нужен. Каким образом

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

Давайте сделаем это на Гitлабе лучше. Вот, создадим новый проект репозиторий. На Гитлабе, кстати, который поднят для менторинга, помните, да? Если хотите вот, чтобы я вас учил и доводил до результата с оплатой за результат, то, пожалуйста, в описании есть вся

информация, как подать свою заявку. Созвонимся, всё обсудим. Create blank Project проект будет называться у меня, давайте назовём его точно так же, чтобы у нас не было никаких конфликтов. Вот git, да, он называется. Отлично, пускай будет git.

А P group Space, всё, он будет private. У нас ничего не надо инициализировать изначально, просто create project.

А, надо выбрать группу. Простите, пожалуйста. Всё, правила, правила, очень жёсткие правила на Getlла. Все поряд должны быть заполнены. Так, отлично, он создался. И термин даже показывают. Смотрите, что я могу вот сделать git remote origin SSH. Вся вот эта вот штуковина.

А мы добавляли с вами SH-ключ. Надеюсь, я его ещё не удалил. Давайте попробуем. Сделаем Gitреem mode. Сделали.

Прекрасно. Тогда мы можем, получается, сделать с вами Gitp. А не можем. А почему? А потому что пока не можем. Он даже говорит нам, что нужно сделать. Git push set upstream origin main. Нажимаем.

Пак. Так. Чик. Всё, PSS у нас всё подтянулось. Смотрим наш репозиторий. Обновляем. Да, вы посмотрите. Да вы посмотрите. Всё выложилось. Всё здесь. Ну как, что за магия? Магия. Ну и давайте, чтобы этой магии точно не было, мы просто откроем с

вами конфиг и посмотрим, что в конфиге написано. Вот Remote, Origin, SSH, все дела. GitHub Черняков. И вот, пожалуйста, феч, которая Remote стоит.

Вот Remote Origin, все дела. Бранch main и тому подобное. В общем, у вас GitHub сам проведёт. Соответственно, теперь представьте, а что нам стоит переехать с Gitlub на GitHub, с GitHub на Gitlab, поменять Origin, запушить. Всё, вот весь переезд. Так что тут тоже ничего

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

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

собрать. Я потому что напоминаю вам, что в нашем лексиконе нет слова невозможно. И пока. M.