Основы Git. Как работает Git?
Git — распределённая система контроля версий, позволяющая сохранять изменения, внесённые в файлы, которые хранятся в репозитории. Сами изменения сохраняются в виде снимков, называемых коммитами. Они могут размещаться на разных серверах, поэтому вы всегда восстановите код в случае сбоя, а также без проблем откатитесь до любого предыдущего состояния. Кроме того, значительно облегчается взаимодействие с другими разработчиками: несколько человек могут работать над одним репозиторием одновременно, сохраняя свои изменения.
Git имеет множество плюсов, поэтому считается незаменимым инструментом для всех, кто работает в сфере разработки ПО. В этой статье мы рассмотрим, когда используется Git, изучим наиболее полезные Git-команды. Если Git вам уже знаком, вы сможете освежить свои знания.
Как работать с Git?
В Git имеется много команд, поэтому разобьём их по теме и причине использования. Но начнём с того, что рассмотрим работу Git на локальной машине, ведь большая часть операций происходит именно там. После этого перейдём к многопользовательскому формату.
Что такое Git?
Вообще, с Git можно работать и через графический интерфейс (например, GitHub Desktop), и через командную строку. Командную строку изучить необходимо хотя бы потому, что она предоставляет больше возможностей, чем некоторые инструменты с интерфейсом.
Обычно, команды Git имеют следующий вид:
В качестве аргумента может быть путь к файлу. Также у команд бывают опции, обозначаемые — либо — . Они обеспечивают более детальную настройку действия команды. В нашем материале команды будут представлены в общем виде, а значит всё, что будет в <> , вы можете менять на собственные значения.
Кстати, если возникают затруднения с использованием той либо иной команды, рекомендуется открыть руководство посредством git help . Если просто нужно напоминание, применяйте git -h либо git —help (в Git -h и —help имеют одинаковое значение).
Установка Git
Если вы пользуетесь Windows, качайте Git отсюда. Что касается macOS, то здесь Git поставляется как часть инструмента командной строки XCode. Наличие Git можно проверить, открыв терминал и набрав git —version . Для Linux используйте команду sudo apt install git-all либо sudo dnf install git-all .
Настраиваем конфигурационный файл
Сразу после установки Git нужно настроить имя пользователя и email, ведь они используются для идентификации. Данные настройки будут сохранены в конфигурационном файле.
Вы можете отредактировать файл .gitconfig напрямую с помощью редактора или, используя команду git config —global —edit . Чтобы отредактировать отдельные поля, подойдёт git config —global — здесь нас интересуют поля user.email и user.name.
Кроме того, есть возможность настройки текстового редактора для написания сообщений коммитов — это поле core.editor. По умолчанию применяется системный редактор. Поле commit.template служит для указания шаблона, который будет задействоваться при каждом коммите.
Что такое GIT простым языком? Как работает, основные команды GIT
Есть и много других полей, но самое полезное — alias (привязывает команду к псевдониму). К примеру, git config —global alias.st «status -s» позволит использовать git st вместо git status –s.
А git config —list выведет все поля с их значениями из конфигурационного файла.
Создание Git-репозитория
Чтобы инициализировать новый репозиторий .git используют команду git init . Если хотите скопировать уже существующий репозиторий — git clone .
История коммитов в Git
Git хранит имеющиеся данные в виде набора «снимков», называемых коммитами. Коммиты хранят состояние файловой системы в конкретный момент времени, а также имеют указатель на предыдущие коммиты. Каждый коммит содержит уникальный контрольный идентификатор, который используется Git, чтобы ссылаться на этот коммит. Для отслеживания истории Git хранит указатель HEAD, указывающий на 1-й коммит.
Ссылаться можно как через контрольную сумму коммита, так и через его позицию относительно HEAD. К примеру, HEAD~4 будет ссылаться на коммит, находящийся 4-мя коммитами ранее HEAD.
Система файлов в Git
Как просматривать изменения в файловых системах?
Для этого используют команду git status . Она отображает все файлы, которые различаются между 3-мя отделами. Файлы имеют четыре состояния: 1) untracked (неотслеживаемый). Находится в рабочей директории, но его нет ни в HEAD, ни в области подготовленных файлов. Можно сказать, что Git о нём не знает; 2) modified (изменён).
В рабочей директории находится его более новая версия по сравнению с той, которая хранится в HEAD либо в области подготовленных файлов (при этом изменения не находятся в следующем коммите); 3) staged (подготовлен). В области подготовленных файлов и в рабочей директории есть более новая версия, если сравнивать с хранящейся в HEAD, но файл уже готов к коммиту; 4) без изменений. Во всех разделах содержится одна версия файла, то есть в последнем коммите находится актуальная версия.
Чтобы посмотреть не изменённые файлы, а непосредственно изменения, можно использовать: — git diff — для сравнения рабочей директории с областью подготовленных файлов; — git diff —staged — для сравнения области подготовленных файлов с HEAD.
В случае применения аргумента diff покажет изменения лишь для указанных вами папок или файлов, к примеру:
git diff src/
Игнорирование файлов
Иногда нам не надо, чтобы Git отслеживал все файлы в репозитории, ведь в их число могут входить: — файлы с конфиденциальной информацией; — огромные бинарные файлы; — специфичные файлы; — файлы сборок, генерируемые после каждой компиляции.
Для игнорирования предусмотрен файл .gitignore, где отмечаются файлы для игнорирования.
Коммиты
Основой истории версий являются коммиты. Для работы с ними используют git commit — эта команда откроет текстовый редактор для ввода сообщения коммита. Кроме того, она принимает следующие аргументы: • -m — позволяет написать сообщение, не открывая редактор, то есть вместе с командой; • -a — служит для переноса всех отслеживаемых файлов в область подготовленных файлов и включения их в коммит (даёт возможность перед коммитом пропустить git add); • —amend — заменяет последний коммит новым изменённым коммитом. Это бывает полезно, когда вы неправильно наберёте сообщение последнего коммита либо забудете включить в него нужные файлы.
Ряд советов по коммитам: — коммитьте часто; — одно изменение — один коммит, но не коммитьте слишком незначительные изменения (в большом репозитории они могут засорить историю); — комментируя сообщение о коммите, логически дополняйте фразу this commit will ___ и не используйте более 50 символов.
Удалённые серверы
Мы можем хранить, отслеживать и обновлять историю коммитов не только на локальной машине, но и на удалённых репозиториях. По сути, можно говорить об облачных бэкапах нашей истории коммитов.
Для вывода списка удалённых репозиториев нужна команда git remote –v . С её помощью мы не только загружаем копию репозитория, но и отслеживаем удалённый сервер, находящийся по указанному адресу (ему присваивается имя origin).
Другие часто употребляемые команды: • git remote add — добавляется удалённый репозиторий с заданным именем; • git remote remove — удаляется удалённый репозиторий с заданным именем; • git remote rename — переименовывается удалённый репозиторий; • git remote set-url — репозиторию с именем присваивается новый адрес; • git remote show — показывается информация о репозитории.
Следующий список нужен для работы с удалёнными ветками: • git fetch — для получения данных из ветки заданного репозитория; • git pull — сливает данные из ветки; • git push — для отправления изменения в ветку заданного репозитория. Когда локальная ветка отслеживает удалённую, достаточно использовать git push или git pull .
В результате несколько человек могут запрашивать с сервера изменения, выполнять изменения в локальных копиях, а потом отправлять их на удалённый сервер. Всё это позволяет легко взаимодействовать между собой в пределах одного репозитория.
Ветвление в Git
Ключевая особенность Git — ветвление, позволяющее работать над разными версиями проекта. Таким образом, вместо одного перечня с упорядоченными коммитами история может расходиться в некоторых точках, поэтому становится похожей на дерево. И каждая ветвь содержит в Git легковесный указатель HEAD, указывающий на последний коммит в данной ветке.
В результате можно легко создать много веток. Делая это, называйте ветки согласно разрабатываемой функциональности. Ветку по умолчанию называют master.
Что ж, у нас есть HEAD для каждой ветки и общий указатель HEAD. Переключение между ветками предполагает лишь перемещение HEAD в HEAD соответствующей ветки.
Стандартные команды при ветвлении в Git: • git branch — для создания новой ветки с HEAD, указывающим на HEAD. Если аргумент передан не будет, команда выведет список всех имеющихся локальных веток; • git branch -d — для удаления ветки; • git checkout — для переключения на эту ветку. Если хотим создать новую ветку перед переключением, можем передать опцию –b.
И локальный, и удалённый репозиторий могут иметь много веток, поэтому при отслеживании на деле отслеживается удалённая ветка, то есть git clone привязывает ветвь master к ветви origin/master удалённого репозитория.
Парочка команд для привязывания к удалённой ветке: • git branch -u / —текущая ветка привязывается к указанной удалённой ветке; • git checkout —track / — аналогично; • git checkout -b / — создаётся новая локальная ветвь и начинает отслеживать удалённую; • git checkout — создаётся локальная ветвь с таким же именем, как и у удалённой, плюс начинает её отслеживать; • git branch —vv — служит, чтобы показать локальные и отслеживаемые удалённые ветки.
Совмещение веток
Обсудив возможности по переключению, можно поговорить, как ветки совмещать после разработки. Ветку, в которую мы желаем слить изменения, назовём основной, а ветвь, из которой будем сливать, — тематической. Существуют 2 способа внести изменения — перемещение и слияние.
Слияние
Включает в себя создание нового коммита, основанного на общем коммите-предке 2-х ветвей, указывает на оба HEAD. Для осуществления слияния нужно перейти на основную ветки и использовать команду git merge .
Когда обе ветки меняют одну и ту же часть файла, возникает конфликт слияния. В этой ситуации Git не понимает, какую версию файла нужно сохранить. Разрешать конфликт следует вручную. Для просмотра конфликтующих файлов, используйте git status .
Маркеры разрешения конфликта:
>>>>>> test:index.html
В этом блоке надо заменить всё на версию, которую хотите оставить, после чего подготовить файл. Разрешив все конфликты, можно завершать слияние, используя git commit .
Перемещение
Осуществляется вместо совмещения 2-ух веток коммитом слияния. Перемещение заново воспроизводит коммиты тематической ветви в виде набора новых коммитов базовой ветви, что обеспечивает более чистую историю коммитов.
Чтобы выполнить перемещение, используют команду git rebase . Она воспроизводит изменения тематической ветви на основной. При этом HEAD тематической ветви указывает на последний воспроизведённый коммит.
Совет: перемещайте изменения лишь на вашей приватной локальной ветке. Не стоит перемещать коммиты, от которых ещё кто-то зависит.
Если хотите откатить коммит: — git revert — создаёт новый коммит, который отменяет изменения, но сохраняет историю; — git reset — перемещает указатель HEAD, и создаёт более чистую историю, как будто коммита никогда не было. Но это также значит, что вы не сможете вернуться обратно к изменениям, если решите, что отмена была лишней. В общем, чище — не значит лучше!
Источник: otus.ru
Что такое Git?
Git стал мировым стандартом для управления версиями. Так что же именно это?
Git — это распределенная система управления версиями, то есть локальный клон проекта — это полный репозиторий управления версиями. Полнофункциональные локальные репозитории упрощают работу как в автономном, так и в удаленном режиме. Разработчики фиксируют свою работу локально, а затем синхронизируют свою копию репозитория с копией на сервере. Эта парадигма отличается от централизованных систем управления версиями, где клиенты должны синхронизировать код с сервером перед созданием новой версии кода.
Гибкость и популярность Git делают его отличным выбором для любой команды. Многие разработчики и выпускники колледжей уже знают, как использовать Git. Сообщество пользователей Git создало ресурсы для обучения разработчиков и популярности Git упрощает получение помощи при необходимости. Почти каждая среда разработки поддерживает Git и средства командной строки Git, реализованные в каждой основной операционной системе.
Основы Git
При каждом сохранении работы Git создает фиксацию. Фиксация — это моментальный снимок всех файлов в определенный момент времени. Если файл не изменился с одной фиксации на следующую, Git использует ранее сохраненный файл. Эта конструкция отличается от других систем, которые хранят начальную версию файла и сохраняют запись изменений с течением времени.
Фиксации создают ссылки на другие фиксации, формируя граф журнала разработки. Можно вернуть код к предыдущей фиксации, проверить, как файлы изменились с одной фиксации на следующую, и просмотреть сведения о том, где и когда были внесены изменения. Фиксации идентифицируются в Git уникальным криптографическим хэшом содержимого фиксации. Так как все хэшируется, невозможно вносить изменения, терять сведения или повреждены файлы без обнаружения Git.
Ветви
Каждый разработчик сохраняет изменения в собственном локальном репозитории кода. В результате может быть много разных изменений, основанных на одной фиксации. Git предоставляет средства для изоляции изменений и последующего их слияния. Ветви, которые являются упрощенными указателями для выполнения работы, управляют этим разделением. После завершения работы, созданной в ветви, эту ветвь можно снова объединить с основной ветвью команды (или магистралью).
Файлы и фиксации
Файлы в Git находятся в одном из трех состояний: измененных, промежуточных или зафиксированных. При первом изменении файла изменения существуют только в рабочем каталоге. Они еще не являются частью фиксации или истории разработки. Разработчик должен подготовить измененные файлы для включения в фиксацию.
Промежуточная область содержит все изменения, которые необходимо включить в следующую фиксацию. Когда разработчик доволен промежуточными файлами, файлы упаковываются в виде фиксации с сообщением, описывающим изменения. Эта фиксация становится частью истории разработки.
Промежуточное хранение позволяет разработчикам выбирать изменения файлов для сохранения в фиксации, чтобы разбить большие изменения на ряд небольших фиксаций. Уменьшая область фиксаций, проще просмотреть журнал фиксаций, чтобы найти определенные изменения в файле.
Преимущества Git
Преимущества Git много.
Одновременная разработка
Каждый имеет собственную локальную копию кода и может работать одновременно с собственными ветвями. Git работает в автономном режиме, так как почти каждая операция является локальной.
Более быстрые выпуски
Ветви обеспечивают гибкую и одновременную разработку. Основная ветвь содержит стабильный высококачественный код, из которого вы выпускаете. Ветви компонентов содержат выполняемые действия, которые объединяются в главную ветвь после завершения. Отделяя ветвь выпуска от выполняющейся разработки, проще управлять стабильным кодом и отправлять обновления быстрее.
Встроенная интеграция
Благодаря популярности Git интегрируется в большинство инструментов и продуктов. Каждая основная интегрированная среда разработки имеет встроенную поддержку Git, а многие средства поддерживают непрерывную интеграцию, непрерывное развертывание, автоматическое тестирование, отслеживание рабочих элементов, метрики и интеграцию функций создания отчетов с Git. Эта интеграция упрощает повседневный рабочий процесс.
Строго сообщества поддержки
Git является открытым исходным кодом и стал де-факто стандартом для управления версиями. Нет недостатка в средствах и ресурсах, доступных командам для использования. Объем поддержки сообщества для Git по сравнению с другими системами управления версиями упрощает получение помощи при необходимости.
Git работает с любой командой
Использование Git с средством управления исходным кодом повышает производительность команды, поощряя совместную работу, применяя политики, автоматив процессы и повышая видимость и трассировку работы. Команда может урегулировать отдельные средства для управления версиями, отслеживания рабочих элементов, а также непрерывной интеграции и развертывания. Кроме того, они могут выбрать решение, например GitHub или Azure DevOps , которое поддерживает все эти задачи в одном месте.
Запросы на вытягивание
Используйте запросы на вытягивание , чтобы обсудить изменения кода с командой, прежде чем объединить их в главную ветвь. Обсуждения в запросах на вытягивание являются бесценными для обеспечения качества кода и повышения знаний в вашей команде. Такие платформы, как GitHub и Azure DevOps, предлагают широкий интерфейс запроса на вытягивание, где разработчики могут просматривать изменения файлов, оставлять комментарии, проверять фиксации, просматривать сборки и голосовать за утверждение кода.
Политики ветвления
Teams может настроить GitHub и Azure DevOps для обеспечения согласованных рабочих процессов и процессов в команде. Они могут настроить политики ветви , чтобы убедиться, что запросы на вытягивание соответствуют требованиям перед завершением. Политики ветвей защищают важные ветви, предотвращая прямые отправки, требуя рецензентов и обеспечивая очистку сборок.
Источник: learn.microsoft.com
Git — что это простыми словами
Git относится к третьему поколению систем контроля версий (СКВ). Они называются распределенными СКВ, поскольку имеют хранилище данных (репозиторий) не только на сервере, но и локально на тех машинах, которыми пользуются разработчики. От других СКВ Git отличается особым подходом к обработке информации: он не записывает отдельно внесенные правки, а делает подробный снимок проекта в момент сохранения, то есть фиксирует состояние каждого файла, и создает ссылку на эту версию.
Для чего нужен Git
В основном Git применяют при работе с исходным кодом, но его можно использовать для любых файлов на усмотрение пользователя. К помощи Git часто прибегают при переводе книг, когда нужно сопоставить выполненную работу с оригиналом, дизайнеры тоже нередко пользуются его возможностями. Он позволяет анализировать изменения, просматривать их историю, сравнивать разные версии одних и тех же файлов.
Что касается создания приложений и сайтов, то здесь Git — обязательный и незаменимый инструмент. Часто бывает так, что внесенное в код исправление рушит работающие части проекта, и даже после отмены этого исправления ситуация не улучшается. Решение — Git. Он защищает ваш проект от подобных неожиданностей и исключает возможность случайного удаления правок или файлов.
Благодаря уникальному подходу к хранению данных, Git может быстро откатить проект до рабочего состояния при возникновении ошибок. Вам не потребуется выискивать проблемы, которые повлекло за собой добавление изменений, ведь в любой момент можно вернуться к одной из старых версий. Такая система нужна, чтобы люди, участвующие в разработке, могли беспрепятственно «копаться» в коде, не боясь навредить чужим правкам или работе проекта в целом. С помощью Git можно поддерживать рабочую версию и параллельно создавать новые, одной командой сливать их воедино или разделять. Этот инструмент ускоряет процесс разработки и делает его более эффективным.
Что входит в Git
Распределенная система контроля версий подразумевает под собой сразу три сервиса:
- Хранение, обработка и передача данных. Сама возможность работы с «контентом».
- Контроль за всеми вариациями проекта. То, о чем мы говорили выше: в любой момент времени вы можете восстановить предыдущие версии, буквально вернуться в прошлое до «поломки» кода.
- Параллельная разработка. Удаленное файловое хранилище делает доступной одновременную редакцию одних и тех же объектов разными людьми и при этом гарантирует отсутствие конфликтов в коде. Это достигается благодаря тому, что каждый участник проекта хранит свои правки в локальном репозитории на своем устройстве, и они не вступят в силу, пока он не выгрузит их на сервер и не сольет с рабочей версией.
Строение Git
Если при работе над проектом используется Git, все принадлежащие ему файлы проходят через несколько секций хранилища: рабочий каталог (Working directory), область подготовленных файлов или индекс (Staging area) и каталог Git (Git directory).
Последнее — самая важная часть системы, поскольку именно здесь хранятся все объекты и метаданные вашего проекта. Git-каталог — это и есть локальный репозиторий, который был клонирован с сервера. В нем содержится не только код, но и изображения, файлы конфигурации, скрипты, стили — эти и другие компоненты представлены здесь во всех вариациях, когда-либо сохраненных в удаленном репозитории.
Из сжатой базы данных каталога Git извлекается копия определенной версии проекта и помещается на жесткий диск компьютера для внесения изменений. Рабочий каталог или директория представляет собой как раз одну такую копию. Другими словами, в этой секции производятся все действия по редактированию файлов: переписывается код, меняются шрифты, цвета, добавляются новые блоки и функции или удаляются старые и так далее. Файл получает статус «изменен» (modified) и, если нужно, может быть перемещен в индекс — промежуточную зону между двумя каталогами.
В области подготовленных файлов он переходит в статус «индексирован» (staged), что означает готовность объекта к коммиту — отправке в репозиторий, где он станет «зафиксированным» (committed). Файл будет находиться в стейджинг-зоне до тех пор, пока пользователь не сохранит его в локальное хранилище и не отправит на сервер.
Каждую из этих секций можно представить как отдельную миниатюрную файловую систему, которая сообщается и взаимодействует с остальными при помощи определенных команд. Работа в Git строится простым и понятным образом, благодаря чему возрастает и ее эффективность.
Как начать работу в Git
Чтобы включить Git в процесс разработки, для начала его нужно установить на компьютер. Если вы используете операционную систему из семейства Linux или Unix, достаточно произвести установку пакета при помощи пакетного менеджера. Либо вы можете скачать набор утилит последней версии с официального сайта Git, что также актуально для Windows и macOS.
Конфигурационный файл
Первым делом лучше настроить параметры для идентификации: имя пользователя и электронную почту. Для большинства операций они не потребуются, но без них у вас не будет возможности сделать коммит. Настройка производится при помощи утилиты git config. Она позволяет устанавливать и просматривать параметры, контролирующие всю работу Git и его внешний вид.
Они могут храниться в трех файлах: на уровне системы (/etc/gitconfig), на уровне пользователя (~/.gitconfig) и на уровне проекта (.git/config). Для того чтобы данные читались и сохранялись в одном из первых двух файлов, при запуске git config укажите параметр —system или —global соответственно. Если для конкретного проекта вам необходимо установить отдельные имя и email, то в его каталоге выполните команды без указания параметра: git config user.name «значение» и git config user.email «значение». Помните, что значения нижнего уровня перекрывают значения верхнего.
Создание репозитория
Существует два способа создать Git-репозиторий: инициализировать новый или клонировать уже существующий.
В первом случае достаточно создать папку будущего проекта, перейти в нее и ввести команду git init. Репозиторий готов к работе: можете добавлять в него свои файлы. После этого нужно сделать коммит изменений (git commit -m “название версии”). Таким образом, новые файлы будут готовы к отправке в удаленный репозиторий.
Для связи локального и удаленного репозиториев требуется выполнить команду git remote add origin . Теперь Git знает, где находится удаленный сервер (куда отправлять файлы). Для отправки данных в репозиторий используется команда git push.
Чтобы начать использовать Git для имеющегося у вас проекта, сделайте все то же самое, открыв проектный каталог.
Если же вы хотите скопировать репозиторий из удаленного хранилища (например, GitHub), выполните команду git clone .
Заключение
Теперь вы знаете, почему Git является популярнейшей из распределенных систем контроля версий. Мы познакомили вас с принципом его работы и показали, насколько эффективно она организована. Это надежный инструмент для совместной разработки проектов и отслеживания истории их развития.
Источник: eurobyte.ru
Git. Урок 1. Введение. Установка и настройка.
В этом уроке мы с вами познакомимся с мощнейшим инструментом, которым должен владеть каждый уважающий себя разработчик. Встречайте короля систем контроля версий – Git. Расскажем, чем же он так хорош, где применяется, а главное — как его установить и настроить.
Урок: 1
Команды: config
В КОНЦЕ УРОКА ЕСТЬ ВИДЕО
Следующий урок
Урок 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. Домашнее задание
ТЕОРЕТИЧЕСКИЙ БЛОК
1
Что такое системы контроля версий?
Дадим определение:
Система управления версиями (от англ. Version Control System, VCS) — программное обеспечение для облегчения работы с изменяющейся информацией. Система управления версиями позволяет хранить несколько версий одного и того же документа, при необходимости возвращаться к более ранним версиям, определять, кто и когда сделал то или иное изменение, и многое другое.
Такая система фиксирует изменения, что позволяет вам в случае чего откатиться к любой предыдущей версии файла. Кроме отката изменений, система контроля версий позволяет сравнивать версии одного и того же файла, чтобы найти в нем изменения, видеть, кто эти изменения внес, когда это было сделано и что могло вызвать проблему.
Чтобы сформировать у вас интуитивное понимание, приведу пример. Представьте себе, что вы разрабатываете голосового помощника для мобильных устройств. Ваше приложение уже выпущено в Play Market и в AppStore и пользуется успехом. Теперь вам захотелось добавить в него новую функцию: таймер.
Вы пишите код, загружаете обновление в Play Market и AppStore , но внезапно вы узнаете от пользователей, что все сломалось. Теперь, чтобы исправить ошибку, вам нужно пересматривать весь код, чтобы вспомнить, что вы изменяли, и убирать это.
Такой процесс займет очень много сил и времени, а пользователей оставит недовольными. Вам бы очень помогла система контроля версий. Вы бы загрузили в нее файлы с кодом до внесения изменений, а после обнаружения ошибки, откатились бы к ним за считанные секунды. Функция отката изменений позволила бы вам оперативно загрузить в магазины старую версию приложения, которая работает без ошибок.
2
Зачем нужен контроль версий?
Понятно, что проект для команды — это бесценные знания, накопленные за все время его существования, и никому бы не хотелось, чтобы с ними что-то случилось. Система контроля версий защищает эти накопления от человеческого фактора, непредвиденных последствий и разных форс-мажоров.
Обычно, работая в команде, каждый разработчик трудится над какой-то своей частью проекта: создает новые функции, оптимизирует уже существующие, исправляет ошибки в уже написанном коде. Сам проект обычно организован в виде дерева файлов. Контроль версий помогает сотрудникам одновременно работать над проектом, отслеживать, кто какие изменения внес, и избегать при этом различных конфликтов (например, когда два человека изменят один и тот же файл по-разному).
Помимо этого, как уже было сказано выше, любое изменение кода может привести к непредвиденным последствиям и сломать весь проект вообще. Система контроля версий защищает и от этого.
3
Разновидности архитектур VCS
Существует три основных разновидности архитектур систем контроля версий: локальная, централизованная и распределенная. Рассмотрим их все.
3.1. Локальная система контроля версий
Вы спросите: почему нельзя просто сохранять файл под разными именами, а затем открывать нужный? Да, так делать можно, но это вызовет массу проблем. Вы можете забыть, какой файл содержит итоговую версию, можете запутаться в миллионе одинаковых файлов, отличающихся парой строк кода. Вы не сможете быстро сравнить две версии, чтобы посмотреть, какие изменения были внесены.
Для решения этих проблем была придумана локальная система контроля версий. Схематически она представляет из себя следующее:
Схема работы локальной системы контроля версий
Из рисунка видно, что есть несколько версий одного и того же файла. А сам файл сейчас находится в состоянии третьей версии.
Одной из самых популярных локальных систем контроля версий на сегодняшний день (не считая Git) остается система RCS. Она работает по принципу сохранения изменений в ваших файлах. То есть она хранит не целую новую версию, а только указания к изменению первоначального файла. Например, «добавить к предыдущей версии строку import math «. Таким образом, последовательно изменяя файл, система воссоздает любую из его версий.
Подытожим:
Локальные VCS хранятся у вас на компьютере. Пример локальной VCS — RCS — одна из первых систем контроля версий, разработанная в 1985 году.
Составим список преимуществ и недостатков локальных VCS.
Преимущества:
1. Позволяет хранить историю изменения файлов локально, без интернета.
2. Вы независимы от сторонних серверов.
Недостатки:
1. Вы можете потерять все файлы, если с вашем компьютером что-то случится.
2. Вы не можете работать в команде, поскольку репозиторий доступен только вам.
3.2. Централизованная система контроля версий
Как было сказано выше, одна из проблем, с которой вы столкнетесь, работая в команде разработчиков — это то, что вам нужно делиться файлами (и их версиями) с другими разработчиками.
Например, чтобы старший разработчик проверил ваш код на ошибки, перед тем, как дать вам разрешение на внесение изменений в рабочий файл. Для решения этой проблемы была придумана централизованная система контроля версий. Схематически она устроена так:
Схема работы централизованной VCS
Из рисунка видно, что есть один сервер с сохраненными версиями всех файлов, а разработчики обращаются к нему за файлами.
Такими системами были очень популярные в свое время CVS, Subversion и Perforce. Долгое время такой тип системы контроля версий считался стандартом. Такая система довольно удобна с точки зрения руководства компании. Она позволяет им следить, кто и чем занимается в текущий момент, позволяет настроить: кому какие файлы можно редактировать, а кому — нельзя.
Тем не менее, централизованная система контроля версий имеет множество недостатков. Если сервер отключится на несколько часов, то работа целой компании будет парализована: никто не сможет сохранять версии файлов с кодом.
Если будет поврежден жесткий диск сервера, на котором хранятся данные, то восстановить их не удастся (если только не были сделаны копии), и вся работа будет потеряна.
В этом плане такая система мало чем отличается от локальной: если вы храните все данные проекта только на одной машине, вы рискуете потерять все из-за непредвиденного сбоя в работе этой машины.
Кроме того, поскольку вы не храните никаких данных локально, вам нужен бесперебойный высокоскоростной интернет на протяжении целого дня, чтобы скачивать и загружать данные с сервера. Это, конечно, не проблема, но однозначно минус.
Подытожим:
Централизованная VCS хранит все данные на сервере, а сотрудники получают к ним доступ.
Примерами удаленных систем контроля версий являются CVS, Subversion и Perforce.
Преимущества централизованных VCS:
1. Вы можете работать в команде с другими разработчиками.
2. Ваше начальство видит, чем вы занимаетесь.
3. У администратора есть четкий контроль, кто и что может делать. Администрировать центральную VCS намного проще, чем локальные на каждой машине.
Недостатки централизованных VCS:
1. Все данные хранятся только на одном сервере. Если он выключится, то работу всей компании парализует.
2. Если с сервером что-то случится, а копий данных нет, то весь проект может быть потерян.
3. Для работы необходим хороший интернет на протяжении целого дня.
3.3. Распределенная система контроля версий
Распределенная система контроля версий решает все описанные выше проблемы. К этой группе систем относится Git, Mercurial, Bazaar и некоторые другие. На схеме распределенные системы контроля версий выглядят так:
Схема работы распределенной VCS
Особенность этой архитектуры в том, что клиенты не хранят у себя отдельные файлы, они хранят полную копию всех версий проекта. Поэтому, если что-то случится с сервером, работа не остановится, а продолжится, как ни в чем не бывало. Работники будут сохранять версии у себя на компьютере, а как только сервер восстановится, они загрузят все эти версии на него.
Кроме того, почему сервер обязательно должен быть один? Правильный ответ: серверов может быть сколько угодно! Это открывает безграничные возможности для коллаборации разработчиков. Ведь это значит, что если вы делаете какое-нибудь открытое программное обеспечение и используете систему контроля версий, любой человек сможет скопировать данные с вашего сервера на свой, улучшить это ПО, не боясь ошибок (ведь можно откатиться к предыдущей версии), а затем (с вашего согласия) записать улучшенную версию на ваш сервер. И так с миллионами людей по всему миру.
Подытожим
Распределенные VCS — лидер по популярности на сегодняшний день. Примеры таких систем — это Git, Mercurial и Bazaar.
Преимущества распределенных VCS:
1. Работа компании теперь не зависит от работы сервера. Если сервер отключится, то каждый сотрудник продолжит работу с локальной копией репозитория, а после загрузит ее на сервер.
2. Можно работать с несколькими удаленными репозиториями, делиться кодом с другими людьми и коллаборировать целыми компаниями.
ОБЩИЙ ИТОГ
Для закрепления повторим все, что было сказано ранее. Итак, VCS открывает перед вами следующие возможности:
1. Сохранять все изменения в файлах в хронологическом порядке, при этом не путаясь в именах миллионов копий одного и того же файла.
2. Избегать неприятных ошибок в коде, вызванных непредвиденным поведением новых функций.
3. Отслеживать, над какими файлами вы работаете (и работаете ли вообще). Вам это вряд ли пригодится, а вот вашему начальству – очень.
4. Работать параллельно над одним и тем же проектом вместе с командой, не боясь конфликтов, например, одновременного изменения одного и того же файла.
5. Делиться своим кодом. А разработчики со всего мира могут улучшать его и записывать изменения на ваш сервер.
4
Как появился Git?
Git — это самая популярная на сегодня система контроля версий. Это развитый проект с открытым кодом, активно поддерживаемый и совершенствуемый. Как я уже говорил выше, Git устроен по принципу распределенной архитектуры, но поддерживает и локальную работу (в таком случае ваш компьютер будет единственным сервером, где хранятся все версии проекта).
Git был разработан командой Линуса Торвальдса в 2005 году, как open-source аналог уже существующим системам. Но разработка Git не была спонтанным решением. Дело в том, что с самого первого релиза в 1991 году разработка ядра Linux выполнялась по старинке: старая версия архивировалась, а новые патчи от разработчиков становились новой версией.
Но с ростом популярности рос и объем данных, поэтому в 2002 году было принято решение перевести ядро Linux на распределенную систему управления версиями BitKeeper от BitMover Inc . Однако между компаниями произошел разлад и BitMover Inc . отозвали лицензию на бесплатное использование своего ПО.
Этот инцидент и подстегнул Линуса Торвальдса с командой разработчиков создать свою открытую распределенную систему контроля версий. Ребята хотели разработать надежное решение, обладающее высокой скоростью работы и упрощающее командную разработку.
- Скорость
- Простота дизайна
- Поддержка нелинейной разработки (тысячи параллельных веток)
- Полная распределенность
- Возможность эффективной работы с такими большими проектами, как ядро Linux (как по скорости, так и по размеру данных)
Источник: smartiqa.ru
Что такое GIT для веб-разработчика.
Один из инструментов, который должен быть в «арсенале» любого веб-разработчика — это программа Git.
Что же такое Git?
Первое, что нужно понимать, Git — это просто программа, которая устанавливается на ваш компьютер.
Официальный сайт, где вы можете скачать эту программу и установить ее на свой компьютер:
Есть версии для разных операционных систем, выбирайте ваш вариант и устанавливайте git к себе на компьютер.
Здесь нужно понимать такой момент. Git — это консольная программа. У этой программы нет какой-то графической оболочки, где можно поводить курсором мыши, покликать куда-то и.т.д. Для работы с этой программой вам нужно открыть консоль (терминал) вашей операционной системы. Это окно, в которую мы можем вводить команды.
Для чего же нужен Git?
Git — это так называемая система контроля версий. Это такая программа, которая может следить за изменениями в любой папке на вашем компьютере.
Например, мы создали в какой-то папке на компьютере какой-то документ и внесли туда какие-то правки. Мы его сохранили и вышли. Git зафиксировал эти изменения и состояние папки как начальное положение.
Теперь мы добавляем в этот текстовый документ какое-то изображение или текст. Это будет уже следующее состояние этой папки. Git это тоже зафиксировал.
Каждый раз, когда я что-то буду менять в этой папке, git все это может фиксировать и помечать соответствующими метками, каким-то уникальным кодом.
Смысл в том, что мы теперь можем откатиться к каким-то изменениям, если в какой-то момент времени было сделано что-то не то. Мы можем вернуться к этим файлам или изменениям, которые были в определенный момент времени. Это основное назначение программы Git.
Git — это не только веб-разработка. Ей могут пользоваться компьютерные дизайнеры, копирайтеры, которые пишут тексты, в общем, всем, кому нужно контролировать состояние файлов в какой-то папке, можно пользоваться этой программой.
Как правило, этой программой пользуются программисты, т.к. работать с консолью операционной системы более привычно именно им.
Размер папки, которая будет содержать все изменения Git очень мал. В git есть специальный алгоритм, как эти все изменения фиксировать.
Предположим, что вы создали какой-то файл, внесли в него изменения и git сохраняет не полностью целиком весь файл, а сохраняет только то изменение, которое вы сделали, т.е. разницу.
Если вы создали какой-то текстовый файл, а потом внесли в него изменение, в Git будет сохранен не весь текстовый файл, а только тот кусок текста, в который вы вносили изменение.
Ветки — это следующая возможность Git. Мы можем сохранять не только текущее состояние положения дел в нашем проекте, но мы можем создать отдельную ветку, отдельное направление проекта. Так мы можем протестировать эту ветку.
Например, мы создаем сайт и нам нужно добавить на него какую-то возможность. Например, добавить в боковую колонку какой-то виджет. Возможно, что в момент пока мы все это будет добавлять и изменять, на сайте могут появляться какие-то ошибки и.т.д. Мы можем создать отдельную ветку и тестировать эту возможность там.
После того, как все изменения проверены и все работает, мы можем слить эти изменения с основной версией сайта и все будет работать.
Ветки — это просто возможно создать другую версию файлов, которые находятся в папке. Как правило, ветки нужны в крупных проектах.
Следующая возможность Git — это возможность работы с удаленными серверами или репозиториями. Репозиторий — это некое хранилище, в котором храняться наши файлы.
У нас есть удаленный компьютер (сервер), который является репозиторием и на нем есть некая папка и в ней будут храниться файлы нашего проекта. В этой папке на удаленном репозитории настроен Git.
Что же это нам дает?
Главное преимущество в том, что теперь мы не привязаны к какому-то рабочему месту и мы можем работать с этим удаленным компьютером с любого компьютера, который подключен к Интернет.
Вы поработали на домашнем компьютере, закачали эти изменения на удаленный репозиторий, потом вы пришли на работу, скачали эту версию проекта на рабочий компьютер и получили там свежую версию проекта.
Также это дает возможность работы над проектом в команде из нескольких людей. Каждый делает что-то свое, за что он ответственен.
Программа Git — это современный инструмент, который позволяет удобно работать над проектам, возвращаться к различным версиям этого проекта и работать над ним в команде.
Источник: webkyrs.info