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

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

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

Либо можете пройти бесплатный интерактивный курс на hexlet.io: Системы контроля версий (GIT).

Система контроля версий (англ. Version Control System, сокр. VCS) — это система, регистрирующая изменения в одном или нескольких файлах, чтобы в дальнейшем была возможность вернуться к старым версиям этих файлов. Существует множество таких инструментов, основанных на разных подходах. Мы рассмотрим самый распространенный и «правильный» — Git, разработанный основателем проекта Linux, Линусом Торвальдсом. Он по сей день используется для работы над ядром операционной системы.

You can disagree with me as much as you want, but during this talk, by definition, anybody who disagrees is stupid and ugly, so keep that in mind. When I am done speaking, you can go on with your lives. Right now, yes, I have strong opinions, and CVS users, if you actually like using CVScvs, you shouldn’t be here. You should be in some mental institution, somewhere else. // Tech Talk: Linus Torvalds on Git

Вы можете не соглашаться со мной сколько хотите, но в течение этого доклада все, кто не согласен со мной, по определению — тупые уроды. Помните об этом! Вы будете вольны делать и думать все что захотите, когда я закончу доклад. А сейчас я рассказываю свое единственно правильное мнение, так что пользователи CVS, если вы действительно его так любите, уйдите с глаз моих долой. Вам надо обратиться в психушку или куда-то еще. // Доклад Линуса Торвальдса на Google Tech Talk

VCS можно использовать локально, исключительно для собственных нужд, или размещать код на каком-нибудь публичном сервисе, чтобы делиться наработками с другими разработчиками. Самый популярный пример такого сервиса — github.com. Для начала работы вам необходимо установить Git. В Ubuntu это можно сделать одной строчкой:

sudo apt-get install git

Для других операционных систем вы найдете установочный файл на официальном сайте git-scm.com.

Далее необходимо представиться git, указав имя и адрес электронной почты:

git config --global user.name "John Doe"
git config --global user.email johndoe@example.com

Перейдите в папку с проектом и инициализируйте репозиторий (англ. repository, хранилище):

cd ~\project
git init

Если репозиторий уже существует и необходимо скопировать код на компьютер, выполните команду вида:

git clone git@github.com:user/repo.git

Если используется удаленный репозиторий, то указать его адрес нужно командой:

git remote add somelabel git@gitolite.com:repo

Перед совершением каких-либо действий сойдемся на том, что не все файлы необходимо помещать в хранилище. Промежуточные объектные файлы не нужны — они будут лишь занимать место и загромождать всю систему. Чтобы предотвратить включение этих файлов в историю, используется .gitignore-файл, который располагается в корне проекта. Ниже приведены сценарии его использования.

# Игнорирование ВСЕХ файлов и директорий, включая поддиректории
*
# Игнорирование по типу файла (во всех директориях)
# Например ./libmylib.a, /lib/libmylib.so
*.a
*.so
*.o
# Игнорирование файла во ВСЕХ директориях
c_tutorial.sublime-workspace
c_tutorial.sublime-project
# Если файл нужно проигнорировать только в # определенной директории,
# необходимо указать полный путь (относительный)
./config/device.h
# Можно проигнорировать все файлы в определенной директории
./config/*
# В случае если есть несколько папок с одинаковым названием
# в разных директориях, и их содержание нужно игнорировать,
# можно воспользоваться строкой
# следующего вида:
config/*
# Запретить добавлять (коммитить) файлы определенного типа в
# конкретной директории, при этом файлы такого типа в поддиректориях
# будут добавлены
/config/*.h
# Чтобы этого не происходило, нужно писать
/config/**/*.h
# Если есть исключение, то его можно записать
# следующим образом
/config/*
!/config/device.h
# в таком случае device.h будет включен
# Можно проигнорировать все файлы, начинающиеся
# с определенной буквы
./config/d?.h

После модификации, добавления или удаления файлов из папки project закрепить изменения можно серией команд:

# Посмотреть текущее состояние
git status
# Добавит все файлы во всех вложенных директориях
git add .
# можно добавить определенный файл:
git add path\to\a\file.c

Система сделает пометку о том, какие изменения необходимо запомнить, но не добавит их в древо. Для добавления изменений необходимо их «закоммитить» следующей командой:

git commit -m "commit comment"

Комментарий лучше делать осмысленным — это поможет в поиске необходимой версии проекта.

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

git push somelable master

Здесь master — название «ветки» (англ. branch). Можно создать и другие ветки, это особенно полезно, если над проектом работает не один человек. Существует несколько политик ветвления, самая очевидная выглядит примерно так:

  • в ветке master хранится стабильная версия проекта, которую можно запустить в любой момент;
  • ветка develop порождается от master, здесь лежит проект, куда добавляются новые функции, но не находящиеся в определенной версии (со временем сливается с master);
  • в ветки task-XXX добавляются новые функции, порождается от develop, сливаются с develop.

Новая ветка создается командой checkout:

git checkout -b task-001

Посмотреть, какие ветки доступны локально, можно командой:

git branch

Удаление ветки осуществляется командой:

git checkout -d task-001

Если ненужная ветка залита в центральный репозиторий, ее можно удалить, написав следующую команду:

git checkout -d :task-001

Для объединения нескольких веток, например, task-001 и develop, нужно произвести такие действия:

# Переключаемся на ветку develop
git checkout develop
# Обновляем до последней версии ветку develop
# (из центрального репозитория)
git pull
# Возвращаемся к task-001
git checkout task-001
# Синхронизируем task-001 с develop
git rebase develop
# Возвращаемся на develop
git checkout develop
# Объединяем ветку task-001 с develop
git merge task-001

Операция пройдет успешно, если не возникнет никаких конфликтов. В противном случае git укажет на конфликты и предложит их исправить.

Команда checkout имеет и другую функциональность. Допустим, вы изменили файл, но хотите вернуть его к прежнему состоянию (последнего коммита). Воспользуйтесь ключом -f:

git checkout -f filename.c

Чтобы объединить несколько коммитов (в примере 4) в один, можно прибегнуть к rebase -i:

git rebase -i HEAD~4

Перезаписать предыдущий коммит можно так:

git commit --amend

После этого последовательность коммитов «ломается» (если в ветке центрального репозитория есть коммит, который вы удалили из локального). Залить изменения можно будет только с ключом -f:

git push origin task-001 -f

Вот еще ряд полезных команд:

git log
git show
git diff

У каждого коммита есть идентификатор, это хэш SHA-1. Посмотреть информацию об определенном коммите можно так:

git show e8bba7d0c448adcba435cdacdb4f7aa69d185f9e

Конечно, это далеко не все команды и не всё, что вам стоит знать о системе контроля версий, но этого более чем достаточно для начала работы.


Изменено: