Git-Терминология - подводные камни

Эффективность контроля версий

Контроль версий является важным инструментом для тех, кто хочет отслеживать изменения в ходе работы над проектом. Это особенно полезно для программистов, системных администраторов и инженеров по надежности сайтов (SRE). Возможность оправиться от ошибок и вернуться к известной стабильной версии – огромный плюс и более надежное средство, чем предыдущая стратегия добавления .old к скопированному файлу.

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

Если у вас есть месяц или два и достаточно любопытства, Git SCM является окончательным источником всех терминов, которые вам нужно выучить. Если же вы просто ищете сводку из окопов, продолжайте читать.

Что такое коммит?

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

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

Нет такого места, как 'origin/master'

Знание того, где вы находитесь в Git-проекте, начинается с размышления о дереве. Все проекты Git имеют корневой каталог, аналогичный идее корневого каталога файловой системы. Все коммиты ответвляются от этого корня. Таким образом, ветвь является только указателем на коммит. По соглашению, master – это имя по умолчанию для стандартной ветви в вашем корневом каталоге.

Поскольку Git является распределенной системой управления версиями, где одна и та же кодовая база распределена по нескольким местам, люди часто используют термин "репозиторий" как способ говорить обо всех копиях одного и того же проекта. Существует локальный репозиторий, где вы редактируете свой код (подробнее об этом через минуту), и удаленный репозиторий, место, куда вы хотите отправить его после того, как закончите. Remotes может находиться где угодно, даже на том же компьютере, где расположен ваш локальный репозиторий, но они часто размещаются в таких сервисах репозитория, как GitLab или GitHub.

Что такое pwd команд Git?

Хотя это и не официальный пункт продажи, быть потерянным – большая часть удовольствия от Git-репозитория. Вы можете найти свой путь, выполнив этот надежный набор команд:

  • git branch – найти ветку, в которой вы находитесь;
  • git log – чтобы увидеть, на каком коммите вы находитесь;
  • git status – чтобы увидеть, какие изменения вы сделали со времени последнего коммита;
  • git remote – чтобы увидеть, какой удаленный репозиторий вы отслеживаете.

Ориентация себя с помощью этих команд даст вам ощущение направления, когда вы застряли.

Я спрятал или кэшировал свой коммит?

Код, локальный для вашего компьютера, в разговорной речи называется вашим рабочим пространством. Что не сразу очевидно, так это то, что у вас есть два (да, два!) других локальных местоположения, когда вы находитесь в репозитории Git: index и stash. Когда вы пишете некоторый контент, а затем добавляете его, вы добавляете его в индекс, то есть кешированный контент, который готов к фиксации. Бывают случаи, когда в индексе есть файлы, которые вы не готовы зафиксировать, но хотите просмотреть другую ветку. Вот где stash и пригодится. Вы можете сохранить в хранилище проиндексированные, но еще не зафиксированные файлы, используя git stash. Когда вы будете готовы получить файл, запустите git stash pop, чтобы вернуть изменения в индекс.

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

  • git diff ..origin/master – показать разницу между самой последней локальной фиксацией и удаленным, называемым origin, и его ветвью, называемой master;
  • git diff --cached – показать любые различия между самой последней локальной фиксацией и тем, что было добавлено в локальный индекс;
  • git stash – для помещения проиндексированных (добавленных, но не зафиксированных) файлов в стек stash;
  • git stash list – чтобы показать, какие изменения есть в стеке;
  • git stash pop – чтобы извлечь самые последние изменения из стека.

HEADless

Git – это коллекция всевозможных метафор. Когда я думаю о том, где находится HEAD, я думаю о железнодорожных линиях. Если вы в конечном итоге в режиме HEAD, это означает, что вы находитесь вне метафорических рельсов.

HEAD – указатель на ваш самый последний коммит в текущей checkout-ветке. По умолчанию "checkout" происходит, когда вы создаете Git-репозиторий и попадаете в основную ветку. Каждый раз, когда вы создаете или переходите на другую ветку, вы находитесь на этой ветке. Если вы сделаете git checkout <commit> где-то в вашей текущей ветке, HEAD перейдет к этому коммиту. Если у вас нет истории коммитов, связывающей ваш текущий коммит с коммитом, который вы извлекли, то вы окажетесь в отключенном состоянии HEAD. Если вы когда-нибудь потеряете голову, пытаясь понять, где находится HEAD, вы всегда можете выполнить git reset --hard origin/master, чтобы удалить изменения и вернуться в известное состояние.

Предупреждение: это удалит все изменения, которые вы внесли с момента последнего нажатия на мастер.

Локальное хранилище

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

Например, скажем, я хочу внести свой вклад в Kubernetes. Сначала я бы подключил проект kubernetes/kubernetes к своему аккаунту, mbbroberg/kubernetes. Затем я бы клонировал свой проект в мое локальное рабочее пространство. В этом сценарии мой локальный клон – это мой локальный репозиторий, mbbroberg/kubernetes – мой удаленный репозиторий, а kubernetes/kubernetes – отслеживаемый.

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

Подытожим:

Commit – сохраняет текущее содержимое индекса в новой фиксации вместе с сообщением журнала от пользователя, описывающим изменения;

Branch – указатель на коммит;

Master – имя по умолчанию для первой ветви;

HEAD – указатель на самый последний коммит в текущей ветви;

Merge – объединение двух или более историй коммитов;

Workspace – разговорное имя для вашей локальной копии Git-репозитория;

Working tree – текущая ветка в вашем рабочем пространстве. Вы видите ее в выводе состояния git все время;

Cache – пространство, предназначенное для временного хранения незафиксированных изменений;

Index – кэш, в котором хранятся изменения до их фиксации;

Tracked and untracked files – файлы либо в кеше индекса, либо еще не добавлены в него;

Stash – еще один кеш, который действует как стек, где изменения могут храниться без их фиксации;

Origin – имя по умолчанию для удаленного хранилища;

Local repository – еще один термин для хранения вашей копии Git-репозитория на рабочей станции;

Remote repository – вторичная копия Git-репозитория, куда вы вносите изменения для совместной работы или резервного копирования;

Upstream repository – разговорный термин для удаленного репозитория, который вы отслеживаете;

Pull request – специфичный для GitHub термин, который позволяет другим узнать об изменениях, которые вы добавили в ветку в хранилище;

Merge request – специфичный для GitLab термин, чтобы сообщить другим об изменениях, которые вы добавили в ветку в репозитории;

origin/master – настройка по умолчанию для удаленного репозитория и его первичной ветви.

Наверх
Меню