Embed Size (px)
Citation preview
Системы контроля версий исходного кода
VCS & DVCSGit и GitHub
Научно исследовательская лаборатория
Шкурко А.Н.
Предпосылки
• Частые изменения
• Команды разработки
• Версионность ПО
• Вероятность неправильных решений
• Необходимость «работы над ошибками»
Что обычно происходит без VCS?
Что обычно происходит без VCS?
Для чего это нужно?
• Архивация и восстановление
• Синхронизация работы команды
• Поиск «виновного»
• Хранение истории разработки
• Отмена изменений
• Альтернативные/экспериментальные реализации
Решение
• Хранилище файлов проекта с историей изменений (репозиторий)
• Отслеживание автора изменений• Возможность просмотра истории изменений и отката к
нужной версии• Операции:
• Получить проект полностью из системы (checkout)• Добавить свои изменения в систему (commit)• Обновить текущую версию изменениями из проекта (update)• Скопировать текущий проект в рамках VCS с созданием новой
ветки истории (branch)• Перенести изменения из одной ветки истории в другую
(merge)
Клиент
VCS
Ветвление
Слияние
Конфликты
История развития
Централизованные системы
Централизованные системы
• Преимущества:• все знают, кто и чем занимается в проекте;• у администраторов есть чёткий контроль над тем, кто и что может делать,
• Недостатки:• централизованный сервер является уязвимым местом всей системы:• если сервер не работает, то разработчики не могут взаимодействовать, и никто
не может сохранить новой версии своей работы;• если отсутствует подключение сети у разработчика, в это время он также не
может взаимодействовать с сервером;• если же повреждается диск с центральной базой данных и нет резервной копии,
вы теряете абсолютно всё — всю историю проекта, разве что за исключением нескольких рабочих версий, сохранившихся на рабочих машинах пользователей;
• скорость работы зависит от подключения к серверу.
Децентрализованные системы
Децентрализованные системы
• Преимущества:• Так как каждый раз, когда клиент забирает свежую версию файлов, он создаёт
себе полную копию всех данных, то в случае сбоев на сервере, через который шла работа, любой клиентский репозиторий может быть скопирован обратно на сервер, чтобы восстановить базу данных.
• Возможность работать с несколькими удалёнными репозиториями, таким образом, можно одновременно работать по-разному с разными группами людей в рамках одного проекта. Так, водном проекте можно одновременно вести несколько типов рабочих процессов, что невозможно в централизованных системах.
• Недостатки:• Сложнее в освоении;• Иногда требуют дополнительных договоренностей.
Git
• распределённая система управления версиями файлов
• создан Линусом Торвальдсом для управления разработкой ядра Linux, первая версия выпущена 7 апреля 2005
• программа является свободной и выпущена под лицензией GNU GPL версии 2
• Git и Github – не одно и то же. Это проекты разных команд.
Локальные операции
Статусы файлов
Работа с Git
• git init - создание репозитория
• git add <filename> - добавить файл в индекс
• git commit -m "Comment" - отправить файл в репозиторий(локальный)
git init
Создание файла
echo "file 1" > file1
git st
# On branch master
#
# Initial commit
#
# Untracked files:
# (use "git add <file>..." to include in what will be
committed)
#
# file1
nothing added to commit but untracked files present (use "git
add" to track)
Добавление
git add file1
$ git st
# On branch master
#
# Initial commit
#
# Changes to be committed:
# (use "git rm --cached <file>..." to unstage)
#
# new file: file1
#
Изменение
$ nano file1
$ git st
# On branch master
# Initial commit
# Changes to be committed:
# (use "git rm --cached <file>..." to unstage)
# new file: file1
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in
working directory)
#
# modified: file1
#
Коммит
$ git add file1
$ git ci -m "Add file"
[master (root-commit) 4433db8] Add file
1 file changed, 1 insertion(+)
create mode 100644 file1
$ git st
# On branch master
nothing to commit (working directory clean)
git ci -a -m "Commit all changed tracked files"
Хранение коммита
Последовательность коммитов
Ветка master
Клонирование репозитория
git clone https://github.com/neyronius/gittest.git
Cloning into 'gittest'...
remote: Counting objects: 11, done.
remote: Compressing objects: 100% (5/5), done.
remote: Total 11 (delta 1), reused 10 (delta 0)
Unpacking objects: 100% (11/11), done.
git remote -v
origin https://github.com/neyronius/gittest.git (fetch)
origin https://github.com/neyronius/gittest.git (push)
Работа с удаленным репозиторием
$ nano file1
$ git ci -a -m "Commit"
[master c013d8d] Commit
1 file changed, 1 insertion(+), 1 deletion(-)
$ git push
Counting objects: 5, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 262 bytes, done.
Total 3 (delta 1), reused 0 (delta 0)
To https://github.com/neyronius/gittest.git
9baa1e7..c013d8d master -> master
Создание веток
$ git branch testing
$ git co testing
Switched to branch 'testing'
$ git branch
* testing
master
Хранение веток
HEAD
Слияние веток
$ nano file1
$ git ci -a -m "Branch change"
[issue d9685db] Branch change
1 file changed, 1 insertion(+), 1 deletion(-)
$ git co master
Switched to branch 'master'
$ git merge issue
Updating c013d8d..d9685db
Fast-forward
file1 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Отправка ветки на сервер
git push origin issue
Counting objects: 5, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 273 bytes, done.
Total 3 (delta 1), reused 0 (delta 0)
To https://github.com/neyronius/gittest.git
* [new branch] issue -> issue
Организация разработки
• Инструментарий VCS дает дополнительные возможности по организации процесса разработки
• Чем легче основные операции в системе, тем более сложный процесс может быть реализован
• Цель создания процессов разработки – уменьшение количества ошибок и потенциальных проблем
Github
Github
Github
Github
Github
Спасибо за внимание
Ваши вопросы?
