Ошибки, сложный материал, вопросы >
Нашли опечатку или неточность?

Выделите текст, нажмите ctrl + enter и отправьте его нам. В течение нескольких дней мы исправим ошибку или улучшим формулировку.

Что-то не получается или материал кажется сложным?

Загляните в раздел «Обсуждение»:

  • задайте вопрос нашим менторам. Вы быстрее справитесь с трудностями и прокачаете навык постановки правильных вопросов, что пригодится и в учёбе, и в работе программистом;
  • расскажите о своих впечатлениях. Если курс слишком сложный, подробный отзыв поможет нам сделать его лучше;
  • изучите вопросы других учеников и ответы на них. Это база знаний, которой можно и нужно пользоваться.
Об обучении на Хекслете

Понимание Git

Обилие команд и возможностей могут повергнуть в ужас любого, кто только начинает изучать Git. Git — это комбайн с невероятным количеством «фич». Но надо ли знать их все? И как их запомнить? Как вообще научиться эффективно его использовать?

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

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

Давайте выведем коммиты нашего проекта hexlet-git в специальном виде, который активируется опцией --graph:

hexlet-git$ git log --graph

# Не полный вывод, чтобы не отвлекаться от сути
* commit e7bb5e51f96e572084f6c04ba3312e32ce6b8c0f (HEAD -> master, origin/master, origin/HEAD)
|
|     update README.md
|
* commit 65a8ef7fd56c7356dcee35c2d05b4400f4467ca8
|
|     Revert "remove PEOPLE.md"
|
|     This reverts commit aa600a43cb164408e4ad87d216bc679d097f1a6c.
|
* commit 5120bea3e5528c29f8d1da43731cbe895892eb6d
|
|     add new content
|
* commit e6f625cf8433c8b1f1aaed58cd2b437ec8a60f27
|
|     add INFO.md
|
* commit 273f81cf2117044f1973ea80ce1067a94bea3f80
|
|     remove NEW.md

Обратите внимание на полоску слева. Она отражает связи между коммитами. Каждый новый коммит базируется на коде предыдущего коммита. С точки зрения информатики коммиты выстраиваются в так называемый односвязный список. В таком списке каждый элемент ссылается на предыдущий. Последний элемент при этом называется головой списка (head по-английски).

В Git элементы списка — это сами коммиты. И так же как в односвязном списке, новый коммит (как элемент) имеет ссылку на старый (предыдущий), а предыдущий — на свой предыдущий, и так далее до первого коммита, который никуда не ссылается, так как он первый. Понятие «голова списка» (HEAD) в git присутствует явно и активно используется для разных операций. Например, удаление последнего коммита выглядит так:

# HEAD^1 означает: взять голову и удалить, начиная от нее, один коммит
# То есть только последний коммит
$ git reset --hard HEAD^1

Сам список коммитов тоже имеет название, вы его уже видели: это — master. В терминологии Git такой список называется веткой (branch). Именно поэтому команда для показа текущего местоположения в истории называется git branch:

hexlet-git$ git branch
* master

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

Ветки

Если смотреть дальше, то мы увидим, что Git это не просто односвязный список — это множество односвязных списков, переплетенных вместе.

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

Гит позволяет отпочковываться от основного списка, формируя «ветки». То есть создается отдельный список коммитов, который идет мимо мастера. В конце разработки все коммиты из такой ветки вливаются обратно в мастер.

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


Дополнительные материалы

  1. Ветки в GIT
  2. Trunk Based Development

<span class="translation_missing" title="translation missing: ru.web.courses.lessons.mentors.mentor_avatars">Mentor Avatars</span>

Остались вопросы? Задайте их в разделе «Обсуждение»

Вам ответят менторы из команды Хекслета или другие студенты.

Зарегистрироваться

или войти в аккаунт

Курсы программирования для новичков и опытных разработчиков. Начните обучение бесплатно.

  • 115 курсов, 2000+ часов теории
  • 800 практических заданий в браузере
  • 250 000 студентов

Отправляя форму, вы соглашаетесь c «Политикой конфиденциальности» и «Условиями оказания услуг».

Наши выпускники работают в компаниях:

Логотип компании Альфа Банк
Логотип компании Rambler
Логотип компании Bookmate
Логотип компании Botmother

Есть вопрос или хотите участвовать в обсуждении?

Зарегистрируйтесь или войдите в свой аккаунт

Отправляя форму, вы соглашаетесь c «Политикой конфиденциальности» и «Условиями оказания услуг».

Изображение Тото

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