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

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

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

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

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

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

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

И теперь погнали практике. Важно понимать, что гит - это просто технология, а репозитории, созданные по этой технологии, могут храниться где угодно. Поэтому у нас и есть 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 какой-то конфликт.

Ну что ж, конфликты можно решать в визуальном режиме, например, в вашем редакторе кода. И, в принципе, мне кажется, все редакторы кода поддерживают разрешение конфликтов. Я покажу вам на WebStorm, но точно такой же интерфейс вы увидите ещё много где. Вот на этапе, когда у меня высветило, что нужно разрешать конфликты, если мы перейдём в WebStorm, он подключён к Git. Он понимает, что, видите, есть какой-то conflict, merge mission block, toду, warning, тата. Можно нажать зелёную вкладку resolve conflicts, и будет идеальный интерфейс. Смотрите, здесь он показывает, что конфликт в файле index.html. Мы можем нажать merge строчкой. Что он сделает? Он покажет нам, то есть разницу. У нас есть change mission block, change from main, которые летят, а среднее — это вот то, что мы хотим после себя оставить. То есть мы должны здесь разрешить этот конфликт полностью, да, и только тогда он даст нам пройти дальше. Хорошо, что мы можем сделать, чтобы отсвечиваться зелёным? В нём конфликта особо нет. То есть программа сама знает, как его разрулить. Единственное, что она не всегда делает это чётко. И сейчас она сделала это не совсем чётко. Видите, я могу добавить это зелёное и это зелёное. И вот он мне поставил, пихнул куда-то не туда. А мне нужно, на самом деле, было это сделать вот так. И видите, я в итоге в центральной колонке могу сам просто переписывать код. Это будет тот код, который есть. Вот я вот тут удалю. Отлично. А внизу красное — это прямо конфликты. Помните, как я вам и говорил, да, что как так? Он же типа на восемьдесят шестой строке это писал, а здесь типа здесь это написано. Так оно же, ну, оно же никак никак что. А то, что красным — это реальные конфликты, как я вам и говорил, да, что преучается для Git, когда пользователь на восемьдесят шестой строке написал одно, потом другой пользователь другое, как их слить, чьи оставить, чья восемьдесят шестая строка имеет право на жизнь. Блин, что же делать? Вот, пожалуйста, здесь этот конфликт присутствует. Как мы можем поступить? Можем нажать стрелочки здесь и стрелочки здесь. Он просто поставит одно под другое. Всё. То есть конфликта нету. Типа оставить и то, и другое. И теперь я могу нажать apply. Он всё это заплатил. Смотрим. Опа. All conflict resolve continue merge. И теперь можем запушить этот коммит. Теперь мы подтянули главную ветку в mission block. Всё, теперь у этого разработчика есть та версия кода, которая не будут конфликтовать, когда пройдёт время слияния.

Опять же, показываю вам отдельно. И для тех, кто более опытный, конечно, это создало дурацкий ещё один merge commit. Вот, пожалуйста. Которого хотелось бы избежать, потому что опять же у нас история становится какой-то грязненькой, некрасивой, да? Merge pull request, merge branch main in mission block. Обо всём этом позже. Сейчас мы просто учимся хоть как-то работать с Git. Дальше мы станем профи, wizard с такой вот шапкой. Прямо вообще супер, всё будет хорошо.

Давайте теперь возьмём и смержим эту ветку тем же самым образом, который мы делали до этого. Предлагаю вам это самому сделать, обогнав меня. New request делаем. Ветка у нас будет mission block. Create pull request. Будет mission block. Create pull request. И нажимаем merge pull request. Confirm. Merge. Pull request. Successfully merged and closed. Мы можем перейти теперь в main, посмотреть. Пулим изменения. Помните, да? Четыре коммита. Пум-пум-пум. Сколько коммитов теперь? И теперь у нас есть и первый блок, и наша миссия. Вау! Шу! Ещё раз была одна ветка, распачковалась, да, на две. Они всё-всё сделали и постепенно слили одну ветку и другую ветку. Всё, теперь у нас одна ветка с полным кодом. Всё, можно пачковать новые ветки и делать новый функционал.

Теперь чутка передохнём от всех этих веток, коммитов и так далее, а просто поговорим про очень простую вещь, про stash. Очень простую, но невероятно полезную. Внимательный зритель мог заметить, что у меня в ветке main есть такая вот странная штука. View stash changes. Могу показать stash. И там в stash тот самый branch, где я вам всё супер с помощью ASCII символов рисовал, как же оно всё-таки работает. Смотрите, этого файла сейчас нет в проекте, но я могу сделать, и он появится. Пожалуйста, воспринимайте stash как место, куда можно временно скинуть изменения, чтобы случайно их не закоммитить или посмотреть, как вообще было без них. То есть реальный пример — это какой? Вот мы берём, смотрите, разрабатываем с вами, разрабатываем что? Пишем в поте лица наш код на любом языке программирования. C++, Go, Java, неважно. И в какой-то момент что-то в коде сломалось, и вы такие: "Блин, наверное, это из-за меня, но надо точно удостовериться. Возьму-ка я и засташу свои изменения". Как это делается здесь? Я просто нажимаю вот на верхнюю строчку, где changed files. Ну, видите, могу нажать либо discard all changes, значит, отменит их просто все, они всё в утиль улетят, либо Stash All Changes. Они такие: "Опа!" и временно скрылись. Смотрите, чик, их нет ни файла, ни изменения в файле, вообще никаких изменений нет. И они в stash, они в каком-то, знаете, таком дальнем кармане лежат. Их можно либо окончательно просто удалить эти изменения, либо их восстановить. Вот, соответственно, очень полезно, когда вы не понимаете, то ли бэк или фронт сломался, да, и что не с вами связано, сервер там не отвечает, что-то такое, то ли это всё-таки вы накосячили. Поэтому прикольно свой код откатить, посмотреть, точно ли это не из-за него или это из-за него. А, о'кей, хорошо. Всё. И смотрим обратно накатываем.

И второй вариант использования. Смотрите, давайте я всё восстановлю. Если я переключаюсь на другую ветку, то меня будет спрашивать эти вот changes, которые сейчас висят у нас, мне что с ними сделать? Оставить их на этой ветке main или вот я переключаюсь на ветку mission block, мне забрать их с собой? Могу забрать их с собой. Вот забрал. Давайте обратно их верну на main. Опять заберу их с собой, то есть. И теперь смотрите, если, например, я переключусь на другой блок, оставив мои changes, да, в мейне, оставив их тут, не беря с собой, то при переключении обратно на main они будут где? В stash. Всё, они здесь лежат, как бы скрытые, поэтому надо не забывать, что их надо восстановить вам, если что. В общем, это такая штука. Видите, вы собрали какие-то свои изменения, аккуратненько это сложили, типа, я не хочу их полностью отменять, я к ним просто ещё вернусь, типа, сейчас коммит, коммит, я понял, я понял, коммит. Ну и, соответственно, вот если мы видим, что нам точно не нужны все эти изменения, то можем всегда сделать discard changes. Are you sure? Yes, I'm sure. Всё. А принте мы пока оставим. Причём давайте, пускай оно будет у нас засташенное висеть для будущих объяснений, которые нам скоро понадобятся.

И мы плавно перетекаем к команде cherry-pick. Поговорим о ней. Что это такое? Чтобы посмотреть проблематику, которую решает cherry-pick, нам нужно создать снова несколько веток и между ними попереключаться. Итак, смотрите, вот у нас готовый уже бобёр, да? Следующий у нас какой блок? Наши проекты. Давайте сделаем ветку, в которых будут наши projects, и сделаем ветку, где будут facts, да, факты о бобрах. О'кей, погнали. Делаем это вместе. Лишняя практика для вас. Если кому-то это что-то наскучило, то можете, в принципе, проматывать или на ускоренном посмотреть. Итак, сделаем, не знаю, facts block, да, facts block. Ветку сделаем create branch. О'кей, всё, даже запушим эту ветку, пускай она будет там лежать у нас. Возвращаемся обратно в main и делаем ещё одну ветку. Эта ветка у нас будет projects projects. Ой, блок. Угу. Отлично. Создали ветку Project Block. Тоже запушили её. В ней давайте уже добавим частично код проектов. Значит, где у нас тут? Так, вот я вставил секцию проектов. Смотрите, что у нас получилось. У нас есть наши проекты. И пока только две карточки, да? Сделал специально не все. О'кей. Я делаю коммит, в котором будет написано, что add не давайте, как как всё у нас делается. Start projects block. О'кей. Пушим. Origin запушили.

Тем временем, тем временем в fact, fact, кстати, у нас я букву "т" пропустил. Какой-то fact block получается. О'кей, здесь ничего такого нет. И я только собираюсь разрабатывать, и мне мой коллега говорит: "Слушай, я там уже начал разрабатывать следующий блок, да, чтобы, ну, не было конфликтов, чтобы ты нормально его вставил. Подтяни себе изменения. У меня пока там один коммит. Можешь его cherry-pick-нуть. Cherry-pick-нуть". Мы такие: "М, мы же профессионалы, мы просто визарды Git, мы знаем, что это такое". Всё очень просто. Мы идём в ветку, которую нам указал человек. Указал он нам project block, да, что в ней работает. Мы находим этот коммит. Вот start project block, да, и мы делаем вот так вот правой клавишей и cherry-pick commit. Он нам предлагает cherry-pick commit to a branch. В какую ветку-то? В fact block, да, cherry-pick commit. Всё, я переключился. Вы видите ветку fact block. Тут появился этот коммит. То есть, что такое cherry-pick? Это просто взять коммит из одной ветки и скопировать его в другую ветку, да, чтобы тут тоже были эти изменения. Всё, мы не делаем дополнительных pull request-ов каких-нибудь, не подтягиваем изменения туда, создавая лишний этот merge commit, просто чисто аккуратно берём коммит и перемещаем. Периодически в работе вам это 100% понадобится, когда нужно небольшой кусочек функционала перетянуть себе в ветку, и с ним разработка пойдёт плавнее. Можно будет просто легче состыковаться своими фичами, которые вы разрабатываете.

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

Чем теперь, прежде чем углубляться в Git, нам нужно разобраться с ещё одним концептом, который называется rebase. С ним мы тоже разберёмся в визуальном режиме, а потом уже пойдём постепенно к консоли. Будем через консольные команды работать с Git, чтобы совсем вообще вот любой страх работать с Git вас отбить. Вы всё понимали. Но и перед rebase хотел сказать одну важную вещь. Вы, надеюсь, поняли, что ветки можно создавать не только от main. Ветку от другой ветки тоже создать можно без проблем. То есть ветвистость она реально как дерево может быть сколько угодно. Соответственно, давайте я в двух словах это сделаю. Вот переключимся на, например, на facts block, да, я могу сделать new branch. Видите, он меня спрашивает, на основании main делать или на основании facts block. Давайте на основании facts block сделаем. Только я сделаю facts block 2. Вот такая вот create branch. Всё, у меня есть новая ветка facts block 2. Она основана на ветке facts block. Понимаете? То есть если смотреть на дерево, как я вам показывал, это, ну, всё просто, да, из этой точки времени мы ещё ответковались, ещё ответковались. И потом эти ветки также можно каскадом собрать, смержить одну в другую, одну в другую, одну в другую и собрать её в main, например. Так. То есть тут уже вот как вам душа позволяет и как договорённости в команде работать. Просто имейте в виду, хотел сказать, это очень важная вещь. Ветку можно делать от любой другой ветки, вообще без проблем.

Ох, rebase. Rebase, мой дорогой. Тут важно понять его правильно, потому что многие люди понимают его неправильно, используют неправильно, когда-то нафакапили с ним что-то, теперь ненавидят rebase, думают, что rebase — это поша. Давайте посмотрим, что такое rebase на нашей суперсхеме. Итак, её сначала я выровняю быстренько. Перемотает этот момент. О'кей. От блока "наша миссия". Мы с вами сделали новую ветку, и в неё мы уже успели сделать старт. Старт "наши проекты". Вот уже успели начать делать. Теперь я что предлагаю вам сделать? Мы с вами сделаем продолжение некоторое. То есть добавим карточку. Карточку, там две у нас есть. Давайте карточку три добавим, третью и просто добавим ещё карточку четыре. Вот. То есть у нас будет ещё два коммита. Мы изготовим в этой ветке, и получится такая картина. А тем временем в главной ветке мы сделаем футер. Представьте себе, то есть здесь вот, например, будет старт футер, да, и будет ещё один продолжение футер. Вот смотрите, то есть у нас получится так, что есть в одной ветке три коммита, но параллельно ей делались другие коммиты. Теперь, если мы будем вливать эту ветку в нашу ветку main, произойдёт merge request, который мы уже делали. Мы уже с вами это видели в истории коммитов, когда делали три восклицательных знака, да, что они объединились, что был start block, start mission block, это picture. Это всё оно объединилось и встало по времени, как оно выстраивалось. Вы это могли видеть буквально там сколько, 10 минут ролика назад. Хорошо. И создался вот такой вот омерзительный коммит. Merge pull request. Потом ещё ветки другие мержили, тоже были мержи. Ещё merge pull request другой. В общем, всякое всякий ужас. Как работает? Он помогает от этого всего избавиться. Давайте рассмотрим само слово rebase, да? То есть перебазировать, да? Перебазировать. В чём суть? Объясняю. Давайте из этимологии пойдём, почему команда называется BASE, а у вас всё встанет на места. Значит, сейчас эта ветка базируется, да, базируется на вот этом коммите. Отсюда она была отпачкована. Rebase — это перенести её базу. То есть мы можем вот так вот сделать, сдвинуть её сюда. То есть не мержить всё, да? А просто сделать так, как будто бы сделать так, как будто бы ветка начиналась отсюда. И всё, у нас не будет никаких проблем, потому что эти все коммиты при мерже ветки спокойно встанут вот сюда. И всё, не будет никому мешать, всё будет чётко. И надо будет выбирать между ними последовательность и так далее. То есть просто делаем rebase. Соответственно, не нужен никакой merge commit. Посмотрим, что в нём происходит. В merge коммите вот мы тут делали какие-то удаления строк, добавления строк. В общем, всё это у нас было через одно место немножко, да, и с грязными коммитами. Здесь же, как видите, будет чистая ситуация.

Давайте, перед тем, как я покажу, как на практике это работает, да, мы сейчас всё сделаем, эти условия и rebase-немся, я вам ещё расскажу, как это работает под капотом в Git, то есть что он делает, когда нужно rebase-нуться. Вот смотрите, у нас ситуация вот такая, да? То есть он отсюда отпачковался. Мы когда делаем rebase вот этой ветки в ветку main, то есть в эту ветку, опять же, rebase может быть между другими разными ветками, тут просто для примера. При rebase что мы делаем? Он переключается на последний коммит этой ветки. То есть мы переключились с этой ветки на эту и встали на последний коммит. И начинает коммит за коммитом постепенно проигрывать вот эти коммиты. Типа этот применил, этот применил, этот применил. Но что важно, две вещи. Во-первых, так он делает их постепенно, да, то может по дороге возникнуть какой-то конфликт, да, который мы разрешим, и rebase продолжится. Это первое. Во-вторых, эти коммиты, они будут не совсем эти коммиты. То есть они уже поменяются. Это будут как бы новые коммиты для системы. Почему новые коммиты для системы? Потому что коммит себе хранит своего родителя. Родители заменились, соответственно, коммит уже другой. У него уже другой родитель. Всё. Вот. То есть переключились на ветку целевую, да, на самый последний её коммит и проиграли все коммиты, которые есть в нашей ветке, которые мы хотим rebase-нуть. Вот. Чик-чик-чик. И видите, всё, выстроилось. То есть была ветвистость некоторая, да? И мы чик сдвинули, всё в прямую линию сделали. Соответственно, что чего мы добиваемся? Мы добиваемся того, что у нас ровная история изменений идёт. Абсолютно абсолютно ровная. Да. Мы немножко переписываем старую историю вместо того, чтобы у нас всё выглядело вот так вот чинно-благородно, без всяких там этих merge коммитов, которые засоряют историю и не дают никакой информации. Вот. Кроме того, типа, где был merge, ну насколько она нужна, не знаю, не нужна. О'кей, всё, погнали делать.

Значит, этот текстовый файл мы уже с вами классный. Мы можем засташить его. Засташили. Отлично. Теперь давайте здесь, пока мы в ветке main, мы добавим как раз-таки код футера. Да, погнали. Добавим код футера в самый низ. Вот код футера. Я его добавил. Только давайте разобьём его на два коммита специально. Вот мы таким образом вот этот пока частично код поставим у себя. Мы пишем с вами, делаем коммит start footer, пушим, а сразу же добавляем назад код, который я подудалил. Тут, видишь, соцсети всякие добавились. Facebook, Twitter, Instagram наши суперорганизации по охране бобров. И пишем, например, end footer, то есть второй коммит. Всё, зандили.

Теперь я переключаюсь в project. И здесь мы добавим с вами карточки, которые мы тогда удалили. Так, вот добавили одну карточку. Смотрим. Да, их стало три. Как договаривались с вами, делаем add 3. Пушим и давайте добавим четвёртую карточку. Добавляем четвёртую карточку. Так, вот она, четвёртая карточка. Центр реабилитации бобров. [музыка] Карф добавил. Теперь давайте ещё раз, перед тем, как мы начнём всё это жёстко rebase-ить, посмотрим, что мы сейчас имеем. Сейчас мы с вами имеем вот такую картину. От блока "наша миссия" отпачковались. У нас был старт "наши проекты". Добавили карточку три, добавили карточку четыре. И здесь вот разница. Теперь мы будем rebase-ить ветку с проектами с мейном. Так вот, чтобы было вот так. Всё. Как мы это будем делать? В приложении GitHub Desktop. Переключаемся на project. Значит, мы оставляем наши changes здесь в stash. У нас есть вкладка 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 commits наверх мейна. То есть наверх мейна. Видите? А уже закрыл. То есть наверх мейна, что означает? Что у нас было ещё два коммита после отделения, да? И мы сдвигаем, то есть наверх добавляем. О'кей, нажимаю rebase. Вы готовы? Нажимаю I to want rebase. Да, мы у нас есть конфликт. У нас есть конфликт. И видите, потом мы можем сделать continue rebase. Как я вам говорил, это какой-то конфликт возник. Мы его должны поменять и продолжится. Почему? Потому что он постепенно применяет по одному коммитику. И мы смотрим, решаем конфликты. Итак, перешли в WebStorm, нажали кнопку, нажали. Сейчас посмотрим, что у нас здесь. Что-то вообще неважное, а зато вот здесь важное. Здесь футер, здесь project. Я говорю, что нужно и то, и то оставить. Всё, apply. Так, теперь смотрите, он попросил меня сделать какой-то commit message. Сейчас вы увидите, что это такое. Я просто нажимаю, нажимаю continue rebasing, потому что start project block меня устраивает название. Всё, нажимаем continue. Rebase successful. Rebased successful. Всё, посмотрим на историю, да, что он предлагает мне. Вон видите, там пять отправить, три получить, что-то в этом роде. Что тут произошло? Он мне сделал footer and footer, да? То есть он теперь они есть в этой ветке, да? Потому что он историю переписал, как будто бы они начались с них. Дальше сверху идут коммиты. Как было написано, он top, да, на top, то есть start footer. Footer — это есть top мейна. На него пошли start project. И что есть интересное, смотрите, вот project block. Помните, у нас высветилась такая штучка про конфликт. Я написал конфликт, но он не создал отдельный коммит, который решает конфликт. Он start project block, видите, в этом коммите добавил уже всё, что нужно, потому что футер здесь уже есть, да? То есть rebase он чётко помогает нам сделать историю, выпрямить её.

Теперь мы нажмём Pull Origin. Так, после получается синхронизаций всего этого дела. Репозиторий. Всё, всё у нас обновилось. Посмотрим, что у нас там в репозитории. Давайте поставим. Получается, что это у нас? Project block, да? А this branch 3 commit head of main. Ну всё отлично. Она просто commit head of main и всё имеет, не более. Переключимся в main. Всё нормально, всё клёво. Давай теперь попробуем сделать merge request. Pull request. О'кей. Project block create request. Прямо в main. Да. Что требуется? Просто посадить наверх три коммита. Да. Merge request. Всё, я мёрз. Тем временем хочу залететь в main. Мы смержили, и request закрылся. Принимаем изменения. Ну и вот смотрите, у нас есть чистая история. Start footer and footer start project block car 3C car 4. Всё здесь в ветке main. Соответственно, что rebase позволяет всё сделать ровненько. А, кстати, надо же визуал показать, поэтому вот смотрите, наши проекты, наши проекты. И вот, пожалуйста, Berggaard. Всё здесь. Короче, разработчики делятся на два лагеря. Кто-то любит merge, кто-то любит rebase. Rebase в основном любят те, кто когда-то с ними накосячил. Но, в общем, это не столь принципиально. Не столь нам принципиально разработать качественное программное обеспечение. Вот как вот тут в Git будет история. Ну, кому надо, сделают ровно, кому нет, неровно. Какой команде нужно договориться, они договорятся, какой нет, не договорятся. Так что просто имейте в виду это. Вы должны знать главное. Это всё, чтобы для вас был не пустой звук, там cherry-pick-ни, push-ни, rebase-ни, merge-ни, чтобы это всё было понятно, что означает.

Теперь небольшой прикол о том, как можно всё испортить, когда вы сделали, казалось бы, rebase, да, но что может произойти? Смотрите, я создал pull request для ветки, которая fact block. Ну fact. О'кей, о'кей. FS, да, делаю для неё pull request. Вот она на один коммит впереди main. Здесь добавляется просто блок фактов, да? Я создаю request. И теперь я в целом могу его смержить, да, вот когда он проверит ability to merge. И смотрите, теперь, если я буду это всё смерживать в интерфейсе GitHub и нажму на эту кнопку, то произойдёт вот что. Create merge commit. All commits from this branch will be added to the base branch with the merge commit. То есть он сделает merge commit всё-таки. То есть мы всё делали, чтобы этого не было, но он сделает его. Дальше есть другой вариант squash. Что такое squash? Тут всё просто. Сейчас отдельно тоже посмотрим. Можно взять вот у вас четыре коммита есть, и вы такие: "Что историю раздувать? Все четыре коммита я делал блок фактов". Ну ладно. И можно все четыре коммита сделать в squash. Вы превратите в один коммит, да, просто для удобства истории. Да, у вас будет история из меньших коммитов. Её, наверное, будет легче читать. Но вопрос, как часто кто-то читает историю коммитов? Ну да, нет, не подумайте. Это важные вещи. Всё действительно, да, надо делать всё, вести аккуратно, Git и так далее. Но иногда мне кажется, что некоторые люди уделяют этому слишком много внимания. А надо всё-таки делать промышленный код для бизнеса, вообще-то. На секундочку. И дальше у нас есть вариант rebase and merge. The one commit from this branch will be rebased and based branch. Давайте попробуем. Именно так сделаем. Rebase and merge. Нажимаю confirm. Rebase and merge. Так, погнали теперь ветку main и попробуем посмотреть, что у нас там нового новенького. Один коммит. Ну всё, вот он факт. 4 минуты назад пролетел, да? Угу. Предыдущий merge — это зафакапленный как раз-таки merge. Таким образом, вот видите? То есть, короче, сделал вот здесь как надо, всё получилось хорошо. Нажал бы просто merge, я получил бы вот такой merge pull request. И какой-то весь смысл rebase как будто бы убит. Да, ну не убит до конца, но история некрасивая. Некрасивая.

Теперь насчёт squash. Смотрите, я перешёл в ветку.

Facts block. Okay. And down there we have facts about beavers, right? Beavers are amazing creatures whose activity benefits the entire ecosystem. By the way, let's just add one more fact with one commit and another fact with another. Let's just paste them. So, for those who don't want to watch everything, how to do it in HTML, I'll also rewind it. So, I wasn't satisfied with two commits, I decided it would be clearer to show when two commits are already pushed. And you see, two commits are not yet pushed. Let's wrap them all up in four and squash them. Squash commit, here's the summary. Plus 1 2 3 4 facts, right? Squash commit, squash process. That's it, they all became one commit. We need to push, chponks. That's it, now it's one commit. In general, we had four commits, two pushed, two not pushed, and we made them all into one commit and pushed it as one commit. That's it. That's how squash works. So you can clean up the history. You have almost everything you need to work as a programmer for years without thinking about Git. Why do I say almost? Because we still need to talk about authorization. Maybe you've heard of SSH keys? No? Well, we'll figure it out now. And that's how we'll smoothly transition to the console. Look, our repository is private, meaning to get it, you probably need some credentials, like a login, password, something like that. How do we get the code at all? We can get the code, you see, it says clone, because there's a command Git Clone. We'll use it now. And you can clone via HTTPS, via SSH, which is that super secure option. And GitHub CLI is just a helper program for GitHub. We won't consider it, we don't need it. Since we're using the console, it's all hardcore, all the way. So, let's start with HTTPS. I've copied what it suggests into this path. And how will we do this? This terminal is open on my left. I'll do the following. If you don't know the commands, then CD is change directory. I want to go to the desktop, and there I've made a folder for you called git examples. Git examples. We'll do all sorts of mischief in there. Now, here we type Git Clone, the Git Clone command, right, and just paste this HTTPS thing. Press Enter. It asks for my username. Look, it doesn't matter, I'll deliberately enter the wrong username and password. And here's what it will tell me, that password authentication has been removed for a long time. It was on August 13, 2021. That's the last century, my friend, the last century, right? Yours failed because you entered the login and password incorrectly, but think about it, think about it, it's the last century, let's go via SSH. The video is already very long. I won't talk about encryption, what SSH keys are, I'll just say a couple of things: there's a public key and a private key. And a pair of computers can exchange a pair of keys to establish a trusted connection, right, and exchange information securely, recognize each other, that it's really them. We'll leave the understanding of encryption at that for now. If anything, I have a report on encryption on my Boosty, you can watch it there. But for now, we'll just generate this pair of keys and make GitHub trust us. That is, we'll give it our SSH keys and say that it's through these that everything is okay, give us the code without questions. Let's try to copy all this first, without having any SSH keys. I choose the SSH option. Here it shows me GitHub, templates, everything I need. I type the same thing: Git clone. And that's how it tries to clone. Then it tells me that permission denied public key, meaning you see, there's a public key. There's a public key, there's a private key. So, the public key didn't work. Right, let's inform GitHub about our public key so that this option always works and we don't have authorization problems. By Googling GitHub documentation, you can find out how to add keys there. But we'll try to do it from memory. So, ssh-keygen, there's such a utility. Then we type -f. And here you need to choose the encryption type. So, again, encryption type is all for the report, for videos about encryption and so on. There are just different ways to create encryption, right, again, simply, from a Turing machine to what quantum computers will do now. So, we choose a cool encryption type suitable for GitHub called ED25519. Again, you don't need to memorize all this. You can just retype these commands from the screen or find them in the docs, and that's it. I'm just adding extra comments so that it doesn't look like we're just banging on the keyboard and waiting for results, right? So that you understand at least something about what's happening. Then -C. And here you type your email. I'll have this email. How do you like my email? .ru. Like this. Let's make the shift a bit smaller so that everything fits. And after that, I'll press Enter after the closing quote. Generating public/private ed25519 key pair. Here it is. It will create a pair of keys for us. Look, it suggests placing it in this file. Let's make it even bigger. Like this. In this file user achernyakov ssh_keys. I suggest you take the same, but change it slightly. Let's put a slash or better an underscore GH like GitHub, right, so that if I have some other keys in this file, they don't get overwritten and so on. So, let's have this separate thing. That's why it writes in parentheses where it will save it. If I just press Enter, it's the default, but instead, I can enter. Where to next? It suggests entering a passphrase, right, for this, just press Enter. We don't need any passphrase. The security of this key is enough for us. That's it, we got this fancy pattern. Here's something it generated. And now we type the following lines. Again, all this can be found on the internet, but you'll have it here in the video. eval "$(ssh-agent -s)". We start our SSH agent, the agent that actually transmits SSH keys during our connections. Here it says that the agent has started, right, and it has a PID, which is the process ID. That's the ID of this process in the operating system where it started. Now we type the following command ssh-add and add our newly minted file. It was at the end, we had an underscore GH, right, ssh-add ~/.ssh/id_ed25519_gh. That's it, great. Now we need to take this public key and inform GitHub about it. There are all sorts of ways to do this, and depending on the operating system, the way we copy things will vary. But let's not use any command-line copying utilities, but rather do it manually. Here's ssh, right, and we had id_ed25519_gh, right, everything is super. And we need to take the .pub, that is, the public key. We need to see what it looks like. It looks like this. This line with the crazy key. That's it. Now we just go to GitHub. In GitHub, we go to Settings. In Settings, we'll have SSH and GPG keys. We can create a new SSH key. Add this key here. I'm sharing this with you openly because I'll delete it after recording the video. Understand? Like this. And then we can enter, let's call it just a name to distinguish it. MacBook SSH. It asks for GitHub Mobile, I take my phone because a two-factor authentication might come to the GitHub mobile app. I have to confirm here that I'm actually entering an SSH key, because security must be secure. Understand? I entered this number. Oops, everything just happened automatically. Great. Now look what I'm doing. I go back, press the up arrow. I go back to this. Git clone git@github.com:.... This is our SSH command. I press it, it thinks, click. But it downloads everything. Look, it downloaded everything. Now what can we see? Here, ls, contents of the folder. Here's BER Defender, we have it. Everything, it cloned all the code from here. And you'll need this because, well, all repositories will naturally be private. So, you'll end up at work, or you're already at work, but you're doing all this through GitHub desktop or via HTTPS. Keep in mind that you can also do this with an SSH key, upload it to your account on your GitHub, GitLab, it doesn't matter, and everything will work. By the way, about GitLab. Well, let's also see how it's done on GitLab. I've logged into GitLab, but not the regular GitLab, but GitLab.ru, because this is our GitLab, which is set up for mentoring purposes. By the way, we have front-end mentoring with payment for results. That is, you'll pay after receiving your first salary in IT, or your new salary. And this is, of course, for you too, because the maximum experience of people who study with us is 5 years of real commercial experience, the minimum is no experience at all. And we help everyone realize themselves, get their first job in IT, get their 85th job in IT with a new salary, a new grade, and so on. So, on GitLab, let's look. So, we have Edit profile, there's SSH. Here we add a new key. We can just copy it again, because they will validate it, it won't let it through. A simple disabled key. It even names it right away, you see, the title is the last line. And we can do Add key. Everything is great. We now have a new SSH key added. Here, at the moment, the third one. We practice Git, set up all CI/CD pipelines, and deploy everything there. Fam-fam-fam, we have circles there and so on, full automation. In short, we squeeze all the juice out of Git. And by the way, a very important thing. I'm often asked if GitHub has an analog to GitHub Desktop. It's not needed, you understand? GitHub Desktop works with Git technology. Whether it's GitLab, GitHub, Bitbucket, or your own custom Git, it doesn't matter. Therefore, GitHub Desktop also works with GitLab. So relax. The program is cool, convenient, very friendly. So, now we're starting a gradual journey into the world of Git. We'll also go fast and gradually increase the pace and intensity of the knowledge we have. How do you create a GitHub repository at all? What is a GitHub repository? It's just a folder, inside which there's another folder called .git. We'll look at that now. So, look what I'll do. First of all, I'm currently in the Git examples folder. Just in case, it's also open here in the file explorer, so you can see it. And in it, I can do this. Make directory, mkdir, that's the command. And git, I'll call it. Here you see, the git folder was created. The command didn't lie, it does that. Let's go into testgit. And here we can do git init, initialized empty Git repository. Right here. Great. And you see, it even wrote .git. So, what's the catch? If we open testgit, we see that there's a .git folder. So, everything that distinguishes a regular folder from a Git repository is the presence of a .git folder. Wow. Great. We'll look at the contents of the .git folder later. For now, for convenience, I've opened this git folder inside WebStorm, because we won't need any code to run, to watch in the browser. We'll only need to work with the console here. So, first of all, you might notice that the .git file folder is missing here. And usually, hidden IDs. I'll show you how to show it in WebStorm. As for how it's shown in other IDEs, you'll have to Google that. Your favorite editor, file types, ignore file and folders. And usually, it's here as ignored. Here, .git. We can delete it. I'll restore it later because it's really not needed by anyone, but it will be needed for clarity. So, we can click and see. All the information about the Git repository is here. Okay. Good. Now, look, we'll create a new HTML file, it doesn't matter. index.html. Great. And we'll add something from our neighboring beaver project to it. Just so it's there, so there's some content. Here, hero action. That's enough for me. I'll just add hero action. So, now there's some content, some code we can work with. I'll tell you that files in Git have three states: untracked, staged, and tracked. That is, committed. So, let's deal with the first ones, Untracked. Git has a command called Git status to see the status of files, what's happening. Let's open it and see that we have untracked files, that's .DS_Store and .idea. And in fact, in fact, the modified file, index.html right now, is also untracked because, well, we haven't done anything with it yet. These are just files that, if we delete them now, they'll be gone forever. They haven't made it into Git history yet. So, untracked, right, they are untracked, no one is watching them. So, if we translate it directly. Let's do a small exercise. Look, these two files, .DS_Store. They'll get in our way. What can we do with them so that Git ignores them? The hint, of course, is to create a .gitignore. And let me just create a .gitignore for this. That's it. Now, look, I'll call git status again. We have R, beautifully modified, right? .gitignore and index.html. So, changes that should be committed. Okay. The second state is staged. And here, by the way, we come to a question that is often asked: what is the index? You often hear, right, that there's some index in Git, something like that. In general, the staging area and the index are the same thing. And the index is an intermediate area in Git where prepared files that are ready for commit are stored. And how do you move files to the staged state? How do you add them to the index? There's a simple command: git add. Here we type the file that can be moved. For example, index.html, I've added it. Let's do git status again. And we see that only .gitignore remains modified. To add all files, we can use git add . The dot will recursively go through the directory and add all modified files to the stage. That's it, once again. Git status. Now we have two new files. Great. Now all that's left is to move them to the third state, that is, tracked. They need to be committed, that is, to make a commit. How to make a commit not in GitHub Desktop, but in the console. We'll see now. But first, we'll open GitHub Desktop so that it visually shows us what's happening when we enter these commands. Here I've opened GitHub Desktop. It doesn't get smaller, so sorry, this is the minimum. Here we have two files, right, changed files. Here they are added. Great. How to make a commit? I type git commit. Unexpected, right? Yes? Then -m, which means message. In quotes, I can write a message, my awesome commit, how about that, my awesome commit. I press Enter, they've been added, you see, create mode, .gitignore, all that, everything, they've been added. I click here to update everything here, right, the commit is done. So, it's as if I clicked commit, all that's left is to click publish. In this case, publish the repository, right, to GitHub, that we haven't even published it there. Well, if I click it, it will push it to my account and everything will be pushed. Accordingly, pushing is a separate topic. These are already created commits. To upload them somewhere to another remote server. And we can click history and see that here's my awesome commit. That's it, the commit is created. It's that simple. So, we take, do git add, what needs to be added to the commit. Accordingly, it's like checkboxes here, we select everything, right? So, we add. Then we do git commit. That's it, it went inside. Great. The git commit is created. Now, if you think we'll go through all these buttons and how they will be commands, that's not the case. Now it will be much more interesting. So, now we'll get acquainted with what a hash is. You might have seen that each commit has some F5961 and so on. It's also written here, F5691. What is it, after all? It's a unique identifier, a hash. Again, this is not about encryption, it's not about hashing, right, a lecture, so I can't tell you completely what a hash is. But in a nutshell, a hash is the result of a hash function. Wow, right, strange, right? A hash function is something that takes some data as input and should return a completely unique string composed of that data. That is, if you give the same hash function the exact same data, it should return the hash, these incomprehensible numbers, exactly the same. At the same time, if even a tiny bit of information changes in that data, the hash should be completely different to avoid collisions. A collision is when hashes don't match. But we'll stop here for a moment to talk about hashes. Look, let's try to create a hash from the index.html file. Yes, look, we have such a utility sha sum, right, that's exactly the hash. Here we can specify which hashing algorithm. And GitHub uses, I think, sha, but it doesn't matter. Then sha256 follows, I think. It doesn't matter. These are just different hashing algorithms. Just like when I talked about creating SSH keys, we chose an algorithm. Here too, there are different algorithms, right? So, here we'll take sha1, a1, and then the path to the file. You don't need to memorize all this. All this is easily Googled on how to create a hash. I press it like this. Click. Here it gave me the hash. It calculated the hash. Pay attention to what it is. Now I'll take, first of all, let's do it again, the same hash. But if I make a small change, for example, delete this ID from here and create the hash again, you see, it's completely different. So, I changed even less than one line. So, that's how much, I don't know, God willing, 1% of the file I changed, probably even less. But the hash is completely different. So, 03E7FD. In general, it's completely, completely different. So, a hash is about uniqueness. So, each commit has its own hash. And what is a commit built on? On the changed files, on its parent, who was before it, on its author, and on its creation date. So, I think there are four components that together form the hash. So, accordingly, if one of these parameters changes, the hash will be completely different, right? That's it. So, if another person commits the exact same changes, even at the same second, the hash will still be different because the author participates in the hash formation. Now, let me create another file next to it. It will be just any, I don't know, md, as is customary here on the channel, right, and in the community. MD is Markdown markup, as it's called. So, let it have a heading. Like this. And we'll commit it. How is it done? Let's remember how I do git status. I don't necessarily have to press it. I understand that there are uncommitted changes, so I do git add. That's it. Git commit. Message file. That's it, I've added the md file. Look here, a new commit has appeared. That's it, great. I have two commits. Now, as I said earlier, each commit is a snapshot of your repository at the moment of creation. So, it's not saving a delta or anything. We can calculate the delta, because if there's one commit, another commit, we can see what distinguishes them. But each commit is a complete tree. Why? How? Let's look at new Git commands. Keep in mind that the Git commands I'm about to show you are absolutely not necessary to memorize. I'm just showing you the logic through their example so that you understand how it works, right? We can take any commit, here's its hash EC38. Why, by the way, is the hash? Here there are very many symbols, right? And here there are very few symbols, because the first symbols are enough to already have complete uniqueness. Therefore, Git, so as not to write a bunch of all this everywhere. It writes very few symbols, but you can also refer to a commit by its full hash. What can we do with a commit? We have such a command cat-file, git cat-file. Then we write the commit hash. We wrote the commit hash. This way we can see what's in this commit. It has its tree. I'll explain what a tree is - it's a folder, figuratively speaking. It has its parent. The parent, as you understand, is the previous commit, right? It has its author, here it is, I Chernyakov, right, and it has a committer, also I Chernyakov. And here it says, actually, the date in timestamp format, even with my timezone +0. Here's the commit message. We can do git cat-file and pass any other hash to it, because everything is a file. By the way, you just need to understand this, right, that everything in Git is a file. Git was created by Linus Torvalds. He's also the creator of Linux, the operating system. And in the Linux operating system, there's a paradigm, right, that everything is a file. And as you might guess, he transferred his creation to the Git system? Yes, he did. That's why everything here is also a file. So, we can also take the file with hash tree, refer to it and see that in this tree, right, actually, in the contents of the commit, there are all the files. So, we seemed to have committed only README.md, but here's everything: index.html, .gitignore, and please, everything can be seen. And here's a blob, right, now we'll talk about what a blob is. First, I'll show you this Git folder in a visual mode again. What's the point of it? There's a lot in the Git folder. There are Git hooks, you'll learn to use them in the future. That's what to do before commit, after commit, before commit, and so on. All sorts of info, logs, that's all clear to us. We need this objects file. In objects, there are these peculiar folders 6B, 09, 25, 51, something like that. Now let's try to find a match. 25. Look, 25, 6, look, somewhere there was 6B. Here, 6B, and so on. So, the first two symbols of the hash are the subfolder where it's located. And then this thing goes. You see, here are stored, which we can't see because they're just binary data. Everything, there are zeros and ones inside. So, how does Git actually work under the hood? Git has several main types of objects: blob object, tree object, commit object. And we can juggle between them, there are others, but they are not so important. And by juggling between these three, we can do anything with the repository, with its history, restore it from anywhere, rewind, un-rewind, rebase, and so on. So, what is a blob? It's taking a file, its raw content, and putting it into this blob, calculating a hash. The hash is needed for what? For addressing, to understand where in the blob it is stored. Here, here it is. Where is this blob stored? In which folder and in which binary file. There's a tree. Tree is a directory, respectively, and it's a representation of a folder, a folder structure, right, because we have here, for example, no folders. But if I suddenly create a new folder, say, src, as in many projects, right, and in this, in src, I create some, I don't know, index.js. JS. And so, index.js will be one blob, right, with a hash, but the src folder itself will be a tree object. It will be represented as a tree object, which will store the hashes of its contents, or other trees, that is, nested folders, or hashes of specific files, like index.html files. Well, and we have a commit object, which also refers to some tree, to the previous commit, and so on. In general, we have

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

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

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

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

Теперь погнали поговорим про ветки. Значит, я введу команду клиarр, чтобы всё очистить, и поговорим про ветки. Так, сначала у нас там есть одно новое изменение srcindex, да? А давайте сделаем 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.