Как можно откатитьсяв текстовом документе? Ctrl+Z. Можно сохранять много рабочих копий одного файла, указывая в имени файла дату, какую-то метку проекта, вести отдельный файл с кратким описанием изменений в файле и содержать в этом файле всю необходимую информацию о списке рабочих файлов и сделанных в них изменениях.
Но это неудобно, проект растет, папка с проектом «пухнет».
А если количество одновременных проектов больше одного? По каждому нужно вести учет об изменениях?
Здесь приходит на помощь VCS.
WIKI: VCS (versioncontrolsystem) –ПОдляоблегчения работы с изменяющейся информацией. Система управления версиями позволяет хранить несколько версий одного и того же документа, при необходимости возвращаться к более ранним версиям, определять, кто и когда сделал то или иное изменение, и многое другое.
То есть нужно иметь возможно откатиться к более ранним изменениям (snapshots).
Все VCS – по сути хранилище (repository), которое хранит ВСЕ версии файлов, с которыми мы работаем. Понятие «версия» - определяется нами, пользователями, теми, кто изменяет документ. К примеру, сделали много мелких правок в документе, «нажали Ctrl-S» – вот вам и получилась «версия». Снова внесли правки – «нажали Ctrl-S» – ЧТО БУДЕТ? Файл перезапишется. Но в случае с VCS, второе «сохранение» не затрется- это будет новая отдельная версия. Очень похоже на игру с сохранением. Поиграли, сохранились, еще поиграли – сохранились. В любой момент мы можем выбрать удобный для нас «сейв» и играть начиная с него, затем снова сохранится. И уже новое сохранение будет считаться новой веткой (branch).
Итак, VCS системы. Данные системы бывают централизованными и распределенными.
Традиционные системы управления версиями используют централизованную модель, когда имеется единое хранилище документов, управляемое специальным сервером, который и выполняет бо́льшую часть функций по управлению версиями.
Пользователь, работающий с документами, должен сначала получить (сделать pull) нужную ему версию (то есть commit) документа из хранилища, чаще всего это будет самый последний commit, то есть последняя версия; т.о. создаётся локальная копия документа, так называемая «рабочая копия». Может быть получена последняя версия или любая из предыдущих, которая может быть выбрана по номеру версии или дате создания, иногда и по другим признакам. После того, как в документ внесены нужные изменения, новая версия помещается в хранилище. В отличие от простого сохранения файла, предыдущая версия не стирается, а тоже остаётся в хранилище и может быть оттуда получена в любое время. Все правки, которые мы хотим обозначить новой версией, то есть сделать commit, «улетают» на сервер с какой-то задержкой.
Распределенные системы – при получении с сервера некоторой версии, вместо версии мы получаем весь репозиторий проекта.
Поэтому в случае, когда "умирает" сервер, через который шла работа, любой клиентский репозиторий может быть скопирован обратно на сервер, чтобы восстановить базу данных. Каждый раз, когда клиент забирает свежую версию файлов, он создаёт себе полную копию всех данных. Из этого вытекает важное отличие – в распределенных VCS вся работа над проектом ведется с локальным репозиторием. То есть все commit ’ы хранятся локально, никуда не улетая, ожидают своего часа. Или если связь с сервером утеряна, всегда можно продолжать работу с локальной копией репозитория.
Примеры VCS: Git, SVN, Perforce и другие // даже Dropbox можно считать системой контроля версий, по сути он и есть VCS.
Мы познакомимся с vcsgit. Она является распределенной системой управления версиями.
Модуль 2 (1 пара)
Git
- Архитектура
- Установка. Конфигурация.
- Проверка состояния. Фиксация изменений. Индексация
- Создание репозитория. Добавление пользователя
- Добавление файлов. Игнорирование файлов
- Журнал изменений
- Понятие ветки. Создание ветки
- Псевдонимы.
Архитектура
Каким образом можно хранить файлы, подверженные контролю версий?
Можно хранить их «дельты», их еще называют «патчи », то есть лишь правкиотносительно базовой версии:
Так осуществляется контроль в некоторых системах контроля версий.
В Gitделается слепок ВСЕГО проекта, а в commit фиксируется, что НЕ измененные файлы должны иметь ссылку на предыдущую версию (ведь они же не менялись, зачем хранить такую же копию):
Как и упоминалось, все (почти все) операции локальные. Все изменения GIT ведет в локальной копии репозитория (сервер не нагружается). Историю проекта (кто вносил какие изменения) можно увидеть, не обращаясь к серверу. Если вы клонировали себе какой-то репозиторий, помимо всех файлов проекта вы к себе скопировали и всю историю, которая велась над этим проектом. Сразу же вы можете увидеть, когда, что и кем менялось, причем узнавать вы будете это не у сервера VCS, а прямо у себя, у своей копии клонированного репозитория.
Установка. Конфигурация
Установка
НаLinux:
$ yum install git-core – для Fedora (Centos, RHEL)
$ apt-get install git– дляDebian (Ubuntu)
НаWindows:
https://git-for-windows.github.io/
Под Mac тоже есть – гуглим.
Конфигурация.
Теперь нужно допилить gitпод нас. Совсем немного. ОткрываемGITBASHи задаем глобально наши имя пользователя и e-mail,то есть повторно их вводить не придется, даже после обновления версии git. Эти данные будут включаться по умолчанию во все коммиты.
ВНИМАНИЕ. На машинах в академии этот параметр уже задан. Его не изменить, поэтому переходим к следующему пункту.
$ gitconfig --globaluser.name “yourname”
$ gitconfig --globluser.email “mymail@domain.net”
Если мы хотим другие указать, к примеру, для другого проекта, то следует перейти в папку с репозиторем и там уже указать другие свои данные, но без ключа –global:
$ cdanotherProject
$ gitconfiguser.name “yourname”
$ gitconfiguser.mailmymail@domain.net
Эта заоверрайдит предыдущие данные, то естьспецифичные данные доминируют над глобальными.
Посмотрим на конфиг:
$ gitconfig --listили
$ gitconfig -l
Если смотреть конфиг, к примеру, из домашнего каталога ~, то увидим глобальные настройки – глобально заданные user.name и user.email. Если перейдем в каталог с созданным и проинициализрованнымрепозиторием, то увидим и глобальные и специфичные user.name, user.email. Но «съедаться» в коммиты будут последние, то есть специфичные.
Хелпы.
Если что-то забыли/не знаетео команде, то есть хелпы:
$ githelp
$ git<комманда> -h
$ git<комманда> --help
Или открыть этот же встроенный help в более читабельном виде на странице:
$ git<команда>help (из коробки работает только в винде)
При этом откроется страница в браузерес искомым хелпом. Useit!!