Системы контроля версий существуют, чтобы исключить досадные ошибки, которые могут откатить назад результаты, например, двухнедельной работы команды разработчиков. Такой инструмент помогает отслеживать изменения, особенно если работа над проектом ведется параллельно несколькими специалистами.
Git ー популярная платформа для работы с версиями проекта. Это ー распределенная система контроля версий или VCS (Version Control System). Version Control в данном случае означает, что в любой момент можно вернуться к нужной версии документа. А под распределённостью имеется ввиду, что системой может одновременно пользоваться множество специалистов.
Кстати, Git уже давно вышел за рамки применения только в IT-компаниях. Им пользуются и в других направлениях, где есть командная работа над техническими проектами.
Области данных в Git
Чтобы легче понять работу команд, кратко разберем области данных. В системе Git их три: рабочая директория, индекс, репозиторий.
Рабочая директория содержит в себе файлы, с которыми работаете. Также это могут быть файлы, только что извлеченные из истории проекта. При переключении между ветками файлы в Working Directory можно удалять или изменять. По этому поводу переживать не нужно, так как история сохранена в Git-директории. А рабочая директория ー временное место для работы с файлами.
Git-индекс ー промежуточная локация для изменения файлов на пути от рабочей директории к репозиторию. Здесь хранятся изменения между уже зафиксированными в репозитории данными и теми, что еще лежат в рабочей директории. После выполнения команды git commit информация из индекса переходит в репозиторий с соответствующими ссылками.
Репозиторий представляет собой хранилище файлов проекта. Это место, в котором хранится код с данными о выполненных изменениях. Репозиторий может размещаться как на удаленном сервере, так и на физическом компьютере.
Базовые команды: checkout git
В работе с репозиторием под командой checkout git (git checkout) подразумевается переключение между версиями для трех видов объектов. К ним относятся файлы, коммиты и ветки. Кроме функции переключения между branches, это действие используется и для просмотра старых commits.
Как происходит переключение веток? Процесс аналогичен шифтингу между старыми коммитами и документами, где каталог обновляется по выбранной ветке (или ревизии). При этом новые изменения остаются в истории, потому что операция checkout git ー это не только функция чтения.
Команда git checkout commit: проверяем коммиты
Одним из простых действий в репозитории является команда git checkout commit. Она используется для обновления состояния репозитория до конкретной точки в истории проекта. При запуске с именем ветки, созданной через git branch, действие позволит переключаться между разными ветками. В дополнение есть возможность запустить commit id git ー нужная функция SHA-1 hash для любого коммита. Что проверяем с ее помощью:
- полное содержание;
- дату коммита и пользователя, запустившего коммит, и имейл;
- логи;
- ID предыдущего коммита
При изменении любых данных из вышеперечисленных автоматически меняется и ID. Один и тот же commit с идентичными свойствами будет определен одним ID на другом компьютере. Это связано с тремя целями:
- помогает системе определять, были ли изменения в коммите;
- сравнивать commits проще по ID, что делает работу с протоколами Git гораздо эффективнее;
- у двух коммитов с одинаковым ID будет одинаковая история. Например, если содержание commit идентичное, но родители разные, commit id будет другим.
Опция эффективно работает при заливке в репозиторий и извлечении данных из него. Как фактически выполнить действие git commit? В общих случаях нужно ввести команду, откроется редактор, где нужно будет описать ваш коммит.
Проверка последних изменений в проекте (git get last commit id)
Если хотите проверить недавние действия в проекте или, другими словами, посмотреть ID последних коммитов (git last commit id), используйте команду git log. Она выдает список с последними коммитами в хронологическом порядке (в начале показан последний коммит). Также с помощью команды git log -n 1 после действия git checkout branchname можно проверить hash, автора, дату и сообщение коммита в последнем из них.
Как выполнить команду git checkout/clone commit id (SHA)?
Бывают ситуации, когда необходимо сделать проверку или клонирование из определенного git commit id. Ниже рассмотрим действия:
- Выполните клонирование репозитория или сделайте выборку последних изменений и коммитов.
- Выберите commit ID (SHA), который нужно проверить (его можно найти в логах git log).
- Скопируйте commit (SHA) id и выполните проверку через следующую команду: git checkout 28cd74decb47d8a5294eb59e793cb24a0f242e9e
Также можно использовать сокращенный вариант: git checkout 28cd74de. Обратите внимание, что такая проверка будет находиться в состоянии detached HEAD – об этом расскажем далее в статье. Если хотите выполнить изменения, нужно создать ветку: git checkout -b. Например, git checkout -b test-branch 7d4c59f5. Она унаследует все из commit ID в test-branch.
Действие git checkout head (Detached HEADS)
В дополнение к информации о приведенных выше командах следует обязательно упомянуть о состоянии detached HEAD. Иногда встречаются запросы в формате git checkout head, но такое описание команды не корректно. Чтобы избежать путаницы, расскажем чуть больше о HEAD.
С помощью HEAD Git делает отсылку к текущему снэпшоту. Команда checkout git (git checkout) просто обновляет HEAD для того, чтобы указать на определенную ветвь или коммит. При указании на ветку Git обычно не выдает ошибку, а вот при отсылке к коммиту система переходит в режим detached HEAD. Git предупреждает: все, что делаете в настоящий момент «обособлено» от остальной части проекта.
Например, если вы работаете над какой-то опцией в режиме detached HEAD state, по итогу у вас не будет ветки, позволяющей вернуться к этой части. А если попробуете сделать мёрдж того, над чем работаете, то не сможете выполнить отсылку к этой части. Из этого делаем вывод, что работать с любыми изменениями необходимо на ветке и никогда в detached HEAD state.
Клонируем репозиторий: работает ли git clone specific branch?
Клонирование репозитория обычно выполняется единоразово, в начале работы с проектом. Если репозиторий уже создан, к примеру, на GitHub, его можно копировать и работать с проектом локально. Для дальнейшей разработки клонировать репозиторий повторно нет необходимости.
Часто можно встретить вопрос, включает ли клонирование копию коммитов и отдельных бранчей? В отличие от других платформ, когда мы хотим клонировать коммит в Git (git clone commit) или отдельную ветку, мы клонируем репозиторий. Git clone команда позволяет создать копию всего repository, включая документы, ветки и все коммиты.
Приведем git clone пример: git clone https://github.com/rep/rep. С помощью этой команды создаем клон всех версий (репозиторий в примере называется rep). После этого на сервере создается директория rep, к которой подключается version control support. Появляется папка .git. Репозиторий скопирован с имеющимся названием.
По умолчанию действие git clone (не путать с git clone commit) создает ветки с удаленным отслеживанием для всех бранчей, присутствующих в ремоуте, который скопирован. Единственная локальная ветка, которая создается, и есть ветка по умолчанию. Но если по какой-то причине вы хотите клонировать только ветку с удаленным отслеживанием (для конкретной ветки) или ветку, которая не является дефолтной, используйте –single-branch вместе с git clone. Для копирования конкретной бранчи (или действие git clone specific branch) применяется команда git clone [url] –branch [branch] –single-branch.
Maven Git commit id plugin
Плагин для Maven делает доступными базовые данные о репозитории через ресурсы сервиса. Он является неизменным и добавляется к каждому проекту в Maven. Плагин автоматически создает информацию о версиях во время build, которую можно проверить после деплоя приложения. Плагин помогает с информацией по базовым запросам. Вот git commit id plugin examples:
- Какая это версия?
- Кто и когда выполнил деплой?
- Из какой ветки выполнен деплой?
- В какой версии был баг?
- Исправлена ли версия с багом?
- Подтверди, если характеристики соответствуют требуемым.
Плагин Git commit id plugin доступен на Maven Central. Для его настройки не нужно конфигурировать какие-либо дополнительные репозитории.
Git ー удобная система, в которой вы можете работать командой и держать на контроле все версии проекта. Наверное, самая важная характеристика: система управления версиями дает возможность откатиться до предыдущей версии. Поэтому если вы ー начинающий разработчик, вам просто необходимо подружиться с Git, так как с большой вероятностью вы будете работать на этой платформе.