Что такое Git: объясняем на схемах
Команды разработчиков пользуются системой контроля версий. Чаще всего это Git. Разбираемся, что это значит, зачем нужно и как устроено.
Git — это система для управления версиями исходного кода программ. В статье мы познакомимся с её основными возможностями, покажем отличие от GitHub и объясним, зачем Git новичку. Ещё вы узнаете, с чего начать обучение и почему не стоит тратить время на альтернативные программы.
Git — это система коммитов
Представьте ситуацию: геймер доходит до финала, проигрывает и возвращается к началу уровня — попадает в ближайшую контрольную точку игры, где разработчики разрешили сохраниться. Если мы уберём контрольные точки, после каждого проигрыша придётся начинать игру заново.
В программировании за сохранение кода в контрольных точках отвечает система контроля версий — специальная технология, которую можно подключить к любому проекту. Система контроля версий страхует от ошибок и возвращает код в то состояние, когда всё работало.
Автор статей о программировании. Изучает Python, разбирает сложные термины и объясняет их на пальцах новичкам. Если что-то непонятно — возможно, вы ещё не прочли его следующую публикацию.
Git — это комплекс связанных веток
Коммиты располагаются на master-ветке — основной версии проекта, которая после завершения работы превратится в продукт.
Система контроля версий позволяет создавать ответвления от master-ветки и экспериментировать с проектом, не мешая другим участника команды.
Возьмём предыдущую схему, где мы обнаружили ошибку и откатились на один коммит назад. Чтобы поправить код, создадим несколько дополнительных веток и в каждой протестируем разные варианты решения проблемы. Когда решение найдено, ветку с правильным кодом переносим в master-ветку и сохраняем коммит. Лишние ветки оставляем или удаляем, поскольку они не влияют на проект и скрыты от других разработчиков — это ваш личный черновик.
Git — это инструмент совместного создания кода
Часто бывает так: разработчики отделяются от master-ветки и работают над частью проекта самостоятельно — например, чтобы протестировать дополнительные функции. Но не могут продолжить, пока кто-то из команды не допишет код.
Система контроля версий позволяет не ждать обновления master-ветки и разрешает всем участникам команды свободно перемещаться между ветками других разработчиков для копирования нужных фрагментов кода.
Бывают и обратные ситуации, когда несколько разработчиков одновременно дописывают код, заливают его в master-ветку и сталкиваются с конфликтом — один файл получает несколько несогласованных изменений. В этом случае Git попробует автоматически исправить ошибки. Если не получится, разработчики это увидят и смогут поправить код вручную.
Git — это распределённая система версий
Системы контроля версий бывают локальными, централизованными или распределёнными.
Из-за удобства и гибкости распределённая система версий Git считается современным форматом. Это стандарт для большинства ИТ-команд.
Git — это не GitHub
Git — это программа, которую нужно установить и подключить к проекту для управления системой контроля версий. GitHub — это сайт-хранилище для историй версий проектов: вы подключаете Git, регистрируетесь на GitHub, создаёте онлайн-репозиторий и переносите файлы с Git на GitHub.
Git — это самая популярная система контроля версий, а GitHub — онлайн-хранилище кода. Git и GitHub настроены на взаимодействие и поэтому часто используются как единый механизм работы с проектом.
Если нужно, Git можно заменить альтернативной программой контроля версий, а GitHub — другим онлайн-хранилищем кода. Большинству работодателей это не нужно, поскольку знакомство с другими сервисами отнимает время и неудобно многим разработчикам.
Зачем новичку учить Git
Git используется в большинстве компаний, где над проектом работает хотя бы два разработчика:
Это общая схема того, как проходит командная работа в проекте. В ней не учтены правила использования Git, которые каждая команда пишет под себя. Например, у каждой команды свой порядок проверки кода и свои критерии его готовности для добавления в master-ветку.
Знание Git и знание правил использования Git в команде — это два разных навыка, которые можно сравнить с умением ездить на автомобиле и знанием правил дорожного движения. Если умеете управлять автомобилем — вам проще сконцентрироваться и быстро выучить правила. С Git аналогичная ситуация: если вы умеете управлять системой контроля версий, то можете сразу влиться в проект, не отвлекаться на второстепенные вещи и сосредоточиться на качестве кода.
С чего начать: 3 шага, чтобы освоить Git
1. Посмотрите наш вебинар по основам работы с Git:
Что такое Git и для чего он используется
Рассказываю про Git – популярнейшую систему контроля версий для разработчиков.
Что такое Git?
Git – это три сервиса в одном. Целый комплекс программных решений, используемых в различных сферах деятельности для отслеживания итераций разрабатываемого продукта.
Чаще всего Git используется в разработке приложений и сайтов, но он также находит применение и в других сферах, например в переводах книг.
Объяснить в двух словах всю систему почти нереально, потому что Git включает в себя настолько разношерстные функции и возможности, что подогнать общую идею под один с ходу понятный термин не представляется возможным. Поэтому начнем с базового определения и постепенно перейдем к конкретным функциям.
Система контроля
Под системой контроля в контексте Git подразумевается программный механизм для работы с контентом. В «работу» также входит хранение, передача данных, отслеживание изменений и прочие аспекты.
Система контроля версий
Как я уже отмечал выше, обычно Git используют для работы с программным кодом. Кодеры ведут разработку своих продуктов, используя систему контроля версий, чтобы иметь полный контроль над своим детищем, над каждой его версией и вариацией.
То есть в любой момент времени можно вернуться в прошлое и восстановить предыдущую версию программы, если новый релиз все поломал. Или когда срочно нужно посмотреть, как выглядел код до рефакторинга.
И это касается не только кода. Переводы больших книг, дизайнерские работы, рисунки и прочее. Правилам работы в системе контроля версий можно подчинить почти любой продукт, и везде от этого будет только польза.
Распределенная система контроля версий
Также Git позволяет вести параллельную разработку, когда несколько программистов одновременно вносят изменения в одно приложение или сайт, но при этом не мешают друг другу и спокойно дополняют продукт, не вызывая сбоев в работе сервиса/сайта/приложения, которое использует их клиент.
Для этого используются удаленные файловые хранилища, где лежат различные вариации кода. Например:
основное приложение со всеми нужными функциями,
его версия с новым дизайном,
новая версия с дополнительными возможностями.
И пока основное приложение остается нетронутым, две его вариации активно развиваются, пока не станут частью основы. Впрочем, этот аспект Git мы еще разберем более подробно.
Зачем нужен Git?
Затем, чтобы не случился апокалипсис в мире разработки (и не только, но мы будем оперировать именно областью IT). Сейчас трудно представить себе мало-мальски крупное приложение, над которым работал бы один человек. За проектом всегда стоит целая команда создателей. И чтобы им всем было комфортно работать вместе, нужна распределенная система контроля версий. Это гарантия отсутствия конфликтов в коде и возможность вести разработку нескольких функций ПО, не соприкасаясь друг с другом и общим кодом.
Более того, в разработке часто меняются требования к проекту, видение заказчика и стандарты дизайна. Поэтому полный контроль над всеми итерациями приложения позволяет легко «откатывать» любые изменения и вносить поверх них новые.
Подробнее о внутреннем строении Git
Репозитории
Репозиторий (репо, реп) – это хранилище файлов проекта. То есть все компоненты, относящиеся к одному приложению (код, изображения, конфигурационные файлы, стили, скрипты и т.п.). С ним как раз и работают люди, ведущие совместную работу над одним продуктом.
Коммиты, пуши и стейджинг
Коммит – это единица контента, хранящая в себе информацию о том, какие компоненты репозитория были изменены на текущий момент времени.
Стейджинг-зона – это временное пристанище измененных файлов. Отправляясь в стейджинг-зону (git add), они помечаются как «в разработке», но при этом из них все еще можно выбрать готовые файлы, чтобы непосредственно их закоммитить. Файлы хранятся в стейджинг-зоне (git add) до тех пор, пока пользователь не сделает коммит и не запушит (git push) изменения на сервер, то есть не выгрузит с локального репозитория в удаленный.
Удаленные репозитории (GitHub, GitLab и т.п.)
Большинство разработчиков хранят репозитории не на локальных машинах, а в хранилищах наподобие GitHub, BitBucket, GitLab и в их аналогах. Это специализированные веб-ресурсы, поддерживающие все функциональные особенности git и позволяющие работать десяткам разработчиков над одним проектом параллельно, используя единое пространство для хранения всех файлов, их версий и прочих компонентов приложения или сайта.
Коммиты остаются в локальном репо, но с помощью команды push можно отправить их в GitHub. А при помощи команды pull можно вытащить их в локальный реп, чтобы иметь под рукой самую новую версию проекта для дальнейшей разработки новых функций.
Ветви и мерджинг
Две функции, вокруг которых строится параллельная разработка.
Ветви (branches) – это разные состояния одной программы. Например, есть ветка master (иногда ее называют main) – в ней обычно хранится приложение с полным набором функций и дизайном, готовое к деплою (то есть публикации в App Store или загрузке на сервер). Есть ветка develop, в которой программисты корпят над нововведениями. Веток может быть неограниченное количество, хоть по одной для каждой функции.
С помощью ветвей можно избежать изменений в программе до того, как новшества будут протестированы. А еще это помогает вносить срочные изменения в main-ветку, не добавляя при этом в программу недоделанные функции или изменения в дизайне.
Мерджинг (merging) – это процесс объединения одной ветки с другой. Чаще всего – ветки develop с веткой main.
Пул-реквесты
Pull Request – это запрос на проверку и одобрение кода. Когда один из программистов заканчивает свою работу, он отправляет PR своим коллегам. Те проводят аудит кода и выносят вердикт, публикуется этот код или нет.
При этом сам пул-реквест является не просто оповещением о готовности куска кода – это целая система взаимодействия и обсуждения. Один PR может превратиться в десятки комментариев и правок кода. После «обработки» PR превращается в мердж.
Разработчики также стали использовать функцию Pull Request Preview, позволяющую подключить к процессу проверки кода дизайнеров, начальство и заказчиков.
С чего начать работу в Git?
Скачиваем git последней версии с официального сайта. Затем создаем директорию для репозитория и переходим в нее с помощью команды cd.
Создаем новый репо:
Теперь можно работать с git. Вот список основных команд:
На этом все. Вас можно поздравить – теперь вы знаете, что такое git и как работать с системой контроля версий.
О системах контроля версий
Всем привет! Уже на следующей неделе в OTUS стартует «Супер-практикум по использованию и настройке GIT». Этому я и решил посвятить сегодняшнюю публикацию.
Введение
Системы контроля версий
Система контроля версий является прежде всего инструментам, а инструмент призван решать некоторый класс задач. Итак, система контроля версий – это система, записывающая изменения
в файл или набор файлов в течение времени и позволяющая вернуться позже к определенной версии. Мы хотим гибко управлять некоторым набором файлом, откатываться до определенных версий в случае необходимости. Можно отменить те или иные изменения файла, откатить его удаление, посмотреть кто что-то поменял. Как правило системы контроля версий применяются для хранения исходного кода, но это необязательно. Они могут применяться для хранения файлов совершенно любого типа.
Как хранить различные версии файлов? Люди пришли к такому инструменту как системы контроля версий не сразу, да и они сами бывают очень разные. Предложенную задачу можно решить с применением старого доброго copy-paste, локальных, централизованных или распределенных систем контроля версий.
Copy-paste
Известный метод при применении к данной задаче может выглядеть следующим образом: будем называть файлы по шаблону filename_
Данный способ является очень простым, но он подвержен различным ошибкам: можно случайно изменить не тот файл, можно скопировать не из той директории (ведь именно так переносятся файлы в этой модели).
Локальная система контроля версий
Следующим шагом в развитии систем контроля версий было создание локальных систем контроля версий. Они представляли из себя простейшую базу данных, которая хранит записи обо всех изменениях в файлах.
Одним из примеров таких систем является система контроля версий RCS, которая была разработана в 1985 году (последний патч был написан в 2015 году) и хранит изменений в файлах (патчи), осуществляя контроль версий. Набор этих изменений позволяет восстановить любое состояние файла. RCS поставляется с Linux’ом.
Локальная система контроля версий хорошо решает поставленную перед ней задачу, однако ее проблемой является основное свойство — локальность. Она совершенно не преднезначена для коллективного использования.
Централизованная система контроля версий
Централизованная система контроля версий предназначена для решения основной проблемы локальной системы контроля версий.
Для организации такой системы контроля версий используется единственный сервер, который содержит все версии файлов. Клиенты, обращаясь к этому серверу, получают из этого централизованного хранилища. Применение централизованных систем контроля версий на протяжении многих лет являлась стандартом. К ним относятся CVS, Subversion, Perforce.
Такими системами легко управлять из-за наличия единственного сервера. Но при этом наличие централизованного сервера приводит к возникновению единой точки отказа в виде этого самого сервера. В случае отключения этого сервера разработчики не смогут выкачивать файлы. Самым худшим сценарием является физическое уничтожение сервера (или вылет жесткого диска), он приводит к потерю кодовой базы.
Несмотря на то, что мода на SVN прошла, иногда наблюдается обратный ход — переход от Git’а к SVN’у. Дело в том, что SVN позволяет осуществлять селективный чекаут, который подразумевает выкачку лишь некоторых файлов с сервера. Такой подход приобретает популярность при использовании монорепозиториях, о которых можно будет поговорить позже.
Распределенная система контроля версий
Для устранения единой точки отказа используются распределенные системы контроля версий. Они подразумевают, что клиент выкачает себе весь репозиторий целиком заместо выкачки конкретных интересующих клиента файлов. Если умрет любая копия репозитория, то это не приведет к потере кодовой базы, поскольку она может быть восстановлена с компьютера любого разработчика. Каждая копия является полным бэкапом данных.
Все копии являются равноправным и могут синхронизироваться между собой. Подобный подход очень напоминает (да и является) репликацией вида master-master.
К данному виду систем контроля версий относятся Mercurial, Bazaar, Darcs и Git. Последняя система контроля версий и будет рассмотрена нами далее более детально.
История Git
В 2005 году компания, разрабатывающая систему контроля версий BitKeeper, порвала отношения с сообществом разработчиков ядра Linux. После этого сообщество приняло решение о разработке своей собственной системы контроля версий. Основными ценностями новой системы стали: полная децентрализация, скорость, простая архитектура, хорошая поддержка нелинейной разработки.
Заключение
Мы рассмотрели способы организации систем контроля версий, обсудили варианты решения поставленных перед этими системами задач, поговорили о преимуществах и недостатках каждого из них, познакомились с историей системы контроля версий Git.
Что такое система контроля версий и как ей пользоваться
В арсенале веб-разработчика много полезных инструментов, которые позволяют автоматизировать решение разных задач. Без них время работы сильно увеличивается. А продуктивность падает, потому что приходится вручную делать то, что можно решить с помощью десктопных программ или браузерных расширений.
В статье поговорим о системе контроля версий. Разберёмся, зачем она нужна, как пользоваться инструментом и расскажем о популярных ошибках, которые допускают новички и опытные программисты.
Что такое система контроля версий
Система контроля версий — программное обеспечение, которое обеспечивает командную работу в рамках одного или нескольких проектов. Команда разработчиков взаимодействует с консольным или браузерным инструментом для выгрузки кода на сервер, скачивания его на рабочий компьютер и изменения структуры.
Новичкам обычно сложно вникнуть в технические подробности работы системы контроля версий, поэтому мы постараемся объяснить суть простым языком. Не старайтесь сразу погружаться в термины, пользы от этого будет мало.
Представьте, что играете в компьютерную игру. По мере прохождения миссий происходит сохранение контрольных точек. Даже если выключить компьютер и зайти в приложение через несколько дней или месяцев, прогресс не потеряется. В любой момент можно выбрать контрольную точку и пройти миссию заново.
Система контроля версий работает по аналогичной схеме. Она хранит все версии проекта и обеспечивает к ним доступ. Любой член команды может взаимодействовать с основной «веткой» проекта или создавать новые.
Самой популярной системой контроля версий является Git, поэтому мы не будем подробно останавливаться на альтернативных решениях и расскажем об этом инструменте.
Собрали основные понятия, которые будут полезны всем, кто захочет освоить работу в Git:
Система контроля версий — полезный инструмент, который нужен не только программистам, работающим в команде. Он пригодится и самостоятельным разработчикам для удобного хранения данных проекта. Если что-то пойдёт не так, в любой момент можно вернуться к контрольной точке и начать заново.
Зачем она нужна
Мы уже частично ответили на этот вопрос, но чтобы новички лучше поняли принцип работы, остановимся на нём ещё раз. Если представить работу над проектом в виде прохождения игры, то контрольные точки — промежуточные версии проекта.
Допустим, программист в одиночку работает над плагином для WordPress. Заказчик добавил в техническое задание обязательное условие — использование Git или аналогов. У него большие планы по разработке продукта, поэтому он хочет, чтобы данные находились в свободном доступе.
Программист создаёт репозиторий и начинает работать над плагином. В основной ветке у него хранится первая рабочая версия продукта. После каждого изменения разработчик добавляет новый коммит, а для внедрения масштабных изменений создаёт параллельные ветки.
Дело близится к релизу, но заказчик внезапно обнаруживает серьёзный баг, который нужно срочно исправить. Разработчик возвращается к контрольной точке (коммиту), в которой он допустил ошибку, исправляет её и обновляет основную ветку.
Теперь представьте, что разработка плагина велась на компьютере программиста. Он не использовал систему контроля версий и не хранил промежуточные копии плагина. Ему придётся либо переписывать проект почти с нуля, либо сильно постараться, чтобы исправить баг без изменения основной логики.
Если над сайтом, плагином или сервисом работает команда разработчиков, без системы контроля версий не обойтись. Каждый из них отделится от master-ветки и будет работать над своими задачами. После завершения работы, коллеги проведут кодревью и проект можно собрать воедино.
Git не только позволяет сохранять контрольные точки проекта, но и помогает устранять конфликты. Часто бывает так, что программисты одновременно работают над одной функцией и заливают изменения в репозиторий. В этом случае система обнаруживает конфликт и пытается исправить его автоматически.
Если Git не решит проблему самостоятельно, программисты увидят её и смогут устранить вручную. Окончательное решение всегда остаётся за разработчиком. Он контролирует процесс и решает, как будет происходить дальнейшая работа.
Какие задачи решает система контроля версий:
Git или другая система контроля версий также важна в работе программиста, как и сохранение бэкапов. В любой момент могут понадобиться исходники. И если их не будет, появятся дополнительные проблемы.
Как пользоваться системой контроля версий
Уже давно появился стереотип, что программисты очень любят работать с консолью. Новички представляют, что опытные разработчики вводят 20 команд в минуту и не используют веб-версии с user-friendly интерфейсами.
Git в стандартном варианте устанавливается на компьютер и представляет собой командную строку с минималистичным интерфейсом. Разработчики обычно разделяются на два лагеря: одни пользуются консольной версией, а вторые предпочитают вариант с графической оболочкой.
Если не хотите осваивать консоль и тратите много времени на ввод простых команд, лучше выбрать GitHub. Это крупнейший веб-сервис, на котором размещены тысячи проектов для совместной разработки. Платформа основана на системе контроля версий Git и обеспечивает удобную командную работу.
Любой пользователь может зарегистрироваться на сайте GitHub, чтобы создавать репозитории для своих проектов. Платформа отлично подходит для новичков и даёт полезный опыт. В системе много проектов с открытым исходным кодом, которые можно дорабатывать по своему усмотрению.
По данным GitHub в системе 56 млн разработчиков, больше 100 млн репозиториев и 3 млн организаций. Клиенты, которые обращаются к программистам за разработкой сайта, сервиса или приложения часто добавляют в список требований использование GitHub.
Git и GitHub не получится освоить за несколько часов, если раньше не было опыта работы с системами контроля версий. Новичкам не надо пытаться сразу выучить все термины. Лучше разобраться с основными понятиями, изучить несколько полезных статей и протестировать Git самостоятельно.
Популярные ошибки при работе с Git
Собрали распространённые ошибки, которые мешают начинающим разработчикам полностью использовать возможности системы контроля версий и создают дополнительные проблемы. Некоторые ошибки актуальны и для опытных программистов:
Система контроля версий — must have инструмент для разработчиков с разным опытом. Новичкам лучше сразу освоить его, чтобы использовать для своих проектов и получить дополнительное преимущество перед конкурентами, которые не знают Git или аналоги.