Система управления версиями Git. Система управления версиями git и российский сервис хранения исходного кода gitflic
 Скачать 3.56 Mb.
|
|
1.6. Встроенные системы управления версиями В предыдущих разделах рассмотрены системы управления версиями, представляющие собой самостоятельный, отдельно стоящий инструмент. Эти системы используются в процессе профессиональной разработки про- граммного обеспечения. Наряду с профессиональными существуют си- стемы управления версиями, встроенные в программные инструменты, ис- пользуемые для решения офисных и даже повседневных задач. Большинство работающих с этими инструментами людей даже не подозревают, что пользу- ются системами управления версиями. Рассмотрим несколько примеров. Сервисы синхронизации файлов между устройствами, такие как Drop- box, отслеживают версии файлов, с которыми работают пользователи. Про- цесс выглядит следующим образом. Файловая система компьютера автома- тически сохраняет информацию о времени последнего изменения файла. Сервис синхронизации периодически сравнивает файлы, находящиеся на сервере, с файлами на локальном компьютере. Если файлы отличаются и файл, находящийся на сервере, старше файла, находящегося на локальном компьютере, то выполняется процесс синхронизации. Файл, находящийся на сервере, становится частью истории изменений, а на его место скачива- 26 ется файл с локального компьютера. Dropbox сохраняет файл в истории каж- дый раз, когда пользователь нажимает кнопку «Сохранить». Файл сохраня- ется целиком и называется снимком. Благодаря такой процедуре Dropbox в состоянии восстановить любую версию файла. Недостаток такого подхода очевиден – значительный расход дискового пространства. Возможно, с точки зрения экономии дискового пространства было бы эффективнее хра- нить дельты, как это делается во многих профессиональных системах управ- ления версиями. Но в этом случае время восстановления версий будет зна- чительным. Экономия дискового пространства или малое время восстанов- ления предыдущих версий? Эта дилемма возникает всегда при разработке систем управления версиями. Системы управления версиями являются неотъемлемой частью тек- стовых редакторов, особенно онлайновых. Google Docs выполняет проце- дуру автосохранения приблизительно каждые 5 секунд. Если файл изме- нился, то делается снимок, который сохраняется в истории изменений. История изменений иначе называется историей ревизий. Ревизия бо- лее общее понятие, чем снимок. Ревизия – это любое зафиксированное из- менение в файле, как правило, сохранённое в истории изменений. Ревизия может выполняться с использованием снимка или дельты. Ревизия – это контейнер для снимка или дельты, помимо самого снимка (дельты), она со- держит дополнительную информацию, например, дату сохранения, имя ав- тора и т.п. Процесс переключения между ревизиями имеет своё название в рамках систем управления версиями. Этот процесс называется checkout. Например, в Git существует команда git checkout. Современные текстовые редакторы являются инструментом коллек- тивной работы над документами. Любой коммерческий договор проходит несколько стадий согласования и зачастую возвращается к автору или ре- цензенту несколько раз. Разумеется, сотрудник, получивший документ с ис- правлениями (замечаниями), прежде всего, хочет узнать, какие правки в него были внесены. Для того чтобы увидеть изменения, необходимо срав- нить ревизии. Если ревизия была сохранена с использованием дельты, то достаточно извлечь нужную дельту и отобразить её. Если ревизия хранится в виде снимков, то необходимо вычислить дельту перед отображением. Например, Microsoft Word хранит историю ревизий и позволяет сравнивать версии документа, отображая в наглядной форме, что и где изменилось. Для 27 Microsoft Word существуют два вида ревизий. Одна из них называется ре- жимом записи исправлений и сохраняет только удаления или изменения текста. В режиме записи исправлений возможно сравнивать оригинал и из- менённый документ, располагая их в двух соседних окнах. Такая история ревизий хранится непосредственно в документе в виде дельт. Другой вид истории ревизий сохраняет снимки и позволяет восстановить любую из предыдущих версий. Для того чтобы воспользоваться этим режимом, необ- ходимо подключиться к One Drive. При сохранении снимков Microsoft Word обеспечивает сравнение версий, вычисляя дельты. Какой бы из систем управления версиями вы ни воспользовались, ра- бочий процесс будет выглядеть одинаково: − создание репозитория; − добавление новых файлов; − коммит; − внесение изменений в файлы (редактирование, добавление, удаление); − коммит; − и так далее до завершения работы над проектом (документом). Термины «коммит» и «ревизия» являются синонимами. В данной ра- боте в дальнейшем будет использоваться термин «коммит». С практической точки зрения к коммиту предъявляются два следую- щих требования. 1. Коммит должен иметь комментарий. В большинстве систем управ- ления версиями коммит невозможно сохранить, если комментарий отсут- ствует. Комментарий состоит из краткого заголовка, описывающего суть из- менений, зафиксированных в коммите. За заголовком, если требуется, сле- дуют подробные объяснения. Это правило обеспечивает самодокументиро- ванность истории версий и способствует эффективной работе с ней. 2. Коммит должен фиксировать решение одной задачи, как можно бо- лее полное. Это правило называется атомарностью коммита. Как и первое правило, оно способствует эффективной работе с историей версий, кроме того, помогает понять, какие коммиты необходимо отменить, чтобы вер- нуться к предыдущей версии, если это необходимо. Контрольные вопросы 1. Какие задачи решает система управления версиями? 28 2. Дайте сравнительную характеристику систем управления верси- ями 1-го, 2-го и 3-го поколений. 3. Опишите принципы формирования файла истории. Что такое дельта (прямая и обратная)? 4. Раскройте понятие термина «ветка» по отношению к системе управления версиями. 5. Что такое «централизованный репозиторий»? Какова его роль в развитии систем управления версиями? 6. Что такое «коммит»? Какие проблемы, возникающие при исполь- зовании коммитов, решает «журналирование»? 7. Что такое «распределённый репозиторий»? Опишите его преиму- щества по отношению к «централизованному репозиторию». 8. Раскройте смысл термина «встроенная система управления верси- ями». Приведите пример встроенной системы управления версиями. 29 2. СИСТЕМА УПРАВЛЕНИЯ ВЕРСИЯМИ GIT Вторая глава посвящена системе управления версиями Git. Будут по- дробно рассмотрены все этапы использования репозитория Git от создания до управления ветками. В ходе описания команд Git будет продемонстриро- вано внутреннее устройство репозитория. Из этой главы читатель получит полное представление о Git как инструменте управления версиями и сможет начать использовать его в своей работе. Дальше практика, практика и ещё раз практика. 2.1. Особенности и преимущества Git Git является распределённой системой управления версиями. Это значит, что полная версия репозитория находится на локальном компью- тере. Нет необходимости постоянно сохранять изменения в удалённом ре- позитории и загружать из него обновления. Всё, что происходит на локаль- ном компьютере, остаётся только на локальном компьютере. Во внешний мир уходят только проверенные версии, поэтому никто не узнает о неуда- чах, ошибках и откровенных ляпах. Копии репозитория могут находиться на нескольких компьютерах: домашнем, офисном, дачном, и на всех компь- ютерах будут одни и те же версии файлов. Если есть необходимость выпол- нить работу на «новом» компьютере, репозиторий может быть перенесён на него очень быстро. В общем, полная свобода перемещений. Git даёт полный контроль над версиями. Коммиты можно удалять, из- менять, менять местами, объединять, разделять, перемещать между ветками. Основной инструмент Git – это ветки. Ветки создаются для проверки решения подзадач, для выбора одного варианта из нескольких, для помощи коллеге, для сохранения идеи «на будущее». Создать ветку, переключиться между ветками, слить ветки, удалить ветку – эти операции выполняются по- стоянно в ходе работы над проектом. Ветки – то, ради чего существует си- стема управления версиями. Ветки и есть версии. Git предоставляет гибкий инструмент управления коммитами. 30 Перед созданием коммита можно посмотреть, что в него войдёт и отредак- тировать список файлов, при необходимости. Можно посмотреть историю коммитов для одного файла или для всей ветки. Сравнить версии файла в различных коммитах. Удалить коммит, восстановить рабочую версию из коммита. Git позволяет заморозить изменения без создания коммита. Если нужно срочно переключиться на другую ветку, а текущая ветка ещё не го- това для коммита, то её можно заморозить. Изменения не будут потеряны, и не придётся создавать «технологический коммит», не несущий смысловой нагрузки. Git позволяет организовать работу в команде. Каждый програм- мист работает в своей ветке, что ускоряет разработку за счёт разделения её на несколько потоков. Перед добавлением ветки в проект она отправляется на проверку и рецензию. При необходимости код, содержащийся в ветке, дорабатывается. В результате в проект попадает только проверенный код. Программисты видят результаты работы коллег и могут обмениваться иде- ями, устраивать консультации, совместные обсуждения, оказывать помощь. Для Git существует большое количество бесплатных удалённых репозиториев, таких как GitHub, GitFlic, BitBucket. 2.2. Установка и настройка Git для Windows Для использования Git его необходимо установить на компьютер и настроить. Для установки Git на компьютер, работающий под управлением опе- рационной системы Windows, необходимо скачать дистрибутив с официаль- ного сайта Git: www.git-scm.com, запустить его и выбрать необходимые опции, предлагаемые установщиком. Здесь будут пояснены две наиболее важные оп- ции. Не беда, если в процессе установки будут выбраны «не те» опции, их можно будет изменить после установки с помощью команды git config. Выбор имени основной ветки. Git предлагает имя для основной ветки, но лучше придумать своё. В этом случае, при обновлении версии Git, имя основной ветки не изменится. Выберите опцию “Override the default branch name for new repositories” и введите имя основной ветки в поле ввода. 31 Настройка запуска Git из консоли. Выберите опцию “Git from the com- mand line and also from 3 rd -party software”. Это позволит запускать Git не только из консоли Git Bash, но и из консоли Windows и других приложений (например, сред разработки). После завершения установки на компьютере появится папка, содер- жащая программы: − Git Bash – оболочка работы с Git, основанная на Bash; − Git CMD – окно командной строки Windows для работы с Git; − Git FAQs – ссылка на сайт с ответами на наиболее частые вопросы про Git; − Git GUI – графическая оболочка для работы с Git; − Git release notes – ссылка на сайт с информацией о текущей и преды- дущих версиях Git. Что использовать для работы с Git: Git Bash, Git CMD, Git GUI – каж- дый из пользователей должен решить самостоятельно. В настоящем изда- нии для демонстрации примеров будет использоваться Git Bash, поскольку Bash является оболочкой, доступной и в Windows, и в Linux, что делает при- меры воспроизводимыми в различных операционных системах. 2.3. Основные понятия Ниже приведено формальное описание терминов, которые будут ис- пользоваться в процессе изложения материала. 1. Репозиторий. Любая папка файловой системы может быть преоб- разована в репозиторий Git. После преобразования внутри этой папки по- явится папка .git/, содержащая дерево изменений проекта. 2. Рабочая директория. Все папки и файлы внутри репозитория за исключением .git/. С файлами, находящимися в рабочей директории, проис- ходят основные изменения в рамках работы над проектом. 3. Индекс. Файл, расположенный в папке .git/, содержит список фай- лов, подготовленных для добавления в коммит. 4. Коммит. Файл, который хранит изменённые файлы, имя автора коммита, время создания коммита. Каждый коммит имеет уникальное имя, 32 позволяющее вернуть рабочую директорию в состояние, которое было до внесения изменений, зафиксированных в коммите. 5. Указатель. Ссылка, которую использует Git или программист, чтобы сослаться на коммит. 6. Ветка. Последовательность коммитов. Для ссылки на ветку ис- пользуется указатель на последний коммит ветки. В репозитории изна- чально содержится одна ветка. В дальнейшем может быть добавлено не- ограниченное количество независимых веток. 2.4. Настройка Git, команда git config После установки Git встраивается в операционную систему и влияет на её поведение на системном, глобальном и локальном уровне. В соответ- ствии с этим, существуют три файла настроек: 1. Системные. Распространяются на всех пользователей операцион- ной системы. Файл с системными настройками Git называется gitconfig и расположен в директории C:\Program Files\Git\etc\. 2. Глобальные. Распространяются на все репозитории, созданные под логином пользователя. Файл с глобальными настройками Git называ- ется .gitconfig и расположен в директории C:/User/<имя пользователя>/. 3. Локальные. Влияют на настройки одного репозитория. Файл с настройками называется config и расположен в директории .git/ репозитория. Для изменения настроек можно отредактировать файл конфигурации в текстовом редакторе или воспользоваться командой git config. Эта ко- манда позволяет изменить или посмотреть значение параметров конфигура- ции Git. Формат команды git config: git config <ключ> <параметр> <значение> Ключ задаёт область действия параметра. Возможные значения: --global – указывает на то, что будут изменяться настройки файла gitconfig; --system – указывает на то, что будут изменяться настройки файла .gitconfig; 33 --local – указывает на то, что будут изменяться настройки файла config (это значение ключа установлено по умолчанию). Параметр указывает, какая настройка будет изменена. Возможные значения: – user.name – имя пользователя; – user.email – адрес электронной почты пользователя. Значение – текстовая строка, задающая значение параметра. В следующем примере изменяются имя пользователя и его e-mail в глобальных настройках. $ git config --global user.name 'Git_Book' $ git config --global user.email 'git_book@home.com' После выполнения приведённых команд файл .gitconfig будет выгля- деть следующим образом: [user] name = Git_Book email = git_book@home.com [credential "https://gitflic.ru"] provider = generic Поля name и email содержат значения, заданные соответствующими командами Git, приведёнными выше. 2.5. Создание локального репозитория, команда git init Команда git init создаёт новый локальный репозиторий в той папке, в которой она была выполнена. Формат команды git init: git init <параметр> Один из возможных параметров задаёт имя главной ветки проекта: --initial-branch=<имя ветки> В примере ниже создаётся репозиторий в папке Learn_git. Имя глав- ной ветки этого репозитория Main_branch. 34 /c $ mkdir Learn_git /c $ cd Learn_git /c/Learn_git $ git init --initial-branch='Main_branch' Initialized empty Git repository in C:/Learn_git/.git/ /c/Learn_git (Main_branch) Признаком того, что папка является репозиторием Git, будет название ветки в скобках после указания пути к папке. В папке Learn_git командой git init была создана папка .git со следую- щей структурой вложенных папок. └───.git ├───hooks ├───info ├───objects │ ├───info │ └───pack └───refs ├───heads └───tags Назначение этих папок и их содержимое будет поясняться далее, по мере изучения команд Git и создаваемых ими объектов. 2.6. Логическая структура Git Логически репозиторий состоит из трёх частей: рабочая директория; файлы, подготовленные для включения в очередной коммит (Staging area); хранилище файлов предыдущих версий (архив). В рабочей директории находятся файлы, в которые программист вносит текущие изменения. Staging area включает изменённые файлы, которые планируется включить в очередной коммит. Архив содержит все предыдущие версии файлов проекта. На рисунке 2.1 показана диаграмма «перемещения» файлов между ло- гическими частями репозитория. 35 Рисунок 2.1 – Диаграмма перемещения файлов Работа программиста, использующего Git, выглядит следующим обра- зом. Редактирование файлов в рабочей директории. Git следит за тем, какие файлы были изменены, и может сформировать список изменённых файлов. Ко- гда программист решит, что файл содержит изменения, которые необходимо зафиксировать, он даёт Git команду подготовить файл для сохранения в архиве. Git преобразует файл в формат, удобный для хранения, и размещает его в ар- хивной папке .git. Этот файл находится в промежуточном состоянии. Он уже в архиве, но ещё не включён в историю изменений. Это Staging area. Когда все файлы, включающие логически завершённую часть решаемой задачи, разме- щены в Staging Area, программист даёт Git команду включить файлы из Staging area в историю изменений. Git формирует структуры, описывающие произо- шедшие изменения, и сохраняет их в папке .git. 2.7. Состояния файлов, команда git status Файлы, находящиеся в рабочей директории, могут находиться в од- ном из двух состояний: отслеживаемые и не отслеживаемые. В число отсле- живаемых входят все файлы, которые хотя бы один раз попадали в Staging area. Про файлы, ни разу не попадавшие в Staging area, Git знает только то, что они существуют, и не отслеживает происходящие в них изменения. Отслеживаемые файлы делятся на три категории: неизменённые, из- менённые, подготовленные к коммиту. На рисунке 2.2 показана диаграмма 36 перехода файлов из одного состояния в другое. Рисунок 2.2 – Диаграмма изменения состояния файла Для того чтобы файл стал отслеживаемым, его необходимо поместить в Staging area. Например, для того чтобы файл, скопированный из другой папки, стал частью репозитория, его необходимо включить в коммит (даже, если в этот файл не будут внесены никакие изменения). Для того чтобы файл стал не отслеживаемым, его необходимо удалить из рабочей директории. После удаления файл останется в архиве, и его можно будет восстановить. Файл становится изменённым, если в него внесены изменения. Файл становится Staged (подготовленным к коммиту) после соответ- ствующей команды программиста. При этом новая версия файла будет со- хранена в архиве, но не внесена в историю изменений. После того, как был выполнен коммит, все файлы из Staged area пере- ходят в состояние неизменённых и остаются отслеживаемыми. Для определения состояния файлов, находящихся в рабочей директо- рии, предназначена команда git status. |