Настройка работы системы контроля версий типов импортируемых файлов
Часто разработчики трудятся в команде над одним проектом, а значит, сразу несколько человек могут изменять один файл одновременно. Чтобы избежать путаницы, в таких случаях используют систему контроля версий, которая позволяет хранить историю изменений проекта и при необходимости помогает вернуться к предыдущей версии.
Окружение Git
Git — удобная система. Плюсом является то, что вокруг него создано множество сервисов, которые позволяют сделать работу с ним удобнее. Расскажем о тех, что будут вам полезны в начале работы.
Локальные системы контроля версий
Локальные СКВ обычно хранят на компьютере список изменений, внесенных в файлы. Основываясь на этих данных, система контроля версий воссоздает нужную версию файла (актуальную на определенный момент времени).
Локальные системы контроля версий
Достоинства:
— возможность восстановления данных из определенной версии (точно определяется по времени записи);
— высокая скорость выполнения восстановления (база данных четко структурирована, поэтому сложностей при поиске не возникает, сетевая задержка отсутствует, поскольку данные хранятся непосредственно на рабочем компьютере).
Недостатки:
— возможность потери данных вследствие возникновения физических поломок оборудования;
— отсутствие возможности совместной разработки.
Децентрализованные системы контроля версий
В децентрализованных системах контроля версий при каждом копировании удалённого репозитория (расположенного на сервере) происходит полное копирование данных в локальный репозиторий (установленный на рабочем компьютере). Каждая копия содержит все данные, хранящиеся в удалённом репозитории. В случае, возникновения технической неисправности на стороне сервера, удаленный репозиторий можно перезаписать с любой сохраненной копии.
Децентрализованные системы контроля версий
Достоинства:
— возможность восстановления данных из определенной версии (точно определяется по времени записи);
— возможность ведения командной разработки проекта;
— при сбое работы сервера система сохраняет данные в локальном репозитории, что позволяет эффективно вести процесс разработки, а после восстановления работы сервера, передать все изменения в удаленный репозиторий;
— при физической поломке сервера данные можно легко перенести в новый удалённый репозиторий с любого локального репозитория;
— высокая скорость работы (в ходе работы данные записываются и получаются из локального репозитория, поэтому сетевые задержки отсутствуют).
Дерево проекта
Дерево файлов в системе контроля версий
В репозитории содержится «дерево» проекта, то есть все сохраненные версии файлов.
Дерево может быть прямым (в этом случае каждое последующее сохранение файлов производилось после предыдущего без возвращения к более ранним версиям) и разветвленным.
К появлению «веток» приводит работа с более ранними версиями и сохранение внесённых изменений.
На различных ветках дерева содержатся сохранения, основой которых был один исходный файл. В ходе работы в файлы на разных ветках были внесены разные изменения. В системе управления версиями можно работать со всеми ветками дерева проекта, пошагово, изменяя и дополняя содержащиеся в них данные. После проведения ряда изменений 2 ветки могут «срастись», в новой версии файла будут учтены все внесенные изменения.
Как работает git
Взаимодействие с удаленным репозиторием происходит при наличии интернета и, по сути, представляет собой синхронизацию двух репозиториев.
Команда push копирует новые данные, содержащиеся в локальном репозитории, в удалённый репозиторий, а команда pull передает данные из удаленного репозитория в локальный.
Каждая версия документа, внесенные обновления и т.д записываются в локальный репозиторий.
3.3. Распределенная система контроля версий
Распределенная система контроля версий решает все описанные выше проблемы. К этой группе систем относится Git, Mercurial, Bazaar и некоторые другие. На схеме распределенные системы контроля версий выглядят так:
Особенность этой архитектуры в том, что клиенты не хранят у себя отдельные файлы, они хранят полную копию всех версий проекта. Поэтому, если что-то случится с сервером, работа не остановится, а продолжится, как ни в чем не бывало. Работники будут сохранять версии у себя на компьютере, а как только сервер восстановится, они загрузят все эти версии на него.
Кроме того, почему сервер обязательно должен быть один? Правильный ответ: серверов может быть сколько угодно! Это открывает безграничные возможности для коллаборации разработчиков. Ведь это значит, что если вы делаете какое-нибудь открытое программное обеспечение и используете систему контроля версий, любой человек сможет скопировать данные с вашего сервера на свой, улучшить это ПО, не боясь ошибок (ведь можно откатиться к предыдущей версии), а затем (с вашего согласия) записать улучшенную версию на ваш сервер. И так с миллионами людей по всему миру.
Подытожим
Распределенные VCS - лидер по популярности на сегодняшний день. Примеры таких систем - это Git, Mercurial и Bazaar.
Преимущества распределенных VCS:
1. Работа компании теперь не зависит от работы сервера. Если сервер отключится, то каждый сотрудник продолжит работу с локальной копией репозитория, а после загрузит ее на сервер.
2. Можно работать с несколькими удаленными репозиториями, делиться кодом с другими людьми и коллаборировать целыми компаниями.
ОБЩИЙ ИТОГ
Для закрепления повторим все, что было сказано ранее. Итак, VCS открывает перед вами следующие возможности:
1. Сохранять все изменения в файлах в хронологическом порядке, при этом не путаясь в именах миллионов копий одного и того же файла.
2. Избегать неприятных ошибок в коде, вызванных непредвиденным поведением новых функций.
3. Отслеживать, над какими файлами вы работаете (и работаете ли вообще). Вам это вряд ли пригодится, а вот вашему начальству – очень.
4. Работать параллельно над одним и тем же проектом вместе с командой, не боясь конфликтов, например, одновременного изменения одного и того же файла.
5. Делиться своим кодом. А разработчики со всего мира могут улучшать его и записывать изменения на ваш сервер.
Git - это самая популярная на сегодня система контроля версий. Это развитый проект с открытым кодом, активно поддерживаемый и совершенствуемый. Как я уже говорил выше, Git устроен по принципу распределенной архитектуры, но поддерживает и локальную работу (в таком случае ваш компьютер будет единственным сервером, где хранятся все версии проекта).
Git был разработан командой Линуса Торвальдса в 2005 году, как open-source аналог уже существующим системам. Но разработка Git не была спонтанным решением. Дело в том, что с самого первого релиза в 1991 году разработка ядра Linux выполнялась по старинке: старая версия архивировалась, а новые патчи от разработчиков становились новой версией.
Но с ростом популярности рос и объем данных, поэтому в 2002 году было принято решение перевести ядро Linux на распределенную систему управления версиями BitKeeper от BitMover Inc . Однако между компаниями произошел разлад и BitMover Inc . отозвали лицензию на бесплатное использование своего ПО.
Этот инцидент и подстегнул Линуса Торвальдса с командой разработчиков создать свою открытую распределенную систему контроля версий. Ребята хотели разработать надежное решение, обладающее высокой скоростью работы и упрощающее командную разработку.
Версионирование
Чтобы лучше понять проблему версионирования, рассмотрим пример дизайнера, который закончил работать над проектом и отправил финальную версию заказчику. У дизайнера есть папка, в которой хранится финальная версия проекта:
Всё хорошо, дизайнер закончил работу, но заказчик прислал в ответ правки. Чтобы была возможность вернуться к старой версии проекта, дизайнер создал новый файл barbershop_index_final_2.psd , внёс изменения и отправил заказчику:
Этим всё не ограничилось, в итоге структура проекта разрослась и стала выглядеть так:
Вероятно, многие уже сталкивались с подобным, например, при написании курсовых работ во время учёбы. В профессиональной разработке создавать новые файлы для версионирования — плохая практика. Обычно у разработчиков в папке проекта хранится множество файлов. Также над одним проектом может работать несколько человек. Если каждый разработчик для версионирования будет создавать новый файл, немного изменяя название предыдущей версии, то в скором времени в проекте начнётся хаос и никто не будет понимать, какие файлы нужно открывать.
Для решения проблемы с сохранением новой версии файлов удобно использовать системы контроля версий. Одна из самых популярных — Git. Работу Git можно сравнить с процессом сохранения и загрузки в компьютерных играх:
- если впереди ждёт тяжёлое сражение, то перед этим лучше заранее сохраниться;
- чтобы это сделать, нужно выполнить специальную команду;
- после чего сохранение попадает в специальную папку и содержит состояние игры;
- теперь при необходимости всегда есть возможность вернуться к предыдущей версии игры.
Папка, содержащая данные игры, могла бы выглядеть так:
Файлы, необходимые для работы приложения, хранятся в рабочей области. В папке saves хранится история всех сохранений игры. Git сохраняет код вашего проекта по такому же принципу: сохранения попадают в специальную скрытую папку, а рабочей областью является содержимое корневой папки.
Git-хостинг
Для комфортной работы с git нужно зарегистрироваться на любом git-хостинге. Их довольно много: Github, Sourceforge, Google Code, GitLab, Codebase и т.д.
Самый популярный на данный момент git-хостинг – это Github.
Популярность его обоснована простым интуитивно понятным интерфейсом, поддержкой проектов с открытым кодом (возможностью бесплатно размещать такие проекты на хостинге) и обширным функционалом.
Современные системы контроля версий
Существует много систем контроля версий (Git, Darcs, Mercurial, Bazaar, Monotone и т.д), сходных по принципу работы и конечным задачам. Отличаются они друг от друга архитектурой, использованными решениями и удобством работы.
Самая популярная на сегодняшний день система контроля версий – Git.
GitHub
GitHub — это сайт, сервис и то самое облако, в котором можно хранить удалённые репозитории и через которое коллеги могут синхронизировать свои версии проектов. Как зарегистрироваться, мы рассказали в этой статье.
Облегчить работу с Git и GitHub могут специальные программы. Такие программы в удобной форме показывают изменения в коде, список коммитов и обладают другими удобными возможностями. Обычно в подобных программах есть возможность выполнять стандартные Git команды: pull , push , commit и прочие — просто нажав на кнопку.
Пройдите бесплатные курсы по фронтенду и узнайте, как верстать сразу хорошо.
Так как наша команда программистов ведет разработку сразу несколько проектов, довольно быстро возникла необходимость в системе контроля версий.
Естественно, поиски были начаты с изучения Хабра — и привели к неожиданному результату. Несмотря на то, что системы контроля версий появились ещё в 1986 году, большинство туториалов по работе с современными системами контроля версий оказались неполными и сильно завязанными на работу с командной строкой.
Мы ничего не имеем против командной строки в целом, но в нашей небольшой команде разработчиков (4 человека) фанатов работы с командной строкой нет :).
Почему мы считаем, что работа с командной строкой неэффективна?
- Трата времени на ввод данных. Набивать команды намного дольше, чем кликать мышкой.
- Трата времени на обучение. Изучение нового синтаксиса в эпоху понятных интерфейсов однозначно дольше, чем обучение графическому интерфейсу.
- Вероятность ошибки. Ошибиться при вводе данных через командную строку легче (человеческий фактор никто не отменял).
- Нарушение принципов автоматизации. Возможно, это самый главный пункт. Компьютер создан для ускорения работы и замене человека при выполнении рутинных операций. В случае с командной строкой мы всегда работаем вручную, по сути, приходится каждый раз писать один и тот же программный код (пусть и примитивный).
- Будет пошаговой инструкций (по ней же будут работать наши программисты).
- Будет работать от начала и до конца (то есть по ней вы получите небольшой, но законченный результат — работающую распределенную систему контроля версий).
- Будет работать с использованием только графических интерфейсов (причины см. выше).
Вступление
Вопреки ожиданиям матерых сисадминов и прочих любителей и фанатов работы с командной строкой, в данной статье не будет никаких команд, выполняемых с помощью командной строки. Вся статья написана языком понятным даже тем, кто только недавно начал программировать, но уже задумался о внедрении VCS (системы контроля версий). Каждый шаг настройки VCS разжеван до мелочей с приведением принскринов и дополнительных пояснений.
Если вы не любитель мануалов «Для чайников», то можете не читать данную статью и пойти своим путем в решении задачи подъема VCS.
Используемые программы и сервисы
Для развертывания VCS (системы контроля версий) мы будем использовать следующие программы и сервисы:
- Mercurial — кроссплатформенная распределенная система управления версиями, разработанная для эффективной работы с очень большими репозиториями кода.
- TortoiseHg — графический фронтенд для системы контроля версий Mercurial.
- Bitbucket — веб-сервис для хостинга проектов и их совместной разработки, основанный на системе контроля версий Mercurial и Git.
Развертывание система контроля версий – пошаговая инструкция
Данный клиент необходимо будет устанавливать на всех компьютерах, с которых будет вестись совместная разработка проектов.
В данной инструкции все шаги настройки и работы с системой контроля версий будут производиться с использованием TortoiseHg версии: 2.10.1 for Windows 64-bit with Mercurial 2.8.1.
Регистрироваться в сервисе Bitbucket потребуется также всем участникам вашей команды разработчиков. К великому счастью стартапов в данном сервисе есть бесплатный аккаунт, который позволяет создавать приватные репозитории с 5-ю пользователями. Также есть возможность увеличения максимального числа членов команды, участвующей в разработке на бесплатном тарифе до 8 человек.
3. Зайдя в ваш аккаунт в сервисе Bitbucket, вы можете сразу изменить язык интерфейса вашего аккаунта на русский.
Для этого в верхнем правом углу главного меню из выпадающего списка выберите раздел «Manage account» и на открывшейся странице выберите из выпадающего списка «Language» нужный вам язык интерфейса
5. На странице создания нового репозитория укажите следующие настройки:
— Описание – Укажите краткое описание вашего репозитория (поле не обязательное)
— Уровень доступа – Поставьте галочку, если вы хотите, чтобы доступ к вашему репозиторию имели только члены вашей команды разработчиков (приватный репозиторий).
— Создание форков – Поставьте «Разрешить только приватные форки»
— Тип репозитория – Выберите «Mercurial»
— Управление проектом – Поставьте галочки «Трекер задач» и «Вики»
— Язык – Выберите язык разработки, на котором написан ваш проект. В моем случае это PHP.
По завершению указания всех настроек страница будет выгладить приблизительно так:
Еще раз проверьте введенные данные и если все введено корректно, жмем кнопку «Создать репозиторий».
6. После создания нового репозитория вы попадете на страницу «Начало работы»:
Где, нажав на ссылку «Я начинаю с полного нуля», сможете получить ссылку для подключения к вашему репозиторию с помощью TortoiseHg.
7. У себя на компьютере создаете пустую папку, в которой будут в дальнейшем храниться файлы вашего проекта, подключенные к системе контроля версий Mercurial.
Важно! Папка должна быть пустой. Мне, например, для подключения папки с уже существующим проектом (кучей программного кода) пришлось временно перенести все файлы в другой каталог (сделать резервную копию — backup). Позже мы вернем все файлы на место, а пока нужно полностью очистить папку для подключения.
Далее нажимаем на пустой папке, предназначенной для хранения файлов проекта, подключенных к системе контроля версий Mercurial, правой кнопкой мыши и из выпадающего меню выбираем пункт «TortoiseHg->Clone…»
8. В открывшемся окне вам необходимо указать в поле «Источник» ссылку для подключения к созданному вами репозиторию из п. 6
И нажать кнопку «Клонировать».
9. Система запросит у вас пароль от вашего аккаунта в сервисе Bitbucket, укажите его.
10. Если все было сделано без отклонений от данной инструкции, то в папке появится новый каталог «.hg» со служебными файлами созданного репозитория.
11. Теперь можно смело возвращать файлы (программный код) вашего проекта в папку, предназначенную для хранения файлов проекта, подключенных к системе контроля версий Mercurial
Важно! Служебный каталог «.hg» не трогайте. Он нужен для работы VCS.
12. Снова нажимаем правой кнопкой мыши на нашей папке проекта и из выпадающего меню выбираем пункт «Hg Commit…»
13. Вы увидите диалоговое окно, предназначенное для фиксации всех сделанных изменений, произведенных над вашим проектом (в данном случае мы добавили в изначально пустую папку проекта наши программные коды).
Вам необходимо выделить все измененные (добавленные) файлы, указать комментарий (например, Версия 1.00) к изменению и нажать кнопку «Фиксировать».
Система попросит подтвердить добавление, жмите «Добавить».
14. Если все было сделано правильно, то система зафиксирует произведенные изменения, и вы увидите приблизительно такое окно:
Собственно, в дальнейшем, когда будете вести разработку, после завершения небольшого куска кода, вы будете выполнять действие из п. 12 (нажимать «Hg Commit…») для фиксации проделанного изменения в системе контроля версия. Это даст вам возможность в любой момент времени откатить систему до предыдущей фиксации.
Учитывая вышесказанное, на практике следует писать более развернутый, чем «Версия 1.00», комментарий к каждой из фиксаций.
15. Далее нажимаем правой кнопкой мыши на папке проекта и из выпадающего меню выбираем пункт «Hg Workbench…»
Для этого в панели управления выберите кнопку «Протолкнуть входящие изменения в».
После этого вам будут показаны диалоговые окна с просьбой подтвердить «проталкивание» и просьбой указать пароль от вашего аккаунта в Bitbucket. Соглашайтесь и указывайте пароль.
Система начнет копирование файлов в ваш репозиторий на сервере Bitbucket. Не спешите и дождитесь завершения процесса.
17. Теперь копия файлов вашего проекта храниться в вашем репозитории на серверах Bitbucket. В вашем аккаунте Bitbucket вы можете видеть всю историю работы с вашим проектом.
Промежуточные итоги подключения системы контроля версий (VCS)
На данный момент мы создали репозиторий и поместили в него все файли нашего проекта. То есть теперь вы можете подключиться к вашему репозиторию с любого компьютера и получить стабильную версию файлов хранящихся в нем.
Процесс подключения вашего второго компьютера заключается в копировании файлов из репозитория на второй компьютер. Вам нужно пройти шаги 1 – Установка TortoiseHg и 7 – Импорт файлов репозитория, для копирования файлов на второй, третий и следующие ваши рабочие компьютеры.
Подключение сотрудников к вашему репозиторию.
Основная цель подключения системы контроля версий (VCS) к своему проекту — это организация совместной работы. Т.е. пока вы разрабатываете систему один, вы в большинстве случаев можете обойтись без VCS, но если разработчиков несколько, то вероятность регулярной потери (затирания) программных кодов и конфликтов версий системы очень высока.
Поэтому давайте сейчас подключим к нашему проекту еще одного программиста (пригласим участника) и настроим ему рабочее место.
Подключение сотрудника к нашему репозиторию
Как зарегистрироваться на сервисе и установить TortoiseHg, я рассказывал чуть ранее в данной инструкции. Поэтому данный процесс не должен вызвать у вас и ваших коллег никаких трудностей.
19. Зайдите в ваш аккаунт на сервисе Bitbucket:
20. Система выведет вам диалоговое окно с просьбой указать электронный адрес пользователя, которому вы хотите дать доступ к репозиторию. Помимо этого, вам понадобится указать права доступа («чтение» или «запись»). Т.к. в данной инструкции мы показываем, как подключить к репозиторию еще одного разработчика, то укажите «запись».
После того, как ввели email сотрудника и указали права доступа, жмите кнопку «Share».
21. Приглашенный участник получит на свой email письмо со ссылкой на приглашение. Ему будет необходимо пройти по данной ссылке и принять приглашение на доступ к вашему репозиторию.
22. После того, как приглашение принято, новый участник будет видеть у себя в аккаунте данный репозиторий и свою ссылку на доступ к нему с помощью TortoiseHg.
23. Дальше вашему сотруднику необходимо выполнить 7 пункт данной инструкции для получения файлов проекта к себе на компьютер.
Все изменения, сделанные вами и вашими помощниками, будут сохраняться в вашем репозитории. Вы сможете смотреть, что и когда было изменено и при желании в любой момент откатите ваш проект к нужной версии.
Я думаю, вводную статью о развертывании системы контроля версий без использования командной строки можно на этом заканчивать. Прохождение описанных выше шагов позволит вам внедрить у себя на проекте полноценную VCS, т.е. пройдя все шаги, вы получите хоть и не большой, но законченный результат.
Данный подход мы применили для разработки проекта: АвтоОфис – платформа для интернет бизнеса
Если у вас после прочтения статьи появились вопросы ко мне или уточнения и дополнения инструкций, то пишите в комментариях. Буду очень благодарен, если усилите статью своим пониманием VCS.
P.S.: В следующей статье постараюсь доступным языком расписать, что такое «Ветки», «Метки» и «Форки» и как с ними работать.
Лабораторная работа
«Настройка работы системы контроля версий (типов импортируемых файлов, путей,
фильтров и др. параметров импорта в репозиторий)»
Цель занятия: научиться устанавливать, настраивать и работать с репозиторием GitHub.
Оборудование, технические и программные средства: персональный компьютер, программа
Visual Studio 2019.
Время выполнения: 90 мин
КРАТКАЯ ТЕОРИЯ И МЕТОДИЧЕСКИЕ РЕКОМЕНДАЦИИ:
Управление версиями — это система для управления файлами с множеством разных версий. При разработке программного обеспечения с ней обычно работает большое число разработчиков. Основная цель любой системы управления версиями (VCS) заключается в том, чтобы найти решение, позволяющее всем пользователям одновременно работать с базой кода.
Основой системы управления версиями является репозиторий, который выступает в качестве центрального хранилища данных для любых файлов, что похоже на файловый сервер. Однако в отличие от файлового сервера репозиторий хранит весь журнал проекта и все внесенные изменения.
Если репозиторий является центральным хранилищем данных, логично, что каждый пользователь имеет локальное хранилище, с которым может работать. Оно называется рабочей копией. В Visual
Studio для Mac рабочая копия выглядит так же, как и любой локальный каталог на компьютере, что позволяет считывать и записывать файлы в нем. Но так как Visual Studio для Mac включает возможность интеграции с системой управлениями версиями, Subversion и Git можно использовать, не выходя из интегрированной среды разработки.
Subversion — это централизованная система управления версиями, то есть все файлы и редакции находятся на одном сервере, откуда пользователи могут получить для изменения любую версию любого файла. Если файлы извлекаются из удаленного репозитория Subversion, пользователь получит моментальный снимок этого репозитория на соответствующий момент времени.
Git — это распределенная система управления версиями, которая позволяет командам одновременно работать с одним документом. В случае с Git все файлы могут храниться на одном сервере, но при каждом извлечении репозитория из этого центрального источника весь репозиторий клонируется локально на ваш компьютер.
ПОРЯДОК ВЫПОЛНЕНИЯ РАБОТЫ И ФОРМА ОТЧЕТНОСТИ:
1. Первым делом необходимо установить Расширение GitHub Extension for Visual Studio.
2. Снизу должна появится строчка «Добавить в систему управления версиями».
3. Нажимаем на нее и добавляем проект в систему Git.
4. Основное окно работы (значок домика)
Изменения – сделать записать (commit)
Ветви – можно создать ветвь либо объединить.
Синхронизация – синхронизировать данные локального репозитория и Интернет репозитория.
Так же эти действия дублируются в самом низу панели, просмотрите их. Так же там находится одна из важнейших функций View History. Пример истории рис. Ниже.
При написании какой-либо части когда, можно делать commit (и не забываем делать комментарии, короткие но понятные). Каждый commit будет отображаться в Истории, так же можно будет посмотреть на каком этапе что было изменено и вернуться обратно, либо начать ветвление с конкретного этапа, хоть вы и ушли далеко вперед.
5. Давайте напишем небольшую программу для наглядного примера. Допустим переход с одной формы на другу, добавим пару кнопок, и текста. Не забываем каждую часть когда commit.
6. Теперь можно попробовать добавить ветвь. Например решили попробовать другой способ решения, а тот что сейчас чтобы не комментировать и не удалять. Либо когда работает команда разработчиков, можно было над 1 проектом работать нескольким людям. Разделяются на задачи, и решает каждый свою, когда они все сделают, можно будет собрать решение целиком.
Снизу на панели нажимаем на master и выбираем Создать ветвь…вводим имя и жмем создать.
В дальнейшем можно будем менять ветвь и работать сразу в 2 направлениях, заметьте проект
1, но изменения в 1 ветви (master) ни как, не затрагивают проект во 2 ветви (Addfunction).
7. Попробуйте добавить какой-либо функционал во 2 ветвь. (Не забываем постоянно делать commit) Смотрим результат в View History и наблюдаем различия в проектах.
Между ветвями можно быстро перемещаться, просто выбрав нужную ветвь на панели снизу.
8. Так же ветви можно объединять. Допустим в 1 ветви сделана авторизация, во 2 ветви сделан тест.
На примере: если выбрать слияние из ветви (Addfunction) в ветвь (master), то получится следующее: в ветви master будет находится проект master+addfunction,а в addfunction только он сам.
Проверьте функцию слияния.
9. При слиянии может произойти конфликт, такое происходит в тех случаях, когда в 1 и 2 ветви в одной и тоже строке присутствуют различия, например:
Системы контроля версий (их ещё называют системами управления версиями) – один из инструментов, который использует в своей работе любой программист от первокурсника до опытного тим-лида с сотнями успешных проектов.
— Ссылки на примеры кода в репозиториях помещают в своё портфолио.
— Большие проекты с открытым программным кодом получают тысячи улучшений, благодаря размещению на специализированном хостинге.
— От 30 до 70% кода, использованного в программном продукте, профессиональные разработчики могут скопировать с проектов, представленных в открытых репозиториях.
Незаменимы системы контроля версий в командной разработке, где синхронизация процесса играет важную роль.
С необходимостью отката программы к предыдущей версии рано или поздно сталкивается любой программист.
В точке А программа отлично работает, а попытка расширить функционал, ввести дополнительные переменные, классы и пр. приводит в появлению ошибки.
Распознать ошибку удаётся не всегда. Поэтому многие программисты предпочитают «пройти перезагрузку» — откатиться к стабильной рабочей версии и переписать дополнения заново, построчно анализируя весь добавленный код.
Реализовать такую процедуру помогает использование системы контроля версий (СКВ), которое позволяет четко отследить историю разработки, найти стабильную версию и продолжить работу.
В системе контроля версий может содержаться, как программный код, так и любая другая информация (включая текстовые файлы, изображения и т.п.)
Как осуществляется контроль версий
Существует несколько моделей хранения данных:
Git-клиент
Для удобства работы с системой контроля версий git разработан целый ряд графических git-клиентов. Это программы, позволяющие эффективно работать с системой контроля версий, используя графический интерфейс.
Многие IDE предполагают возможность работы с git.
Работа с Git через IDE
Работа с системами контроля версий — важный навык, нужный каждому программисту.
В этом уроке мы с вами познакомимся с мощнейшим инструментом, которым должен владеть каждый уважающий себя разработчик. Встречайте короля систем контроля версий – Git. Расскажем, чем же он так хорош, где применяется, а главное - как его установить и настроить.
Урок 2. Git. Внутренняя реализация. Создание изменений: индексация и коммиты. Команды: init, status, add, commit.
1. Что такое системы контроля версий
2. Зачем нужен контроль версий?
3. Разновидности архитектур VCS
3.1. Локальная система контроля версий
3.2. Централизованная система контроля версий
3.3. Распределенная система контроля версий
4. Как появился Git?
5. Почему именно Git?
1. Установка и настройка Git
1.1. Установка для пользователей Windows
1.2. Установка Git в Linux
2. Видео "Установка, настройка Git, создание репозитория"
3. Домашнее задание
Система управления версиями (от англ. Version Control System, VCS) — программное обеспечение для облегчения работы с изменяющейся информацией. Система управления версиями позволяет хранить несколько версий одного и того же документа, при необходимости возвращаться к более ранним версиям, определять, кто и когда сделал то или иное изменение, и многое другое.
Такая система фиксирует изменения, что позволяет вам в случае чего откатиться к любой предыдущей версии файла. Кроме отката изменений, система контроля версий позволяет сравнивать версии одного и того же файла, чтобы найти в нем изменения, видеть, кто эти изменения внес, когда это было сделано и что могло вызвать проблему.
Такой процесс займет очень много сил и времени, а пользователей оставит недовольными. Вам бы очень помогла система контроля версий. Вы бы загрузили в нее файлы с кодом до внесения изменений, а после обнаружения ошибки, откатились бы к ним за считанные секунды. Функция отката изменений позволила бы вам оперативно загрузить в магазины старую версию приложения, которая работает без ошибок.
Понятно, что проект для команды - это бесценные знания, накопленные за все время его существования, и никому бы не хотелось, чтобы с ними что-то случилось. Система контроля версий защищает эти накопления от человеческого фактора, непредвиденных последствий и разных форс-мажоров.
Обычно, работая в команде, каждый разработчик трудится над какой-то своей частью проекта: создает новые функции, оптимизирует уже существующие, исправляет ошибки в уже написанном коде. Сам проект обычно организован в виде дерева файлов. Контроль версий помогает сотрудникам одновременно работать над проектом, отслеживать, кто какие изменения внес, и избегать при этом различных конфликтов (например, когда два человека изменят один и тот же файл по-разному).
Помимо этого, как уже было сказано выше, любое изменение кода может привести к непредвиденным последствиям и сломать весь проект вообще. Система контроля версий защищает и от этого.
Существует три основных разновидности архитектур систем контроля версий: локальная, централизованная и распределенная. Рассмотрим их все.
Этапы синхронизации
Как сделать так, чтобы разработчик смог передать актуальную версию проекта коллеге?
Для взаимодействия с системой Git в консоль вводятся специальные команды. Не пугайтесь, работу с консолью можно будет заменить на работу с одной из программ, о которых расскажем ниже. Но чтобы лучше понимать суть, придётся запомнить несколько команд. Все они начинаются с ключевого слова git . Для синхронизации есть две основных команды: pull (англ. «тянуть») и push (англ. «толкать»).
Если работа над проектом ведётся в команде, то перед тем как начать писать код, нужно получить последнюю версию проекта. Для этого нужно выполнить команду pull . Так мы забираем все изменения, которые были совершены со времени последней синхронизации с удалённым репозиторием. Теперь они у нас в репозитории на локальном компьютере.
Синхронизация (push и pull) между локальными и удалённым репозиториями.
3.2. Централизованная система контроля версий
Как было сказано выше, одна из проблем, с которой вы столкнетесь, работая в команде разработчиков - это то, что вам нужно делиться файлами (и их версиями) с другими разработчиками.
Например, чтобы старший разработчик проверил ваш код на ошибки, перед тем, как дать вам разрешение на внесение изменений в рабочий файл. Для решения этой проблемы была придумана централизованная система контроля версий. Схематически она устроена так:
Из рисунка видно, что есть один сервер с сохраненными версиями всех файлов, а разработчики обращаются к нему за файлами.
Такими системами были очень популярные в свое время CVS, Subversion и Perforce. Долгое время такой тип системы контроля версий считался стандартом. Такая система довольно удобна с точки зрения руководства компании. Она позволяет им следить, кто и чем занимается в текущий момент, позволяет настроить: кому какие файлы можно редактировать, а кому - нельзя.
Тем не менее, централизованная система контроля версий имеет множество недостатков. Если сервер отключится на несколько часов, то работа целой компании будет парализована: никто не сможет сохранять версии файлов с кодом.
Если будет поврежден жесткий диск сервера, на котором хранятся данные, то восстановить их не удастся (если только не были сделаны копии), и вся работа будет потеряна.
В этом плане такая система мало чем отличается от локальной: если вы храните все данные проекта только на одной машине, вы рискуете потерять все из-за непредвиденного сбоя в работе этой машины.
Кроме того, поскольку вы не храните никаких данных локально, вам нужен бесперебойный высокоскоростной интернет на протяжении целого дня, чтобы скачивать и загружать данные с сервера. Это, конечно, не проблема, но однозначно минус.
Подытожим:
Централизованная VCS хранит все данные на сервере, а сотрудники получают к ним доступ.
Примерами удаленных систем контроля версий являются CVS, Subversion и Perforce.
Преимущества централизованных VCS:
1. Вы можете работать в команде с другими разработчиками.
2. Ваше начальство видит, чем вы занимаетесь.
3. У администратора есть четкий контроль, кто и что может делать. Администрировать центральную VCS намного проще, чем локальные на каждой машине.
Недостатки централизованных VCS:
1. Все данные хранятся только на одном сервере. Если он выключится, то работу всей компании парализует.
2. Если с сервером что-то случится, а копий данных нет, то весь проект может быть потерян.
3. Для работы необходим хороший интернет на протяжении целого дня.
Типовой рабочий процесс с использованием Git
Разберём типовой процесс разработки сайта в команде. Представим, что Игорь и Алиса — разработчики на одном проекте. Игорь начал верстать проект и сделал первые коммиты, в которых зафиксировал изменения в файле index.html . Для схематичности названия коммитов будут простые: B1 и B2.
Коммиты B1 и B2.
Игорь запушил свои коммиты.
После пуша данные синхронизировались с удалённым репозиторием. Но как Алисе теперь получить изменения? Для этого она выполняет команду git pull и получает все изменения из облака к себе на компьютер. Таким образом, состояние проекта у Игоря и Алисы синхронизировались, и они могут дальше продолжить работать над ним.
Данные у обоих разработчиков синхронизировались.
Параллельные изменения
Что произойдёт, если разработчики изменят одинаковый файл и сделают push ? Предположим, что Игорь и Алиса изменили файл index.html , сделали коммит с изменениями и запушили его. Игорь оказался быстрее Алисы и сделал push первым.
Два пуша в одно время?
В этом случае Git сообщит Алисе, что нельзя пушить свои изменения, потому что она не делала pull . Дело в том, что после того как Игорь синхронизировался с удалённым репозиторием, версия проекта Алисы стала отличаться от той, что находится на удалённом репозитории, и Git это видит. Система сообщает, что перед тем, как выполнить команду push , нужно выполнить pull , чтобы забрать изменения. Алиса делает pull и ей вновь приходит уведомление от Git. В этот раз он сообщает Алисе о том, что произошёл конфликт.
Конфликт
Дело в том, что Игорь и Алиса изменили одинаковый файл и теперь Алисе предстоит решить конфликт.
Конфликт
Существуют два вида конфликтов:
- Автоматически разрешаемый конфликт.
- Конфликт, который нужно разрешить вручную.
Ниже рассмотрим оба варианта.
Слияние
Допустим, что на третьей строке Игорь добавил в проект шапку, а на четвёртой Алиса добавила футер.
Игорь сделал шапку и отправил коммит, а Алиса добавила подвал.
Git видит, что произведённые изменения не затрагивают друг друга. Он сам объединит две версии проектов в одну, совершив слияние. После этого Алиса спокойно синхронизируется с удалённым репозиторием, отправив новую версию проекта.
Изменения в проекте не пересекались и Git выполняет слияние сам.
Во время слияния Git не знает, в каком порядке расположить коммит В3 Игоря и коммит В4 Алисы, из-за которых случился конфликт. Поэтому Git разрешает существовать нескольким версиям проекта одновременно. Как раз для этого и нужен следующий коммит В5, в котором происходит слияние предыдущих параллельных версий. После того как Алиса запушит изменения, она отправляет все версии проектов на удалённый репозиторий. В следующий раз, когда Игорь сделает pull , он получит полную историю со слиянием конфликта.
Слияние.
Алиса и Игорь изменили один и тот же блок.
В таком случае Git не знает чья версия проекта правильная и поступает очень просто. Он изменяет файл index.html , добавляя в него изменения и Игоря и Алисы. После этого предупреждает Алису о конфликте и просит выбрать правильный вариант.
Версии файла.
Версии проектов разделяются строками второй, четвёртой и шестой. Их нужно удалить и оставить правильный вариант заголовка. После того как Алиса это сделает, она сможет закоммитить изменения и запушить их на удалённый репозиторий. Игорь же при следующей синхронизации с облаком получит тот вариант заголовка, который выбрала Алиса.
Работа в команде
Как синхронизовать данные репозиториев между разработчиками? Изначально Git репозитории сами могут синхронизироваться от пользователя к пользователю. Дополнительные программы для этого не нужны. Есть специальные команды в консоли, позволяющие передавать данные из одного репозитория в другой.
Репозитории можно синхронизировать между пользователями.
Этот способ сложный и редко используется. Чаще всего разработчики синхронизируют локальный репозиторий с удалённым. Удалённый репозиторий — это тот же репозиторий, только его данные находятся в облаке.
Синхронизация через удалённый репозиторий.
Основные понятия
Список терминов, которые будут вам полезны.
Репозиторий
Проект, в котором была инициализирована система Git, называется репозиторием. При инициализации в проект добавляется скрытая папка .git . Репозиторий хранит все рабочие файлы и историю их изменений.
Рабочая область и хранилище
Корневая папка проекта — это рабочая область. В ней находятся все файлы и папки, необходимые для его работы.
Хранилище — это содержимое скрытой папки .git . В этой папке хранятся все версии рабочей области и служебная информация. Этим версиям система автоматически даёт название, состоящее из букв и цифр. В примере выше — это bea0f8e и d516600 . Не стоит проводить манипуляции с папкой .git вручную. Вся работа с системой производится командами через специальные приложения или консоль.
Коммит
Точно так же, как и в игре, в системе контроля версий Git можно сохранить текущее состояние проекта. Для этого есть специальная команда — commit . Она делает так, что новая версия проекта сохраняется и добавляется в хранилище. В файле с сохранением отображаются: все изменения, которые происходили в рабочей области, автор изменений и краткий комментарий, описывающий суть изменений. Каждый коммит хранит полное состояние рабочей области, её папок и файлов проекта.
В итоге проект работает так:
- Репозиторий хранит все версии проекта. В случае передачи этого проекта другому человеку, он увидит всё, что с ним происходило до этого.
- Ничего не теряется и не удаляется бесследно. При удалении файла в новой версии добавляется запись о том, что файл был удалён.
- Всегда можно вернуться к любой из версий проекта, загрузив её из хранилища в рабочую область.
Примитивная модель хранения версий
В примитивной модели актуальные копии проекта перезаписываются в отдельную директорию через определённый промежуток времени.
Достоинства:
— возможность восстановления данных одной из записанных версий.
Недостатки:
— сложности с поиском необходимой версии в обширной и плохо структурированной базе данных;
— возможность потери данных вследствие возникновения физических поломок оборудования;
— отсутствие возможности совместной разработки.
3.1. Локальная система контроля версий
Вы спросите: почему нельзя просто сохранять файл под разными именами, а затем открывать нужный? Да, так делать можно, но это вызовет массу проблем. Вы можете забыть, какой файл содержит итоговую версию, можете запутаться в миллионе одинаковых файлов, отличающихся парой строк кода. Вы не сможете быстро сравнить две версии, чтобы посмотреть, какие изменения были внесены.
Для решения этих проблем была придумана локальная система контроля версий. Схематически она представляет из себя следующее:
Из рисунка видно, что есть несколько версий одного и того же файла. А сам файл сейчас находится в состоянии третьей версии.
Одной из самых популярных локальных систем контроля версий на сегодняшний день (не считая Git) остается система RCS. Она работает по принципу сохранения изменений в ваших файлах. То есть она хранит не целую новую версию, а только указания к изменению первоначального файла. Например, "добавить к предыдущей версии строку import math ". Таким образом, последовательно изменяя файл, система воссоздает любую из его версий.
Подытожим:
Локальные VCS хранятся у вас на компьютере. Пример локальной VCS - RCS - одна из первых систем контроля версий, разработанная в 1985 году.
Составим список преимуществ и недостатков локальных VCS.
Преимущества:
1. Позволяет хранить историю изменения файлов локально, без интернета.
2. Вы независимы от сторонних серверов.
Недостатки:
1. Вы можете потерять все файлы, если с вашем компьютером что-то случится.
2. Вы не можете работать в команде, поскольку репозиторий доступен только вам.
Git
Git
Умение работать с git’ом — обязательный навык для программиста любого профиля. Можно долго обсуждать преимущества и недостатки разных систем контроля версий, но большинство компаний используют git, поэтому уметь работать с git’ом нужно всем.
Git – распределённая система контроля версий. Что даёт ей все преимущества децентрализованной СКВ:
— высокую скорость проведения всех операций (за счет отсутствия сетевой задержки);
— идеальные условия для командной разработки;
— страховку от потери информации при возникновении проблем с центральным сервером.
Для контроля версий в git используются 2 репозитория: локальный и удаленный. Локальный репозиторий (полноценный репозиторий, а не ссылки или копии отдельных ветвей) находится на компьютере разработчика, а удаленный на удалённом сервере. Доступ к удаленному репозиторию обеспечивается благодаря гит-хостингу Github, Google Code, GitLab и т.д.
Централизованные системы контроля версий
Централизованные системы контроля версий предполагают сохранение версий проектов на общий сервер, с которого потом получают нужные версии клиенты.
Централизованные системы контроля версий
Достоинства:
— возможность восстановления данных из определенной версии (точно определяется по времени записи);
— возможность ведения командной разработки проекта;
Недостатки:
— отсутствие доступа к данным при сбое работы сервера;
— довольно низкая скорость работы (из-за возникновения сетевых задержек).
Система контроля версий Git
Git — это распределённая и децентрализованная система управления версиями файлов. Децентрализованная система означает, что у каждого разработчика есть личный репозиторий проекта с полным набором всех версий. А все необходимые для работы файлы находятся на компьютере. При этом постоянное подключение к сети не требуется, поэтому система работает быстро. При командной разработке нужна синхронизация репозиториев, так как проект — один и его состояние должно быть у всех одинаковым.
Читайте также: