Система контроля версий

Система контроля версий (СКВ) — это система, регистрирующая изменения в одном или нескольких файлах с тем, чтобы в дальнейшем была возможность вернуться к определённым старым версиям этих файлов (типичный пример: выложили версию в проду, начали работу над новыми фичами и вдруг обнаружились ошибки. Нужно не потеряв новых наработок вернуться к рабочей версии, исправить ошибки).

Можно просто копировать проект в другой каталог, такой подход часто применяется из-за своей простоты, но имеет множество недостатков:

  • избыточность (дублируется весь код, а не только изменения)
  • нет механизмов для распределения работы между несколькими разработчиками
  • нет данных о том что именно изменилось (обычно пишут history файл с общей информацией об изменениях)

Распределённые системы контроля версий

В таких системах как Git, Mercurial, Bazaar или Darcs клиенты не просто выгружают последние версии файлов, а полностью копируют весь репозиторий (репозиторий, в простонародье репа, это место, где хранятся и поддерживаются какие-либо данные). При этом можно выделить центральный репозиторий (условно), в который будут отправляться изменения из локальных и, с ним же эти локальные репозитории будут синхронизироваться. Поэтому в случае, когда "умирает" сервер, через который шла работа, любой клиентский репозиторий может быть скопирован обратно на сервер, чтобы восстановить базу данных. Каждый раз, когда клиент забирает свежую версию файлов, он создаёт себе полную копию всех данных.
Кроме того, в большей части этих систем можно работать с несколькими удалёнными репозиториями.

На сегодняшний день стандартом де-факто стала распределенная система контроля версий - GIT, но в старых больших проектах вполне могут встретиться устаревшие СКВ (например, популярная в свое время Subversion).

Основы GIT

Стандартный рабочий процесс с использованием Git'а выглядит примерно так:

  • Вы вносите изменения в файлы в своём рабочем каталоге.
  • Подготавливаете файлы, добавляя их слепки в область подготовленных файлов.
  • Делаете коммит, который берёт подготовленные файлы и помещает их в каталог Git'а на постоянное хранение.

Основные понятия git систем:

  • Репозиторий (repository) - обособленное хранилище кода внутри которого будут отслеживаться изменения файлов
  • Ветвь (branch) - отдельная цепочка (ветка) отслеживаемых изменений
  • Мастер branch (master) - главная ветка в репозитории
  • Коммит (commit) - зафиксированная точка изменений
  • Удаленный сервер (remote server) - сервер на котором хранится репозиторий
  • Слияние (Merge) - процесс слияния двух ветвей
  • tag - ссылка на определенный коммит

Основные команды GIT

  • git add — добавить файл в стейджинг-зону для работы над изменениями.
  • git commit - зафиксировать изменения и сделать коммит
  • git status – посмотреть статус коммитов (их количество, внесенные изменения).
  • git clone ссылка на удаленный репозиторий – скопировать себе на устройство все данные из GitHub или BitBucket.
  • git pull - забрать изменения с удалённого сервера
  • git push - отправить локальные изменения на удалённый сервер
  • git push -u origin название ветки – отправить набор коммитов в удаленный реп.
  • git branch - показать текущую ветку/список веток
  • git branch название ветки – создать новую ветвь.
  • git checkout название ветки – переключиться на другую ветвь.
  • git merge название ветки – объединить выбранную ветвь с той, к которой подключен пользователь. То есть сначала надо сделать checkout, а потом merge.
  • git stash - сохранить локальные изменения не создавая коммит и откатиться до состояния удалённого сервера
  • git remote add origin ссылка на удаленный репозиторий – подключиться к удаленной платформе. Ссылку на репо можно взять в GitHub или в GitLab в соответствующем разделе. 

Первоначальная настройка Git

В состав Git входит утилита git config, которая позволяет просматривать и устанавливать параметры, контролирующие все аспекты работы Git и его внешний вид.

Первое, что вам следует сделать после установки Git, — указать ваше имя и адрес электронной почты. Это важно, потому что каждый коммит в Git содержит эту информацию, и она включена в коммиты, передаваемые вами, и не может быть далее изменена (команды выполняются из командной строки):

git config --global user.name "Имя Фамилия"
git config --global user.email mail@example.com

Создание Git-репозитория

Для создания Git-репозитория существуют два основных подхода:

  • импорт в Git уже существующего проекта или каталога
  • клонирование уже существующего репозитория с сервера

Создание репозитория в существующем каталоге:

git init

На этом этапе ваш проект ещё не находится под версионным контролем. добавить под версионный контроль существующие файлы (в отличие от пустого каталога), вам стоит проиндексировать эти файлы и осуществить первую фиксацию изменений. Осуществить это вы можете с помощью нескольких команд git add указывающих индексируемые файлы, а затем git commit:

git add .
git commit -m "Начальное состояние"

Клонирование существующего репозитория

Клонирование репозитория в каталог с названием репозитория

git clone https://github.com/remote/repo

Клонирование репозитория в каталог с другим названием

git clone https://github.com/remote/repo myFolder

Клонирование репозитория в текущую папку

git clone https://github.com/remote/repo .

Добавление удалённых репозиториев

Чтобы добавить новый удалённый Git-репозиторий под алиасом, к которому будет проще обращаться, выполните git remote add [алиас] [url]:

git remote add pb https://github.com/remote/repo
Как узнать адрес origin репозитория в git

origin адрес репозитория

git remote -v

Эта команда покажет все имена репозиториев, где вы можете делать fetch/push.

Пример:

$ git remote -v

origin  ssh://git@stash.domain.com:7999/bng/backend.git (fetch)
origin  ssh://git@stash.domain.com:7999/bng/backend.git (push)
upstream    git@bitbucket.org:repo/backend.git (fetch)
upstream    git@bitbucket.org:repo/backend.git (push)
Читать по теме
Интересные статьи