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 do, warning, data. Можно нажать зелёную вкладку 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 запушили. Тем временем, тем временем в facts, facts, кстати, у нас я букву "т" пропустил. Какой-то fact block получается. О'кей, здесь ничего такого нет. И я только собираюсь разрабатывать, и мне мой коллега говорит: "Слушай, я там уже начал разрабатывать следующий блок, да, чтобы, ну, не было конфликтов, чтобы ты нормально его вставил. Подтяни себе изменения. У меня пока там один коммит. Можешь его cherry-pick-нуть. Cherry-pick-нуть. Мы такие: "М, мы же профессионалы, мы просто визарды Git, мы знаем, что это такое". Всё очень просто. Мы идём в ветку, которую нам указал человек. Указал он нам project block, да, что в ней работает. Мы находим этот коммит. Вот start project block, да, и мы делаем вот так вот правой клавишей и cherry-pick commit. Он нам предлагает cherry-pick commit to a branch. В какую ветку-то? В facts block, да, cherry-pick commit. Всё, я переключился. Вы видите ветку facts block. Тут появился этот коммит. То есть, что такое cherry-pick? Это просто взять коммит из одной ветки и скопировать его в другую ветку, да, чтобы тут тоже были эти изменения. Всё, мы не делаем дополнительных pull requests каких-нибудь, не подтягиваем изменения туда, создавая лишний этот 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 на нашей суперсхеме. Итак, её сначала я выровняю быстренько. Перемотает этот момент. О'кей. От блока "наша миссия". Мы с вами сделали новую ветку, и в неё мы уже успели сделать start. Start "наши проекты". Вот уже успели начать делать. Теперь я что предлагаю вам сделать? Мы с вами сделаем продолжение некоторое. То есть добавим карточку. Карточку, там две у нас есть. Давайте карточку три добавим, третью и просто добавим ещё карточку четыре. Вот. То есть у нас будет ещё два коммита. Мы изготовим в этой ветке, и получится такая картина. А тем временем в главной ветке мы сделаем футер. Представьте себе, то есть здесь вот, например, будет start footer, да, и будет ещё один продолжение footer. Вот смотрите, то есть у нас получится так, что а есть в одной ветке три коммита, но параллельно ей делались другие коммиты. Теперь, если мы будем вливать эту ветку в нашу ветку main, произойдёт merge request, который мы уже делали. Мы уже с вами это видели в истории коммитов, когда делали три восклицательных знака, да, что они объединились, что был start block, start mission block, это picture. Это всё оно объединилось и встало по времени, как оно выстраивалось. Вы это могли видеть буквально там сколько, 10 минут ролика назад. Хорошо. А и создался вот такой вот омерзительный коммит. Merge pull request. Потом ещё ветки другие мержили, тоже были мержи. Ещё merge 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 коммитов наверх мейна. То есть наверх мейна. Видите? А уже закрыл. То есть наверх мейна, что означает? Что у нас было ещё два коммита после отделения, да? И мы сдвигаем, то есть наверх добавляем. О'кей, нажимаю 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, да? То есть он теперь они есть в этой ветке, да? Потому что он историю переписал, как будто бы они начались с них. Дальше сверху идут коммиты. Как было написано, он топ, да, на топ, то есть start footer. Footer - это есть топ мейна. На него пошли 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. Всё, я merge. Тем временем хочу залететь в 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 для ветки, которая facts block. Ну facts. О'кей, о'кей. FS, да, делаю для неё pull request. Вот она на один коммит впереди мейна. Здесь добавляется просто блок фактов, да? Я создаю 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. Смотрите, я перешёл в ветку

фактS block. О'кей. И там внизу у нас есть вот факты о бобрах, да.

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

Итак, для тех, кто не хочет всё смотреть, как делать в HTML, я также это перемотаю. Так, мне стало мало двух коммитов, решил, что нагляднее будут показать, когда два коммита уже запушены. И видите, два коммита ещё не запушены. Давайте все вчетвером их завоюем и сквошнем. Сквош коммит вот summary. А плюс 1 2 3 4 факт, да? Сквош коммит, сквош процесс чик. Всё, вот они все стали одним коммитом. Мы должны сделать пуш. Чпонькс. Всё, теперь это один коммит. В общем, у нас было четыре коммита, два запушенных, два незапушенных, и мы все их вместе сделали в один коммит и запушили это один коммит. Всё. Вот так работает сквош. То есть можно делать историю почище.

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

Смотрите, наш репозиторий приватный, то есть, чтобы его получить, наверное, нужны какие-то кренды, то есть логин, пароль, что там вроде. Как вообще у нас получается код? Код мы можем получить, видите, написано clone, потому что есть такая команда Git Clone. Мы сейчас ей будем ей пользоваться. И можно склонировать по HTTPS, по SSH, как раз-таки тому самому супербезопасному варианту. И GitHub CLI - это как раз-таки просто вспомогательная программа для Гитхаба. Мы не будем её рассматривать, это нам не нужно. Раз уж консолью, то всё по хардкору, всё по-нормальному.

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

Теперь, значит, тут пишем Git Clone, команда Git Clone, да, и просто вставляем вот этот вот HTTPS штуковину. Нажимаем Enter. Он просит у меня username. Смотрите, неважно, я специально введу неправильные username и password. И вот что мне напишет, что поддержка аутентификации по паролю, по паролю, да, она уже давно removed. Она 13 августа двадцать первого года. То есть это прошлый век, дружище, прошлый век, да, у тебя там она failed, потому что неправильно вёл логин пароль, но задумайся, задумайся, это прошлый век, давай по SSH.

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

Давай сначала попробуем, не имея никаких SSH ключей, скопировать всё это. Я выбираю вариант SSH. Вот он мне показывает GitHub, тампыры, всё вот, что мне нужно. Я пишу то же самое: Git clone. И вот так вот он пытается склонировать. Потом мне говорит, что permission denied public key, то есть видите, публичный ключ есть. Публичный ключ, есть приватный. Вот, в общем, публичный ключ не подошёл. Да, давайте сообщим Гитхабу наш публичный ключ, чтобы этот вариант всегда подходил и у нас не было проблем с авторизацией.

Загуглив документацию Гитхаба, можно найти, как добавляются туда ключи. Ну а мы попробуем с вами сделать это по памяти. Значит, SSH-keygen, есть такой такая утилита. Дальше пишем -d. И тут нужно выбрать тип шифрования. То есть опять же тип шифрования - это всё туда, к докладу, к видосам про шифрование и тому подобное. Просто есть разные варианты, как создать шифр, да, вот опять же попросту, начиная от машины Тьюринга, заканчивая тем, что у нас сейчас квантовые компьютеры будут делать.

Итак, мы выбираем для Гитхаба подходящий классный тип шифрования ED25519 называется этот вариант шифрования. Опять же, это всё запоминать не нужно. Эти команды вы можете тупо перепечатать с экрана либо найти в доках и всё. Я просто лишние комментарии делаю, чтобы, ну, не совсем было, как будто бы мы там бьём по клавиатуре и ждём результат, правильно? Чтобы вы хоть что-то понимали, что вообще происходит. Дальше -C. И тут пишем свой email. У меня будет вот такой email. Как вам мой email? Вот.ru. Вот. Вот такой вот. Давайте сделаем чуть поменьше шрифт, чтобы всё влезало. И я после этого вот закрытие кавычки нажму Enter. Generating public private ED25519 key pair. Вот он. Сделает нам пару ключей. Смотрите, он предлагает это поместить вот в такой файл. Давайте сделаем всё-таки ещё больше. Вот так. Вот в такой файл user@черняков-sштпрестап. Я вам предлагаю взять то же самое, но чуть изменить. Давайте сделаем там slash или лучше нижнее подчеркивание GH как GitHub, да, чтобы вдруг у меня в этом файле есть какие-то другие ключи, они там перезапишутся и так далее. Давайте, у нас будет отдельно вот такая штука. Поэтому он в скобках пишет туда, куда он сохранит. Если я просто нажму Enter, то есть по умолчанию, но я могу вместо этого ввести. А куда дальше? Он предлагает мне ввести passphrase, да, для этого просто нажимаете Enter. Никакой passphrase нам не нужен. Нам хватит самой безопасности этого ключа. Всё, у нас такой причудливый рисунок получился. Вот что-то он там сгенерил себя.

И теперь пишем следующие строчки. Это опять же тоже можно всё найти в интернете, но у вас это будет здесь видео. Eval SSH-Agent. Мы запускаем наш SSH-агент, тот агент, который, собственно, передаёт SSH ключи при наших подключениях. Вот тут написано, что агент запустился, да, и у него PID - это process ID. Это в операционной системе айдишник этого процесса, где он запустился. Теперь пишем следующую команду SSH-add и добавляем вот наш новоиспечённый файл. Он был там в конце у нас было нижнее подчеркивание GH, да, ~/.ssh/id_ed25519_GH. Всё, отлично.

Теперь нам нужно взять этот ключ публичный и сообщить его Гитхабу, как мы это будем делать? Есть всевозможные варианты и от разных операционных систем. Собственно, по-разному будет зависеть, каким образом мы копируем, что. Но давайте поэтому не будем использовать какие-то утилиты для копирования сразу из командной строки, а мы возьмём просто и сделаем всё в руку, вручную. Вот SSH, да, и у нас там было id_ed25519_GH, да, всё супер он. И нам нужно взять вот точка pub, то есть публичный ключ. Нам надо увидеть, как выглядит. Вот так он выглядит. Вот эта строчка с безумным ключом. Это вот оно.

Теперь мы просто идём в GitHub. В Гитхабе мы берём Profile settings. В settings'ах у нас будет SSH and GPG keys. Можем сделать новый SSH ключ. Добавить сюда этот ключ. Я вам так палю спокойно, потому что я его удалю после записи видео. Понятно? Вот так вот. А дальше можем ввести, давайте он будет называться просто имя, чтобы его отличать. MacBook это SSH. Он просит GitHub Mobile, я беру свой телефон, потому что на телефон в GitHub Mobile может прийти такая такой род авторизация. Я должен здесь подтвердить, что действительно какой-то SSH ключ ввожу, потому что секьюрность должна быть секьюрной. Понятно? Вёл вот я это число. Опа, всё сразу всё само сделалось. Отлично.

Теперь смотрите, что я делаю. Возвращаюсь назад, нажимаю кнопку стрелку наверх. Я возвращаюсь к этому. Git clone git@github.com:.... Вот наш SSH команда. Нажимаю, он думает чик. Но при этом он всё скачивает. Смотрите, всё скачал. Теперь что можем посмотреть? Вот, ls - содержимое папки. Вот BER Defender у нас есть. Всё, он склонировался весь код отсюда. И вам это понадобится, потому что, ну, все репозитории будут, разумеется, приватные. Поэтому вы попадёте там на работу или вы уже на работе, но делаете это всё через GitHub Desktop или с помощью HTTPS. Имейте в виду, что можно так и SSH ключ сделать, закинуть в свою учётную запись в вашем Гитхабе, Гитлабе, неважно, и всё будет работать.

Кстати, про GitLab. Ну и давайте сразу посмотрим, как это делается на Гитлабе. Я зашёл на GitLab, но не на обычный GitLab, а на GitLab.ru, потому что это наш, собственно, GitLab, который поднят для нужд менторинга. Кстати говоря, у нас есть менторинг по фронтенду с оплатой за результат. То есть вы заплатите после получения новой зарплаты в IT, первой зарплаты или новой. И это, разумеется, в том числе для вас, потому что максимальный стаж человека, который у нас учится, 5 лет реального коммерческого опыта, минимальный - отсутствие опыта в целом. И всем ребятам помогаем реализовываться, получать первую работу в IT, получать восьмую работу в IT с новой зарплатой, новым грейдом и так далее.

Итак, на Гитлабе смотрим. Значит, у нас есть Edit profile, там есть SSH. Вот сюда добавляем новый ключ. Можем его просто ещё раз скопировать, потому что там будут валидация, он не пропустит. Простой отключу. Он даже называет его сразу, видите, тайтл последней строкой. И можем сделать Add key. Всё отлично. У нас теперь новый SSH ключ добавлен. Вот тут на данный момент третий. На мене мы практикуемся с гитом, настраиваем все CI/CD пайплайны и, в общем, всё деплоим там. Фам-фа-фа, у нас там кружочки и так далее, автоматизация полная. В общем, выжимаем из гитхаба все соки.

И, кстати, очень важная штука. Меня часто спрашивают, есть ли у Гитхаба аналог такой штуки, как GitHub Desktop. Она не нужна, понимаете? GitHub Desktop работает с технологией Git. А будет это GitLab, GitHub, Bitbucket или какой-то ваш самопальный Git, неважно. Поэтому GitHub desktop работает и с GitLab'ом тоже. Так что расслабьтесь. Прога классная, удобная, очень сильно дружелюбная.

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

Значит, смотрите, что я сделаю. Я, во-первых, нахожусь сейчас в Git_examples папке. Вот на всякий случай она у меня тоже открыта здесь в проводнике, чтобы была. И в ней я могу сделать так. mkdir MKDIR такая команда. А git назову. Вот видите, создалась папка git. Да, команда не соврала, это и делает. Перешли в test_git. И тут мы можем сделать git init initialized empty Git repository. Вот здесь. Отлично. И видите, даже написал точка Git. Значит, в чём прикол? Если откроем test_git, видим, что там появилась папка .git. То есть всё, всё, что отличает обычную папку от Git репозитория, наличие папки .git. Уу. Отлично.

Содержимое папки .git мы с вами посмотрим позже. Сейчас для удобства я открыл эту папку Git внутри WebStorm, потому что нам, в принципе, не понадобится никакой код запускать, смотреть в браузере. Нам потребуется только здесь жёстко работать с консолью. Значит, во-первых, вы можете заметить, что здесь почему-то нет ээ .git файла папки. И обычно скрывают айдишки. Я вам покажу, как в WebStorm её показать. А то, какая она показывается в других IDE, это уже надо вам загуглить будет. Вашей любимой editor file types ignore file and folders. И вот обычно она здесь лежит как бы как игнорируемая. Вот точка Git. Можем её удалить. Я потом это верну, потому что действительно она никому не нужна, но нам будет нужна для наглядности. Вот мы можем шик посмотреть. Вот вся информация про Git репозиторий лежит вот тут. О'кей. Хорошо.

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

Скажу вам, что у файлов в гите есть три состояния: это untracked, staged и tracked. Ну, то есть закомиченные. Итак, разбираемся с первыми, с untracked. У Git есть такая команда Git status, чтобы посмотреть статус вообще файлов, что там происходит. Открываем его и видим, что у нас есть untracked файлы, это .DS_Store и README. И по факту, по факту тот, который изменённый файл, вот сейчас вот index.html, он тоже untracked, потому что, ну, мы с ним ничего не сделали пока ещё. Это просто те файлы, которые, если мы сейчас их удалим, то всё, они пропадут навсегда. Они не успели попасть в историю Git. То есть untracked, да, они untracked, за ними никто не следит. Вот если даже переводить так впрямую.

Давайте с вами проведём маленькое упражнение. Вот смотрите, вот эти два файла вот .DS_Store. Они нам будут мешать, что бы мы могли бы с ними сделать, чтобы Git их игнорировал. Подсказка, конечно, сделать .gitignore. И давайте я просто сделаю .gitignore на этот счёт. Всё, теперь смотрите, я вызвал Git status ещё раз. У нас вот есть README красиво модифицирован, да? Git ignore и index. Всё, changes, которые должны быть закомичены. Хорошо.

Второе состояние - это staged. И тут, кстати говоря, мы приходим к вопросу, которые часто задают, что такое индекс. Вот часто слышат, да, что есть какой-то индекс в гите, что-то такое. В общем, stage area и индекс - это одно и то же. И индекс - это промежуточная область в гите, где хранятся подготовленные файлы, которые готовы к коммиту. И как же файлы перевести в состояние stage? Как добавить их в индекс? Есть простая команда Git add. Тут мы пишем тот файл, который можно перевести. Например, index index.html добавил. Давайте ещё раз сделаем Git status. И мы видим, что modified у нас остался только Git ignore. Чтобы добавить абсолютно все файлы, мы можем использовать Git add и ставим точку. Точка просто рекурсивно пройдёт в и вообще все файлы, которые были modified, добавит в stage. Всё, ещё раз. Git status. Всё, у нас теперь есть два файла новых. Отлично.

Теперь осталось перевести их в третье состояние, то есть tracked. Их надо закомитить, то есть сделать коммит. Как делается коммит не в GitHub Desktop, а в консоли. А вот сейчас мы посмотрим. Но сначала мы откроем GitHub Desktop, чтобы он визуально нам показывал. У вас было больше понимание о том, что же происходит, когда мы вводим эти самые команды. Вот я открыл GitHub Desktop. Он не становится меньше, поэтому извините, это минимум. Вот у нас есть два файла, да, changes files. Вот они добавлены. Шикарно. Как делать коммит? Пишу Git commit. Неожиданно, да? Дальше -m - это message означает. В кавычках могу написать message, э, my awesome commit, как вам такое, мой восхитительный коммит. Нажимаю Enter, они добавились, видите, create mode, Git ignore, все дела, всё, они добавились. Нажимаю сюда, чтобы здесь всё обновилось, да, всё коммит сделан. То есть как будто бы я нажал коммит реально осталось только нажать publish. Ну, в данном случае publish repository, да, на GitHub, что мы его там даже не паблишили. Ну, если я нажму, то он мой аккаунт его запихнёт туда и всё это запушит. Соответственно, пушить - это уже отдельная тема. Это коммиты уже созданные. Куда-то заливать на другой удалённый сервер. А мы можем нажать history и увидим, что вот my awesome commit. Всё, коммит создан. Вот так всё просто создаётся. То есть мы берём, делаем Git add, то, что нужно в коммит добавить. Соответственно, считай вот как чекбоксы мы здесь всё выделяем, да? То есть добавляем. Дальше мы делаем Git commit. Всё, оно полетело внутрь. Отлично. Git commit создан.

Теперь, если вы думаете, что мы пройдёмся по всем вот этим кнопкам и как они будут командами, это не так. Сейчас будет гораздо всё интересней. Значит, сейчас мы познакомим с вами, что такое хэш. Вот у каждого коммита вы могли видеть, что есть какой-то F5961 и так далее. Вот он тоже здесь написано F5691. Что же это такое, в конце концов? Это уникальный идентификатор хэш. Опять же, это не про шифрование, это не про хэширование, да, лекция, поэтому я не могу вам тут полностью рассказать, что такое хэш. Но в двух словах, хэш - это результат хэш-функции. Вау, да, странно, да? Хэш-функция - это такая штука, которая на вход принимает какие-либо данные и должна вернуть абсолютно уникальную строку, собранную из этих данных. То есть, если дальше этой же хэш-функции дать точно такие же данные, она должна вернуть хэшик вот этот вот эти цифры непонятные, один в один такие же. При этом, если в этих данных поменяется хотя бы маленькая крупица информации, то хэш должен быть совершенно другой, чтобы избежать коллизии. Коллизия - это когда не совпадение хэшей. Но мы с вами на минутку остановимся здесь про хэши поговорим.

Смотрите, давайте попробуем сделать хэш из файла index.html. Да, смотрите, у нас есть такая утилита sha-sum, да, это как раз-таки хэш. Здесь дальше можем указать, какой именно алгоритм хэширования. И у нас GitHub использует, по-моему, SHA, но это неважно. Там дальше SHA-256 идёт, по-моему. Неважно. Это просто разные алгоритмы хэширования. Как же так же, как вот с созданием SSH ключа говорил, что мы выбирали алгоритм. Также здесь есть разные алгоритмы, да. Вот здесь мы возьмём SHA1, а1 и дальше путь к файлу. Вам не нужно всё это запоминать. Это всё легко гуглится о том, как сделать хэш. Я нажимаю вот так. Чик. Вот он дал мне хэш. Он высчитал хэш. Обратите внимание, какой он. Теперь я возьму, во-первых, давайте сделаем ещё раз этох ш один и тот же. Но если я сделаю маленькое изменение, например, удалю вот этот айдишник отсюда и сделаю хэш ещё раз, видите, он абсолютно другой. То есть я поменял даже меньше, чем одна строчка. То есть это сколько это там, не знаю, дай бог, 1% файла я поменял на, скорее всего даже меньше. Ну а хэш полностью другой. Вот 03E7FD. В общем, он абсолютно абсолютно другой. То есть хэш - это про уникальность.

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

Теперь давайте я рядом создам ещё один файл. Будет просто любой, не знаю, пи, как у нас тут принято на канале, да, и в сообществе MD. MD - это разметка Markdown, так называемая. Значит, пускай будет какой-то, э, у неё заголовок. Вот так вот. И мы его закоммитим. Как это делается? Давайте, помните, как я делаю Git status. Мне не обязательно нажимать. Я так понимаю, что там есть незакоммиченные, поэтому Git add делаю. Всё сделал. Git commit. Э-э, message file. Всё, я добавил md файл. Тут, кстати, смотрим, вот коммит новой появился. Всё, отлично. У меня есть два коммита.

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

Мы можем взять и по любому коммиту, вот у нас есть его хэш EC38. Почему, кстати, хэш? Здесь ээ очень много символов, да? А здесь вот очень мало символов, потому что достаточно достаточно первых символов, чтобы уже была полная уникальность. Поэтому Git, чтобы везде не писать кучу вот этого всего. Он пишет совсем немножко символов, но можно и по полному хэшу обращаться к коммиту. Что мы можем сделать с коммитом? У нас есть такое такая команда cat-file, Git cat-file. Дальше пишем пишем вот хэш commit. Написали хэшмета. Таким образом можем посмотреть, что вообще в этом коммите. Есть его дерево. Сейчас объясню, что такое дерево - это папка, образно говоря. Есть его parent. Parent у нас его, как вы понимаете, что это родительский коммит, правильно? Его автор есть вот А Черняков, да, и есть коммитер тоже А Черняков. И тут написано, собственно, а дата в формате timestamp, даже с вот моим часовым поясом +0. Вот сообщение коммита.

Мы можем сделать с Git cat-file и взять туда любой другой хэш передать, потому что всё есть файлы. Кстати, вам нужно просто это понять, да, что всё в гите есть файл. Git создал Linus Torvalds. Он же создатель, соответственно, Линукса, операционной системы. И в операционной системе Linux есть парадигма, да, что всё есть файл. И как вы думаете, он перенёс своё детище на систему Git? Да, перенёс. Потому тоже здесь всё есть файл.

Значит, также можем взять файл к хэшу три, обратиться и увидим, что в этом три, да, собственно, в содержимом коммита есть все файлы. То есть мы вроде бы с вами закомитили только README, а там есть всё: index.html, .gitignore, и, пожалуйста, всё можно посмотреть. А вот blob, да, сейчас по с вами поговорим про то, что такое blob. Я сначала могу взять этот README, также взять его хэш, сделать Git cat-file -p. Ведём этот хэш. Опа. Содержимое файла. Вот оно здесь. Прямо внутри коммита хранится вот вся информация, которая нам нужна для восстановления восстановления чего-либо всего, репозитория, построения всех файлов.

Соответственно, теперь плавно подойдём к блобу, но сначала я в визуальном опять же режиме покажу вам эту папку Git. В чём её прикол? В папке Git есть много чего. Есть Git hooks, потом в будущем научим им пользоваться. Это что делать там до коммита, после коммита, перед коммитом и так далее. Всякие info, logs, это всё нам понятно. Нам нужно вот этот файл, objects. В objects есть такие причётливые папки 6B, 09, 25, 51, что-то такое. Теперь давайте попробуем найти совпадение. 25. Смотрите, 25 6. Смотрите-ка, где-то было 6B. Вот 6B и так далее. То есть первые два символа хэша - это под папка, где лежит. А дальше вот такая штука пошла. Видите, здесь лежат, что мы не можем это посмотреть, потому что просто бинарные данные. Всё, там у нас внутри лежат нолики, единички.

Соответственно, как на самом деле под капотом работает Git? В гите есть несколько основных типов объектов: это объект blob, объект tree, объект commit. И между ними можем жонглировать, там ещё другие есть, но они не столь важны. И между этими тремя мы можем как бы жонглируя делать что угодно с репозиторием, с его историей, восстанавливать его откуда угодно и так далее, перематывать, отматывать, rebase и тому подобное. То есть, что такое blob? Это берётся файл, его сырое содержимое и кладётся в этот blob, вычисляется хэш. Хэш, нужно для чего? Для адресации, чтобы понять, где в блобе это там он лежит. Вот, вот он лежит, пожалуйста. Где этот блобчик лежит? В какой папке и в каком там дальше бинарном файле.

Есть tree. Tree - это дерево, соответственно, и это некая репрезентация папки, папочной структуры, да, потому что у нас есть это здесь у нас, например, нет папок. Но если я вдруг создам какую-то новую папку, будет, не знаю, src, как во многих проектах, да, и в этом, а, в src я создам какой-нибудь, не знаю, там, index.js. JS. И вот у меня, соответственно, будет index.js - это будет один блоб, да, с хэшем, но сама папка src - это будет как раз-таки объект tree. Она провест в объект tree, в котором будут храниться хэшики его содержимого, либо других tree, то есть вложенных папок, либо хэшики конкретных файлов, уже как файлы index.html. Ну и у нас есть объект commit, который ссылается также на какой-то там tree, на родительский коммит и так далее. В общем, у нас

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

То есть, смотрите, если всё, что я сейчас сказал, немножко обобщить и даже немножко упростить, то получается 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.