Содержание:
Всем привет! Несмотря на такой долгую паузу после последней статьи о VestaCP, буду пробовать переходить на более интенсивный режим работы. С этого дня темы новых статей будут немного сменены, теперь вы увидите больше статей, связанных с вёрсткой сайтов. Я не беру на себя функцию обучить вас вёрстке, а, скорее, предоставляю вам миниконспект основ, к которому будет легко вернуться и повторить. Надеюсь, вам понравится и вы сможете эффективно использовать предложенную информацию. Хватит предисловий, приступим к работе.
Путь цикла было решено начинать именно GitHub. Потому что очень важно, какие инструменты в своей работе использует человек. Нельзя говорить о земледелии, не упомянув плуг)
Системы контроля версий
Древняя система контроля версий
Наверное, все когда-нибудь сохраняли 2 версии файла с небольшими отличиями под разными именами? К примеру, научка-вер1.txt и научка-вер1-проверил_Пушкин.txt. Первый файл вы отправили своему научному руководителю, он его проверил, внёс свои изменения и отравил вам второй файл. Такое может повторять вплоть до бесконечности, плодя множество файлов, названия которых ставятся все более и более странными. А ваша папка с версиями с "научкой" становится похожа на что-то дикое и сложное в понимании, и найти промежуточную версию становится очень и очень сложно.
Такой способ совершенно не приемлем* в мире разработки, особенно, если над проектом трудится много человек одновременно. И вот почему:
- Возможны ошибки в назначении версии файла.
- Неприменимо к множеству файлов.
- Нет гарантий, что у вас самая последняя версия файла.
- Невозможно работать одновременно группой разработчиков.
Современная система контроля версий
Если дать грубое определение по главной задаче GitHub, то это сервис для организации работы системы контроля версий Git, помогающий содержать версии проекта под контролем в надежном месте и дающий возможность для удобной совместной разработки. Теперь разберемся этими понятиями, выделенными жирным.
Система контроля версий — это та штука, которая позволяет удобно хранить все версии проекта (т.е. ничего не удаляется и не теряется), и, при надобности, вернуться к более ранним, а также посмотреть, кто, когда и что изменил, комментарии к правкам.
Цель такой системы - поддержание актуальной версии проекта у всех ее пользователей.
Для работы системы контроля версий нужно специальное хранилище - репозиторий, своеобразный сейф для файлов вашего проекта, аналог папки на рабочем столе в древней системе контроля версий.
Виды современной системы контроля версий
Централизованная.
- Существует только один репозиторий.
- Простые номера версий файлов (1, 2, 3 и т.д.).
- У пользователей хранится только текущая версия проекта.
- Требуется подключение к интернету.
- Просто, но медленно.
- Сложности в одновременной работе над одним файлом.
Распределенная.
На один проект приходится много репозиториев.
- Каждый пользователь создает локальную копию всего репозитория на основе главного облачного.
- Номера версий сложные.
- Возможность работать офлайн.
- Работать быстро и удобно.
- Требуется синхронизация репозиториев, так как проект — один.
Теперь можно дать определение и слову Git.
Git — это инструмент для реализации работы распределённой системы контроля версий.
Ниже будет описан процесс работы с распределенной системой, т.к. именно она используется в GitHub. В централизованной нет такого понятия, как синхронизация репозиториев, т.к. он один и с него мы загружаем только последнюю версию проекта, а в распространенной загружается весь репозиторий со всеми версиями, таким образом у каждого участника создается свой локальный репозиторий проекта.
Как работает GitHub
Для работы с GitHub нам потребуется установить клиент контроля версий (в GitHub, это GitHub Desktop) и создать репозиторий. Репозиторий можно создать, как через веб-сайт, так и через клиент.
Принципы работы с репозиторием GitHub
- С помощью клиента копируем весь репозиторий на свой компьютер (pull).
- Вносим различные правки, сохраняем, вносим правки и т.д. в различные файлы репозитория.
- Просим клиента внести изменённые файлы в репозиторий.
Внесение измененных файлов в репозиторий называется фиксацией изменений или «коммитом» (commit). - После коммита версия вашего локального репозитория изменилась.
- На данный момент изменения фиксированы только на локальном репозитории, чтобы они отобразились на сайте GitHub, требуется еще одна функция "синхронизация репозиториев" (push).
- Теперь ваш главный репозиторий, расположенный в GitHub, такой же, как на вашем компьютере.
Такая стандартная схема применима, когда над проектом работает один человек. Если над одним файлом проекта одновременно работает несколько человек, тут не обойтись без конфликтов, слияний, ручных разрешений конфликтов.
Слияние, конфликт, разрешение конфликта
Для понимая нужен пример. Влад и Артем сделали копию репозитория (pull) с фалом версии 1 с GitHub, внесли разные изменения в этот файл, оба зафиксировали изменения (commit) → версии фала в локальных репозиториев изменились, у Влада версия 2, у Артем 2А. И затем Влад запушил (синхронизировал репозитории- push). Теперь на GitHub добавилась версия файла 2. Артем тоже решил запушить свои изменения, т. к. на GitHub есть версия которой нет у Артема (у него нет версии 2), система откажется принимать его репозиторий для сохранения версии 2.
Для того, чтобы внести свои изменения, Артему нужно опять скопировать репозиторий (pull) с GitHub с дополнительной версией этого файла. При копировании произойдет конфликт.
На самом деле сильно конфликтов бояться не надо, при работе в большой команде их не избежать, это становится привычной рутиной.
Способы решения конфликта:
- Автоматическое слияние. Сравнивая построчно код Влада и Артема, GitHub может решить совместить куски кода в файле, при этой получится новая версия файла. При таком подходе в репозитории будут находиться версии 1, 2, 2А, и 3, а Артем теперь может запушить все отсутствующие версии файла.
- Разрешение конфликта вручную. Git пометит, какой код конфликтует, и вам нужно будет решить, какой вариант оставить или вообще внести третий. Создается версия 3, и Артем может запушить отсутствующие версии файла.
Master / не master, Fork, Pull request
Ветки — это своеобразные папки со всеми файлами проекта. Ветка Master - это самая главная папка вашего проекта, она всегда существует. Дополнительные ветки создаются под всякие дополнительные нужды.
Пример модели работы с ветками:
В Master лежит последняя стабильная версия, где вы можете вносить незначительные изменения; development - ветка для непосредственной разработки; dev-adaptive - ветка разработки, связанная с планируемым расширением функционала.
Что такое Fork? К примеру, на GitHub вам понравился какой-то проект, но вы заметили в нем ошибку и знаете, как ее решить, но доступа к редактированию чужого проекта у вас нет. Для этого вам нужно создать fokr. Теперь у вас есть доступ для редактирования файлов проекта. Вы справились с багом, но ваши труду пропадут даром т. к. изменения не отобразится в master ветке проекта. Чтобы такого не произошло и создан Pull request.
Pull request — это обращение к владельцам проекта с предложением внести в главную ветку ваши изменения.
На этом небольшое введение походит к концу. Не мучайтесь с допотопной системой версий, переходите на GitHub. Спасибо за внимание.
