Управление исходным кодом

Управление исходным кодом (SCM) — это дисциплина отслеживания, записи и координации всех изменений, вносимых в исходный код проекта с течением времени. На этой странице объясняется, что такое SCM, почему каждая команда полагается на него, как вписывается Git, какой рабочий процесс он обеспечивает и какие практики помогают поддерживать историю проекта в чистоте.

Что такое управление исходным кодом?

Управление исходным кодом — это практика отслеживания изменений программного кода и управления ими. Оно почти всегда реализуется с помощью системы контроля версий (VCS) — инструмента, который фиксирует каждое изменение в репозитории, привязывает его к автору, проставляет временну́ю метку и позволяет перемещаться назад и вперёд по истории проекта.

Git — наиболее широко используемая VCS на сегодняшний день. Она распределённая: каждый разработчик хранит полную копию истории проекта локально, поэтому делать коммиты, создавать ветки и просматривать историю можно без подключения к сети. Существуют и другие системы (Subversion, Mercurial, Perforce), однако понятия, описанные на этой странице, применимы ко всем им.

SCM и VCS часто используются как взаимозаменяемые термины. Строго говоря, SCM — это более широкая практика (история, ветвление, политики совместной работы, ревью кода), а VCS, такая как Git, — инструмент её реализации.

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

Почему управление исходным кодом важно

VCS решает проблемы, которые становятся болезненными, как только к кодовой базе прикасается больше одного человека — или накапливается больше одного дня работы:

• Отслеживание изменений — каждое изменение записывается автоматически, привязывается к автору и документируется в сообщении коммита, создавая доступную для поиска историческую запись.
• Синхронизация — члены команды получают последнюю версию кода из общего репозитория, что гарантирует работу всех от одной и той же базовой линии.
• Резервное копирование и восстановление — поскольку каждый коммит является полным снимком состояния, любой файл можно восстановить до предыдущего состояния в любой момент.
• Отмена изменений — вы можете вернуться к любому предыдущему состоянию: от последнего коммита до версии, созданной давным-давно, не теряя промежуточных шагов.
• Ветвление и слияние — работа ведётся в изолированных ветках и сливается обратно после проверки и утверждения.
• Обнаружение конфликтов — когда два человека изменяют одни и те же строки, VCS не перезаписывает один вариант другим молча; она сигнализирует о конфликте слияния, чтобы человек мог его разрешить.

Без SCM команды вынуждены упаковывать папки в архивы, отправлять файлы по электронной почте и называть их вроде final_v2_REALLY_final.js — теряя историю и перезаписывая работу друг друга.

Базовый рабочий процесс SCM

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

# Create and enter a fresh project
mkdir scm-demo && cd scm-demo

# 1. Turn the folder into a repository
git init -q
git config user.email "[email protected]"
git config user.name "Dev"

# 2. Make a change
echo "console.log('hello');" > app.js

# 3. Stage the change, then record a snapshot (commit)
git add app.js
git commit -q -m "Add initial app"

# 4. Make a second change and commit it
echo "console.log('world');" >> app.js
git commit -q -am "Print world too"

# 5. Inspect the historical record
git log --oneline

В истории теперь хранятся два снимка состояния, новейший первым (короткие хеши слева генерируются для каждого коммита, поэтому у вас они будут другими):

6524bb9 Print world too
88e2f34 Add initial app

Каждая команда git add перемещает изменения в область подготовки (staging area), а каждая команда git commit замораживает подготовленное содержимое в постоянный именованный снимок состояния. Вывод git log — это историческая запись, которую предоставляет SCM: здесь две строки, по одной на коммит, каждая с коротким хешем и сообщением. В любой момент можно выполнить git status, чтобы увидеть, что изменено, добавлено в индекс или не отслеживается.

Ветвление и слияние

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

mkdir branch-demo && cd branch-demo
git init -q
git config user.email "[email protected]"
git config user.name "Dev"

echo "line 1" > notes.txt
git add notes.txt
git commit -q -m "Start notes"

# Remember the main branch name (main or master)
main=$(git branch --show-current)

# Create a branch, switch to it, add work there
git switch -c feature
echo "line 2 from feature" >> notes.txt
git commit -q -am "Add feature line"

# Go back to the main branch and merge the feature in
git switch -q "$main"
git merge -q feature

cat notes.txt

После слияния файл notes.txt содержит работу из обеих веток:

line 1
line 2 from feature

Ветка feature позволила новой линии работы развиваться, не затрагивая main, а git merge объединил её обратно. В совместном проекте вы также использовали бы git clone для клонирования репозитория и git pull перед началом работы, чтобы строить на основе последней версии кода.

Лучшие практики

• Делайте коммиты часто и небольшими порциями. Коммит — это снимок состояния; небольшие сфокусированные коммиты дают множество безопасных точек возврата и делают историю удобочитаемой. Связанные коммиты впоследствии можно объединить, чтобы лог оставался чистым.
• Всегда работайте с последней версией. Выполняйте pull или fetch общего кода перед началом работы, чтобы строить на актуальной базе и минимизировать конфликты слияния.
• Пишите описательные сообщения коммитов. Понятное сообщение, объясняющее что изменилось и почему, становится незаменимым по мере роста проекта, когда другие люди (включая вас в будущем) читают лог.
• Проверяйте изменения перед коммитом. Область подготовки позволяет собирать и проверять правки перед тем, как превратить их в снимок состояния — просматривайте diff, чтобы каждый коммит был осознанным.
• Используйте ветки для изоляции. Разрабатывайте каждую функциональность или исправление в отдельной ветке и объединяйте её только после проверки, сохраняя основную ветку стабильной.
• Договоритесь об общем рабочем процессе. Установите командные соглашения по ветвлению, ревью и слиянию. Распространённые схемы описаны в разделе рабочие процессы Git.

Практика