Когда мы пишем какие-либо документы - письма, отчеты, доклады – мы создаем файлы. Очень часто мы вносим изменения в наши документы, редактируем, улучшаем, сокращаем или наоборот расширяем. Иногда нам необходимо сохранять различные версии документа, например, полный или сокращенный доклад. В таком случае мы обычно создаем копии файлов с разным содержанием. А иногда, после внесения изменений, документ становится таким ужасным, что очень хочется вернуть предыдущую версию и хорошо, если мы сделали копию до внесения правок.
Всем, кто много пишет различных текстов знакома ситуация с кучей папок и разложенных в них различных версий документов. Со временем забывается, где и что лежит, файлы теряются, поиск затрудняется.
Когда мы пишем программный код, ситуация намного, намного хуже. Например, незначительные изменения в дизайне или функционале сайта, могут повлечь за собой правки в нескольких файлах. Более того, часто приходится изменять изменения, отменять изменения, добавлять новые файлы и т.д. и т.п. Также очень важно видеть, что именно, где и когда было изменено в программном коде. Попытка решить проблему методом создания множества папок с различными версиями кода (версиями версий, новыми версиями, старыми версиями, версиями с датой, временем, местом и т.д.) обречена на провал.
Для облечения работы с изменяющейся информацией были придуманы системы контроля версия, которые позволяли хранить несколько версий одного и того же документа, при необходимости возвращаться к более ранним версиям, определять, кто и когда сделал то или иное изменение, и многое другое.
Такие системы наиболее широко используются при разработке программного обеспечения для хранения исходных кодов разрабатываемой программы. GIT одна из них.
Проект GIT был создан Линусом Торвальдсом для управления разработкой ядра Linux, первая версия выпущена 7 апреля 2005 года. На сегодняшний день его поддерживает Джунио Хамано.
Среди проектов, использующих Git — ядро Linux, Swift, Android, Drupal, Cairo, GNU Core Utilities, Mesa, Wine, Chromium, Compiz Fusion, FlightGear, jQuery, PHP, NASM, MediaWiki, DokuWiki, Qt, ряд дистрибутивов Linux.
Название GIT дано системе ее автором. Торвальдс так саркастически отозвался о выбранном им названии git (что на английском сленге означает «мерзавец»): I'm an egotistical bastard, so I name all my projects after myself. First Linux, now git. (Я эгоистичный ублюдок, и поэтому называю все свои проекты в честь себя. Сначала Linux, теперь git).
Напомню, что разработка кода ядра Linux была начата финским студентом Линусом Торвальдсом в 1991 году, на его имя зарегистрирована торговая марка «Linux».
Итак, Git (произносится «гит»[10]) — распределённая система управления версиями. Она спроектирована как набор программ, специально разработанных с учётом их использования в сценариях. Git поддерживает быстрое разделение и слияние версий, включает инструменты для визуализации и навигации по нелинейной истории разработки. (Wikipedia)
При использовании GIT все файлы проекта хранятся, как правило, на внешнем относительно компьютера разработчика, ресурсе (github, локальное хранилище файлов и т.д.).
Перед началом работы разработчик извлекает на свой локальный комп рабочую копию проекта или той его части, с которой предстоит работать. Это действие выполняется с помощью команды извлечения версии (обычно checkout или clone). Разработчик задаёт версию, которая должна быть скопирована, по умолчанию обычно копируется последняя (или выбранная администратором в качестве основной) версия.
Таким образом, на внешнем хранилище всегда есть рабочая версия последнего состояния файловой системы. И если вы утратите собственную копию, то всегда можете восстановить ее с сервера. С другой стороны, если упадет сервер, на локальном компьютере всегда будет рабочая копия системы, из которой можно будет восстановить информацию на сервере.
В этом и есть основное преимущество распределенной системы контроля версий.
В системах контроля версий может одновременно работать множество разработчиков. В распределенных системах каждый разработчик скачивает проект к себе на локальную машину.
Место хранения файлов в GIT называется репозиторием. Git хранит данные как слепки состояний проекта во времени. Перед сохранением любого файла Git вычисляет контрольную сумму, и она становится индексом этого файла. Поэтому невозможно изменить содержимое файла или каталога так, чтобы Git не узнал об этом. Эта функциональность встроена в сам фундамент Git'а и является важной составляющей его философии.
Скачав файлы из «глобального» репозитория, разработчик сразу же создает аналогичный локальный репозиторий на своем компьютере. Для этого у него должна быть установлена программа GIT. (GIT входит в состав OpenServer, может быть также установлен отдельно под Windows)
Затем разработчик создает копию оригинального репозитория – ветку, в которой и ведет свою работу. На локальной машине всегда есть минимум 2 ветки – оригинальная и рабочая.
После окончания работы проводится проверка файлов и фиксация выполненных изменений. В случае успешного решения задачи рабочую ветку можно слить с оригинальной веткой и удалить. Затем локальные файлы выгружаются обратно в глобальный репозиторий.
Таковы основные этапы работы GIT. Рассмотрим пошаговую схему операций.
- Клонирование оригинального кода в локальную папку – git clone адрес-git-репозитория. Или обновление файлов из глобального репозитория – git pull адрес-репозитория имя ветки.
- Создание дублирующей рабочей ветки – git branch staging
- Переключение на рабочую ветку – git checkout staging
- Процесс разработки … Завершение процесса
- Анализ состояния локального репозитория – git status
- Добавление измененных и созданных файлов – git add .
7.Фиксация изменений – git commit –m “Текстовый комментарий”. (фиксации часто называют коммитами)
- Отправка файлов рабочей ветки на сервер – git push адрес-репозитория
- Можно также выполнить слияние рабочей ветки staging и оригинальной master на локальном компьютере – git checkout master, git merge staging. При таком порядке выполнения операций ветка staging вольется в ветку master. Master изменится, staging останется неизменной.