ПРО GIT: Ветки (бранчи)
февраля 1, 2011 | Published in Development Processes, Управление Версиями
Цикл статей ПРО GIT:
Введение
Ветки (бранчи)
В прошлой статье о системе управления версиями Git я как-то слишком сухо рассказал о том, что это такое и зачем все это необходимо, позабыв о тех людях, которые совсем не знакомы с таким технологическим процессом разработки как контроль версий. Именно из-за этого своего упущения я решил начать эту статью с так сказать теории о системах управления версиями.
1. Система Управления версиями (СУВ) — что это?
1.1. Прошлый опыт
Возможно название показалось вам сложным и даже напугало вас, однако СУВ -это достаточно простая вещь! Успокойтесь, расслабьтесь, сделайте глубокий вдох и больше никогда ничего не бойтесь!
Вспомните последний раз, когда вы работали в MS Word или Photoshop. Работая практически с любым редактором будь то текстовый, графический, музыкальный или видеоредактор вы всегда допускаете ошибки. Затем вы исправляете эти ошибки, а затем заметив, что ваши исправления неправильны, нажимаете «Undo», «Step back up» или как там оно у вас называется? Еще часто возникает необходимость отредактировать какой-либо текст или по заготовке отрисовать детальный дизайн сайта. Тогда, чтобы не портить заготовку, вы создаете ее копию и вносите изменения в одну из копий, а если что-то пошло не так, то вы либо используете те же «откаты», либо просто удаляете файл, создаете новую копию оставшегося оригинала и заново начинаете работать. Вам ведь все это знакомо, не так ли?
Если ваш ответ утвердителен, значит вы уже знакомы с системами управления версиями и ваше «знакомство» с ними подразумевает активное их использование!
1.2. Дадим определение понятию СУВ
СУВ — системы управления версиями, это инструмент, который в процессе работы позволяет нам каким-либо путем записывать наши изменения рабочих файлов, для возможности последующего отката.
GIT — это абсолютно обычная СУВ!
1.3. Разновидности СУВ
Существует как минимум 3 основных СУВ:
— Локальный
— Централизованные
— Распределенные
1.3.1. Локальные СУВ
Локальные СУВ должны быть знакомы начинающим программистам. Вы наверняка при работе с кодом, перед началом работы создаете копию рабочего каталога для того, чтобы если вы что-то напортачили, то у вас оставался тот прогресс на котором вы остановились в прошлый раз. Лично я делал так: Допустим у меня есть рабочая директория project в этой директории я создавал папку saves в которой хранились другие директории с именами версий 1, 2, 3 и т.д. и в каждой директории находились копии всех рабочий файлов с прогрессом на определенный момент времени. Я уверен, что многие делали подобным образом, возможно именовали категории не 1, 2, 3, а более логичным способом или еще что-то типа того. Все это можно назвать локальной СУВ каменного века! Существуют также специальные программы локальных СУВ, которые позволяют автоматизировать это копирование папок и файлов или использовать другой способ сохранения стадий развития проекта (версий).
Достоинства: Простота
Недостатки: Относительно небольшая область применения, опасность потери данных в случае если ваш компьютер поломался, или его у вас украли или все уничтожил вирус или …
1.3.2. Централизированные СУВ
Когда идет работа над большим проектом с окромным количеством папок, а в них в каждой огромное количество файлов, а в них в каждом огромное количество строк кода, то над таким проектом, как правило, работает несколько человек. Из необходимости организовать работу группы людей и были созданы централизированные СУВ (из тех, о которых я слышал это Subversion и CVS).
Представьте себе монарха восседающего на золотом троне да с золотой короной на златых власах… Представьте теперь сокровищницу с неисчислимыми богатствами. А теперь представьте, как верные вассалы подношают царю налоги собранные со своих крепостных да подарки, чтобы задобрить своего владыку. — Вот примерно таким образом организованы централизированные СУВ.
Есть монарх он же главный разработчик и есть вассалы — разработчики каждый из которых вносит какую-то свою определенную лепту. Сокровищница в данном случае это центральный репозиторий в который добавляются результаты работы участников процесса разработки какого-либо проекта (налоги).
Достоинства: Высокая степень организации процесса разработки, контроль основного (центрального) репозитория, широкая область применения.
Недостатки: Существует риск потерять данные если сервер на котором размещен центральный репозиторий поломается.
1.3.3. Распределенные СУВ
Представьте детскую группу в садике. У детей урок аппликации. У каждого ребенка свои ножницы, своя цветная бумага, клей, заляпанные клеем штаны и полное довольством за свою работу лицо. Дети заканчивают делать свои работы, воспитательница собирает их, выбирает самые хорошие и отправляет их, например, на городскую выставку детского творчества предварительно сделав всем детям альбомы с копиями работ. — Все это похоже на то, как работают распределенные СУВ.
При распределенных СУВ также имеется центральный (основной) репозиторий (воспитательница), но в этот раз центральный репозиторий является не единственным местом хранения версий проекта так как разработчики делают локальные копии центрального репозитория и теперь если один из компьютеров разработчиков или центральный сервер накроется, то потери будут совсем минимальными и работу можно будет достаточно быстро восстановить (альбомы с копиями аппликаций). Как вам, нравится такой подход?
Git относится именно к распределенным СУВ.
Достоинства: Безопасность данных, высокая степень организации процесса разработки, широкая область применения.
Недостатки: Незначительно увеличивается сложность процесса контроля версий.
1.3.4. История Git
Чисто как дань уважения пишу небольшой раздел об истории появления Git (честно говоря я никогда этот раздел в книгах не читаю).
Жил был на свете Антон Городецкий Линус Торвальдс и занимался он с 33 богатырями разработкой ни чего нибудь, а ядра Linux! Сами понимаете, операционные системы — это достаточно сложные программы для разработки которых без использования СУВ не обойтись. Так вот, поначалу худо-бедно богатыри вели контроль версий путем, на сколько я понимаю рабским, то есть, как я понял все это было весьма глупо, производилось вручную и было трудоемко. Затем, в 2002 году Линус Торвальдс и компания богатырей — разработчиков решили воспользоваться СУВ BitBeeper. Затем, по некоторым причинам личного характера разработчики ядра Linux решили отказаться от BitKeepera и Линус Торвальдс в порывах чувств и пребывая в необыкновенной силы порыве энтузиазма создал Git. Read the rest of this entry »