Как Git упрощает работу с кодом

Минимум, который должен знать каждый разработчик.

Системы контроля версий (Version Control Systems) отслеживают изменения в файлах. VCS помогают разработчикам фиксировать состояние кода и возвращаться к предыдущим версиям. С помощью систем контроля девелоперы могут одновременно работать над одним проектом, не ломая код друг друга. VCS делает слепки файлов, к которым можно вернуться после любых изменений. Самая популярная система — Git. Рассказываем, как управлять версиями кода с ее помощью.

Начало работы

Управление состоянием кода в git происходит с помощью текстовых команд в терминале. Для первоначальной конфигурации используется команда git config с указанием имени пользователя и почты.

git config –global user.name "name"
git config –global user.email "name@gmail"

Ко всем командам можно добавлять флаги (опции), модифицирующие выполнение. Например, global указывает, что изменения будут касаться глобальной конфигурации пользователя. Данные пользователя будут использоваться при создании коммитов для идентификации автора.

В Git код размещается в репозитории — локальном (на ПК), удаленном (на сервере), распределенном (и на ПК, и на сервере). Локальный репозиторий создается в рабочей директории командой git init. Если нужно загрузить (клонировать) репозиторий с удаленного сервера на ПК, вводится команда git clone с указанием ссылки на сторонний репозиторий или SSH (протокол передачи данных).

H:\SOURCE\LMS>git clone https://github.com/instructure/lms.git
Cloning into 'lms'...
remote: Enumerating objects: 737104, done.
remote: Counting objects: 100% (37790/37790), done.
remote: Compressing objects: 100% (10079/10079), done.
remote: Total 737104 (delta 28167), reused 36757 (delta 27184), pack-reused 699314
Receiving objects: 100% (737104/737104), 921.15 MiB | 15.16 MiB/s, done.
Resolving deltas: 100% (566500/566500), done.
Updating files: 100% (16751/16751), done.

Изменения из склонированного репозитория загружаются командой git pull.

H:\SOURCE\LMS>git pull
Already up to date.

Добавление файлов

У файлов есть три состояния:

Untracked — файл еще не добавили в репозиторий;
Modified — файл уже был в репозитории и его изменили;
Staged — проиндексированный файл, который можно добавить в репозиторий.

Посмотреть состояние файлов можно с помощью git status.

On branch main
Your branch is up to date with 'origin/main'.
 
nothing to commit, working tree clean

В репозиторий добавляются только staged файлы. Файлы индексируются командой git add. Можно выбрать:

все файлы с помощью флага –а;
часть файлов по имени или расширению.

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        new file:   new_file.txt

Логи и файлы сборки не нужно индексировать. «Лишние» файлы записывают в .gitignore — специальный текстовый файл в корневом каталоге, где указаны исключения. Git читает этот файл и пропускает исключения.

# Compiled class file #
*.class

# Log file
*.log

# Package Files #
*.jar
*.war
*.nar

# Build directory #
build/

Синтаксис gitignor простой:

пустые строки при чтении игнорируются;
файлы и каталоги указываются с новой строки;
комментарии отмечаются #;
указывается имя или расширение файла;
директории отмечаются /.

Чтобы не писать gitignore самостоятельно, можно сгенерировать его с помощью стороннего сервиса — например, gitignore.io.

Коммит — это операция по добавлению всех проиндексированных файлов в репозиторий командой git commit –m “changes message”. Флаг –m вносит описание изменений. У коммитов есть имя автора, время добавления, хеш и описание внесенных изменений. Для отправки на удаленный сервер нужно ввести git push.

Чтобы ориентироваться во всех коммитах и отслеживать историю изменений, можно воспользоваться командой git log. log возвращает описание всех коммитов, их хеш-функцию и авторов, коммиты выводятся в порядке от новых к старым.

    Init commit 
 
commit 429211da2fd03394e9c53c32f73cr964f3bad436
Author: Dmytro <dmytro@gmail.com>

курс по теме: Алгоритмы и структуры данных

Артем Верещака Tech Lead в Bolt

Git Flow

Программисты одной команды пишут разный функционал приложения одновременно. Чтобы управление разработкой было эффективным, используется практика разделения репозитория на ветки — Git Flow. Создаются ветки Main, Develop и отвечающие за отдельный функционал (Feature). Ветки указывают на коммиты, которые к ним относятся. Идея состоит в том, что Main отвечает за рабочую версию, а реализация отдельных фич сливается только в Develop. Когда команда готова к релизу, она создает ветку, которая потом и будет слита с Main. Так в Main попадает гарантированно рабочий код.

Для создания ветки с фичей нужно ввести команду git branch [feature_name]. Команда git branch без указания имени выведет все локальные ветки, а флаг –r покажет ветки в удаленном репозитории.

* main
  develop

Когда разработчик хочет слить изменения в ветку, он переключается в нее c помощью команды git checkout [branch_name], а затем объединяет ветки командой git merge [branch_name]. Для удаления ненужной ветки используется git branch –d [branch_name].

Отмена изменений

Бывают ситуации, когда новый код ломает старый функционал и необходимо вернуться к рабочей версии. Откатить изменения можно несколькими способами, самые простые:

git checkout [hash_code] — откатывается к коммиту по указанному хешу;
git revert [hash_code] — отменяет указанный коммит и создает новый.

Обращение к коммитам происходит по их хешам. Хеш-коды длинные, но не обязательно писать их полностью — Git идентифицирует коммит по первым четырем символам. Если вы не программист, но сталкиваетесь с кодом, вы можете пользоваться графическими оболочками для git (например, Git Desktop или Git Kraken). GUI встроены в большинство IDE — например, реализация есть в Intellij IDEA. Чтобы не запоминать все флаги для команд, можно посмотреть документацию с помощью git help [command_name].

Автор: Биденко Дмитрий