Система управления версиями git что это

Эта глава о том, как начать работу с Git. Вначале изучим основы систем контроля версий, затем перейдём к тому, как запустить Git на вашей ОС и окончательно настроить для работы. В конце главы вы уже будете знать, что такое Git и почему им следует пользоваться, а также получите окончательно настроенную для работы систему.

О системе контроля версий

Что такое «система контроля версий» и почему это важно? Система контроля версий — это система, записывающая изменения в файл или набор файлов в течение времени и позволяющая вернуться позже к определённой версии. Для контроля версий файлов в этой книге в качестве примера будет использоваться исходный код программного обеспечения, хотя на самом деле вы можете использовать контроль версий практически для любых типов файлов.

Если вы графический или web-дизайнер и хотите сохранить каждую версию изображения или макета (скорее всего, захотите), система контроля версий (далее СКВ) — как раз то, что нужно. Она позволяет вернуть файлы к состоянию, в котором они были до изменений, вернуть проект к исходному состоянию, увидеть изменения, увидеть, кто последний менял что-то и вызвал проблему, кто поставил задачу и когда и многое другое. Использование СКВ также значит в целом, что, если вы сломали что-то или потеряли файлы, вы спокойно можете всё исправить. В дополнение ко всему вы получите всё это без каких-либо дополнительных усилий.

Локальные системы контроля версий

Многие люди в качестве метода контроля версий применяют копирование файлов в отдельный каталог (возможно даже, каталог с отметкой по времени, если они достаточно сообразительны). Данный подход очень распространён из-за его простоты, однако он невероятно сильно подвержен появлению ошибок. Можно легко забыть в каком каталоге вы находитесь и случайно изменить не тот файл или скопировать не те файлы, которые вы хотели.

Для того, чтобы решить эту проблему, программисты давным-давно разработали локальные СКВ с простой базой данных, которая хранит записи о всех изменениях в файлах, осуществляя тем самым контроль ревизий.

Одной из популярных СКВ была система RCS, которая и сегодня распространяется со многими компьютерами. RCS хранит на диске наборы патчей (различий между файлами) в специальном формате, применяя которые она может воссоздавать состояние каждого файла в заданный момент времени.

Централизованные системы контроля версий

Следующая серьёзная проблема, с которой сталкиваются люди, — это необходимость взаимодействовать с другими разработчиками. Для того, чтобы разобраться с ней, были разработаны централизованные системы контроля версий (ЦСКВ). Такие системы, как CVS, Subversion и Perforce, используют единственный сервер, содержащий все версии файлов, и некоторое количество клиентов, которые получают файлы из этого централизованного хранилища. Применение ЦСКВ являлось стандартом на протяжении многих лет.

Такой подход имеет множество преимуществ, особенно перед локальными СКВ. Например, все разработчики проекта в определённой степени знают, чем занимается каждый из них. Администраторы имеют полный контроль над тем, кто и что может делать, и гораздо проще администрировать ЦСКВ, чем оперировать локальными базами данных на каждом клиенте.

Несмотря на это, данный подход тоже имеет серьёзные минусы. Самый очевидный минус — это единая точка отказа, представленная централизованным сервером. Если этот сервер выйдет из строя на час, то в течение этого времени никто не сможет использовать контроль версий для сохранения изменений, над которыми работает, а также никто не сможет обмениваться этими изменениями с другими разработчиками. Если жёсткий диск, на котором хранится центральная БД, повреждён, а своевременные бэкапы отсутствуют, вы потеряете всё — всю историю проекта, не считая единичных снимков репозитория, которые сохранились на локальных машинах разработчиков. Локальные СКВ страдают от той же самой проблемы: когда вся история проекта хранится в одном месте, вы рискуете потерять всё.

Распределённые системы контроля версий

Здесь в игру вступают распределённые системы контроля версий (РСКВ). В РСКВ (таких как Git, Mercurial, Bazaar или Darcs) клиенты не просто скачивают снимок всех файлов (состояние файлов на определённый момент времени) — они полностью копируют репозиторий. В этом случае, если один из серверов, через который разработчики обменивались данными, умрёт, любой клиентский репозиторий может быть скопирован на другой сервер для продолжения работы. Каждая копия репозитория является полным бэкапом всех данных.

Более того, многие РСКВ могут одновременно взаимодействовать с несколькими удалёнными репозиториями, благодаря этому вы можете работать с различными группами людей, применяя различные подходы единовременно в рамках одного проекта. Это позволяет применять сразу несколько подходов в разработке, например, иерархические модели, что совершенно невозможно в централизованных системах.

Источник

Что такое Git?

Git — абсолютный лидер по популярности среди современных систем управления версиями. Это развитый проект с активной поддержкой и открытым исходным кодом. Система Git была изначально разработана в 2005 году Линусом Торвальдсом — создателем ядра операционной системы Linux. Git применяется для управления версиями в рамках колоссального количества проектов по разработке ПО, как коммерческих, так и с открытым исходным кодом. Система используется множеством профессиональных разработчиков программного обеспечения. Она превосходно работает под управлением различных операционных систем и может применяться со множеством интегрированных сред разработки (IDE).

Git — система управления версиями с распределенной архитектурой. В отличие от некогда популярных систем вроде CVS и Subversion (SVN), где полная история версий проекта доступна лишь в одном месте, в Git каждая рабочая копия кода сама по себе является репозиторием. Это позволяет всем разработчикам хранить историю изменений в полном объеме.

Разработка в Git ориентирована на обеспечение высокой производительности, безопасности и гибкости распределенной системы.

Производительность

Git показывает очень высокую производительность в сравнении со множеством альтернатив. Это возможно благодаря оптимизации процедур фиксации коммитов, создания веток, слияния и сравнения предыдущих версий. Алгоритмы Git разработаны с учетом глубокого знания атрибутов, характерных для реальных деревьев файлов исходного кода, а также типичной динамики их изменений и последовательностей доступа.

Некоторые системы управления версиями руководствуются именами файлов при работе с деревом файлов и ведении истории версий. Вместо обработки названий система Git анализирует содержимое. Это важно, поскольку файлы исходного кода часто переименовывают, разделяют и меняют местами. Объектные файлы репозитория Git формируются с помощью дельта‑кодирования (фиксации отличий содержимого) и компрессии. Кроме того, такие файлы в чистом виде хранят объекты с содержимым каталога и метаданными версий.

Вместе с тем распределенная архитектура системы сама по себе обеспечивает существенный прирост производительности.

Рассмотрим пример: разработчик Элис меняет исходный код. Она добавляет функцию для будущей версии 2.0, после чего делает коммит и сопровождает изменения описанием. Затем она разрабатывает другую функцию и делает еще один коммит. Разумеется, эти изменения сохраняются в истории в виде отдельных рабочих элементов. Затем Элис переключается на ветку, соответствующую версии 1.3 того же ПО — так она сможет исправить баг, затрагивающий эту конкретную версию. Это нужно, чтобы команда Элис могла выпустить версию 1.3.1 с исправлениями до завершения работы над версией 2.0. Затем Элис вернется к ветке для версии 2.0 и продолжит работу над соответствующими функциями. Все перечисленные действия можно выполнить без доступа к сети, поэтому система Git отличается быстротой и надежностью, даже если работать в самолете. Когда Элис будет готова отправить все внесенные изменения в удаленный репозиторий, ей останется лишь выполнить команду push.

Безопасность

При разработке в Git прежде всего обеспечивается целостность исходного кода под управлением системы. Содержимое файлов, а также объекты репозитория, фиксирующие взаимосвязи между файлами, каталогами, версиями, тегами и коммитами, защищены при помощи криптографически стойкого алгоритма хеширования SHA1. Он защищает код и историю изменений от случайных и злонамеренных модификаций, а также позволяет проследить историю в полном объеме.

Использование Git гарантирует подлинность истории изменений исходного кода.

В некоторых других системах управления версиями отсутствует защита от тайного внесения изменений. Это может стать серьезной угрозой информационной безопасности в любой организации, занимающейся разработкой ПО.

Гибкость

Гибкость — одна из основных характеристик Git. Она проявляется в поддержке различных нелинейных циклов разработки, эффективности использования с малыми и крупными проектами, а также совместимости со многими системами и протоколами.

В отличие от SVN, система Git рассчитана прежде всего на создание веток и использование тегов. Поэтому процедуры с участием веток и тегов (например, объединение и возврат к предыдущей версии) сохраняются в истории изменений. Не все системы управления версиями обладают настолько широкими возможностями отслеживания.

Контроль версий с помощью Git

Git — это лучшее решение для большинства команд разработки ПО. Разумеется, оценку следует проводить с учетом конкретных требований. Мы лишь хотим перечислить основные причины, по которым команды предпочитают использовать Git.

Превосходные характеристики

Функциональность, производительность, безопасность и гибкость Git удовлетворяют требованиям большинства команд и разработчиков. Эти качества системы подробно описаны выше. При сравнении системы с большинством альтернатив многие команды приходят к выводу, что Git обладает значительными преимуществами.

Git — признанный стандарт

Git является самым популярным инструментом своего класса и поэтому привлекателен по ряду причин. В Atlassian управление исходным кодом проектов практически всегда осуществляется в Git.

Великое множество профессиональных разработчиков уже получили опыт использования Git, а выпускники высших учебных заведений зачастую знакомы только с этой системой. В некоторых организациях работникам требуется обучение при переходе на Git с других систем управления версиями, однако многие разработчики (как штатные, так будущие сотрудники) уже обладают необходимыми знаниями.

Однако привлекательность Git обусловлена не только высокой популярностью среди разработчиков. В системе также предусмотрена интеграция различных инструментов и сервисов, включая интегрированные среды разработки и собственные инструменты Atlassian. В число последних входит настольный клиент для распределенных систем управления версиями Sourcetree, система отслеживания задач и проектов Jira, а также сервис размещения кода Bitbucket.

Начинающим разработчикам, которые хотят приобрести ценные навыки работы с инструментами разработки ПО, следует изучить Git как одну из систем управления версиями.

Git — это качественный проект с открытым кодом

Проект Git имеет открытый исходный код, а также активно поддерживается и непрерывно развивается уже более 10 лет. Кураторы проекта продемонстрировали взвешенный и продуманный подход к выполнению требований пользователей, регулярно выпуская релизы для повышения удобства и расширения функциональных возможностей системы. Качество ПО с открытым исходным кодом легко проверяется, и многие организации всецело доверяют таким продуктам.

Вокруг Git сформировалось многочисленное сообщество пользователей, а сам проект получает активную поддержку со стороны сообщества. Система обладает подробной и качественной документацией: всем желающим в числе прочего доступны книги, учебные руководства, специализированные веб‑сайты, подкасты и обучающие видеоролики.

Git — это система с открытым исходным кодом, поэтому разработчики‑любители могут пользоваться ей совершенно бесплатно. В сфере разработки ПО с открытым исходным кодом Git определенно выступает главным преемником успешных систем управления версиями предыдущих поколений, таких как SVN и CVS.

Критика Git

Git нередко критикуют за сложность освоения: одни термины могут быть незнакомы новичкам, а другие — иметь иное значение. Так, понятие revert (возврат к предыдущей версии) в Git имеет другой смысл, нежели в SVN и CVS. Тем не менее Git — очень мощная система, предлагающая пользователям широкие возможности. Их изучение займет какое‑то время, однако усвоенные навыки помогут участникам команды работать намного быстрее.

Команды, перешедшие на Git с нераспределенной системы управления версиями, могут захотеть и дальше пользоваться центральным репозиторием. Несмотря на распределенную архитектуру, Git допускает возможность создания классического репозитория, где сохраняются все изменения проекта. При этом в Git продуктивность разработчиков не зависит от доступности и производительности «центрального» сервера. Каждому пользователю доступна полная копия репозитория, в которой он может просматривать всю историю проекта даже в периоды отсутствия соединения с сетью и перебоев в системе. Распределенная архитектура и гибкость Git позволяют участникам проекта работать в удобном ритме и пользоваться уникальными преимуществами, о которых они могли не подозревать раньше.

Теперь вы разобрались в основах управления версиями, получили представление о Git и узнали, почему командам разработки ПО стоит пользоваться этой системой. Теперь можно перейти к изучению преимуществ, которые Git может предоставить в масштабах организации.

Готовы изучить Git?

Ознакомьтесь с этим интерактивным обучающим руководством.

Источник

Введение в системы контроля версий

Часто разработчики трудятся в команде над одним проектом, а значит, сразу несколько человек могут изменять один файл одновременно. Чтобы избежать путаницы, в таких случаях используют систему контроля версий, которая позволяет хранить историю изменений проекта и при необходимости помогает вернуться к предыдущей версии.

Версионирование

Чтобы лучше понять проблему версионирования, рассмотрим пример дизайнера, который закончил работать над проектом и отправил финальную версию заказчику. У дизайнера есть папка, в которой хранится финальная версия проекта:

Этим всё не ограничилось, в итоге структура проекта разрослась и стала выглядеть так:

Вероятно, многие уже сталкивались с подобным, например, при написании курсовых работ во время учёбы. В профессиональной разработке создавать новые файлы для версионирования — плохая практика. Обычно у разработчиков в папке проекта хранится множество файлов. Также над одним проектом может работать несколько человек. Если каждый разработчик для версионирования будет создавать новый файл, немного изменяя название предыдущей версии, то в скором времени в проекте начнётся хаос и никто не будет понимать, какие файлы нужно открывать.

Для решения проблемы с сохранением новой версии файлов удобно использовать системы контроля версий. Одна из самых популярных — Git. Работу Git можно сравнить с процессом сохранения и загрузки в компьютерных играх:

Папка, содержащая данные игры, могла бы выглядеть так:

Файлы, необходимые для работы приложения, хранятся в рабочей области. В папке saves хранится история всех сохранений игры. Git сохраняет код вашего проекта по такому же принципу: сохранения попадают в специальную скрытую папку, а рабочей областью является содержимое корневой папки.

Основные понятия

Список терминов, которые будут вам полезны.

Репозиторий

Рабочая область и хранилище

Корневая папка проекта — это рабочая область. В ней находятся все файлы и папки, необходимые для его работы.

Коммит

В итоге проект работает так:

Система контроля версий Git

Git — это распределённая и децентрализованная система управления версиями файлов. Децентрализованная система означает, что у каждого разработчика есть личный репозиторий проекта с полным набором всех версий. А все необходимые для работы файлы находятся на компьютере. При этом постоянное подключение к сети не требуется, поэтому система работает быстро. При командной разработке нужна синхронизация репозиториев, так как проект — один и его состояние должно быть у всех одинаковым.

Работа в команде

Как синхронизовать данные репозиториев между разработчиками? Изначально Git репозитории сами могут синхронизироваться от пользователя к пользователю. Дополнительные программы для этого не нужны. Есть специальные команды в консоли, позволяющие передавать данные из одного репозитория в другой.

Репозитории можно синхронизировать между пользователями.

Этот способ сложный и редко используется. Чаще всего разработчики синхронизируют локальный репозиторий с удалённым. Удалённый репозиторий — это тот же репозиторий, только его данные находятся в облаке.

Синхронизация через удалённый репозиторий.

Этапы синхронизации

Как сделать так, чтобы разработчик смог передать актуальную версию проекта коллеге?

Синхронизация (push и pull) между локальными и удалённым репозиториями.

Типовой рабочий процесс с использованием Git

Коммиты B1 и B2.

Игорь запушил свои коммиты.

После пуша данные синхронизировались с удалённым репозиторием. Но как Алисе теперь получить изменения? Для этого она выполняет команду git pull и получает все изменения из облака к себе на компьютер. Таким образом, состояние проекта у Игоря и Алисы синхронизировались, и они могут дальше продолжить работать над ним.

Данные у обоих разработчиков синхронизировались.

Параллельные изменения

Два пуша в одно время?

Конфликт

Дело в том, что Игорь и Алиса изменили одинаковый файл и теперь Алисе предстоит решить конфликт.

Конфликт

Существуют два вида конфликтов:

Ниже рассмотрим оба варианта.

Слияние

Допустим, что на третьей строке Игорь добавил в проект шапку, а на четвёртой Алиса добавила футер.

Игорь сделал шапку и отправил коммит, а Алиса добавила подвал.

Git видит, что произведённые изменения не затрагивают друг друга. Он сам объединит две версии проектов в одну, совершив слияние. После этого Алиса спокойно синхронизируется с удалённым репозиторием, отправив новую версию проекта.

Изменения в проекте не пересекались и Git выполняет слияние сам.

Слияние.

Алиса и Игорь изменили один и тот же блок.

Версии файла.

Версии проектов разделяются строками второй, четвёртой и шестой. Их нужно удалить и оставить правильный вариант заголовка. После того как Алиса это сделает, она сможет закоммитить изменения и запушить их на удалённый репозиторий. Игорь же при следующей синхронизации с облаком получит тот вариант заголовка, который выбрала Алиса.

Окружение Git

Git — удобная система. Плюсом является то, что вокруг него создано множество сервисов, которые позволяют сделать работу с ним удобнее. Расскажем о тех, что будут вам полезны в начале работы.

GitHub

GitHub — это сайт, сервис и то самое облако, в котором можно хранить удалённые репозитории и через которое коллеги могут синхронизировать свои версии проектов. Как зарегистрироваться, мы рассказали в этой статье.

Пройдите бесплатные курсы по фронтенду и узнайте, как верстать сразу хорошо.

Нажатие на кнопку — согласие на обработку персональных данных

Источник

Работа с распределенной системой контроля версий Git на примере GitHub

Работа с распределенной системой контроля версий Git на примере GitHub
Год начала данной публикации: 2019
Год окончания данной публикации: не указан

Предупреждение по использованию:

Данная публикация является учебной для освоения основ системы контроля версий git, на примере использования GitHub. Это не руководство к действию. Вы должны понимать, то что вы делаете применяя команды и идеи изложенные в публикации. Не спешите применять сказанное к вашим рабочим проектам. Создайте черновой проект, локальный репозиторий. Потренируйтесь на нем. Создайте свой учебный проект на GitHub. Когда вы хорошо будете понимать, что и как работает, только тогда вы сможете применить ваши знания в рабочих проектах. Публикация не является переводом какой либо работы. Это авторская работа с целью прояснить некоторые вопросы. Более подробно смотрите раздел: «Цель публикации».

Небольшая ремарка:
Первый и может быть наиболее важный вопрос, который следовало бы рассмотреть — это безопасность системы для разработчика. Если в организации вашу сеть защищает системный администратор. То обычному пользователю приходится эти вопросы решать самостоятельно.
Этот вопрос далеко не праздный.

Что не должно попасть в удаленный репозиторий:
Лишние файлы конфигурации, исполняемые файлы, временные файлы, ключи к репозиторию, платежные ключи(когда вы работаете над платежными сервисами и системами наподобии Amazon). В ветки master и release не должны попасть изменения от начинающих, неопытных программистов и некачественный код, не прошедший тестирование.

Система контроля версий довольно сложная штука. Но пусть вас это не пугает. Попробуем разобраться. Дать определения, и внести ясность. Если вы работаете один над своим проектом, то вам даже не обязательно регистрироваться на сервере. Вы можете просто установить себе Git и работать с системой контроля версий локально. Вам для локальной работы над проектом не обязательно даже будет подключение к интернету. Репозиторий который вы создаете локально — это фактически такой же репозиторий как на сервере, только без возможности работать над проектом распределенной команды разработчиков. Система контроля версий — по существу это реализация права программиста на ошибку в своем коде. Как вы помните «человеку свойственно ошибаться». Так вот, ошибаться программисту следует гораздо меньше. И, чтобы вернуться к своему коду и исправить ошибку, добавить функциональность и существует такая замечательная система, как система контроля версий. Кроме того использование системы контроля версий — это более эффективный менеджмент.

Ответьте на вопрос: В чем заключается работа в команде и вы поймете насколько управление проектом становится более эффективным с системой контроля версий. Еще одно преимущество: Система контроля версий облегчает процесс ревью(пересмотра, доработки) кода. Следующее преимущество: Автоматическое разрешение конфликтов. То есть объединение, например разных версий методов, сделанных разными разработчиками в одну ветку. Здесь, в данном материале я не рассматриваю плагины для git в IDE. Здесь рассматриваются только общие вопросы работы с git и работы с удаленным репозиторием на GitHub.

Контрольные вопросы:
В чем заключается экономия времени при использовании системы контроля версий?
В чем преимущества использования системы контроля версий?
Что такое Git?
Как начать использовать git?
Как начать использовать GitHub?
Основные(наиболее часто используемые) команды Git.
Какие сервисы существуют для Git?
Как работать с локальным репозиторием?
Как работать с распределенным репозиторием?

Git-хостинг на разных условиях предлагают многие компаний.
Довольно известные из них: Github, Sourceforge, Google Code, GitLab, Codebase и тд.

Сервисы git в порядке популярности(тут, чтобы не возникло холивара, допишу: По моему мнению):

1. Ваш локальный сервис, использование git только локально
2. GitHub
3. BitBucket
4. GitLab

Про использование своего git сервера вы можете прочитать на хабре >>>

В данной публикации я рассматриваю в основном работу с сервисом GitHub.

Цель публикации: Коротко рассказать что такое Git.

Описать некоторые, основные команды консоли Git. Хотя в интернет существует довольно много описаний работы с git, многое из документации может показаться запутанным и некоторые определения раскрыты не полностью. Что может ввести начинающих в заблуждение. Некоторые определения следует написать в более развернутом виде, для ясности понимания.
Также с практическими примерами намного легче освоить систему. Цель статьи сделать небольшой обзор о системе Git. Показать как использовать некоторые команды, для более быстрого освоения начинающими. Показать как настроить систему для конкретного использования. Следующая цель, предотвратить бездумное использование тех или иных команд Git.

Предметная область и основные термины

Система контроля версий — программное обеспечение для облегчения работы с изменяющейся информацией. Система управления версиями позволяет хранить несколько версий одного и того же документа, при необходимости возвращаться к более ранним версиям, определять, кто и когда сделал то или иное изменение, и многое другое.

Git — одна из распределенных систем контроля версий.
GitHub — один из сервисов для использования системы контроля версий Git.

repository — некоторое хранилище файлов, ссылок на изменения в файлах
commit — отслеживание изменений, сохраняет разницу в изменениях
HEAD — (специальный указатель) символическая ссылка на последние изменения. Примечание: Не обязательно ссылается на commit. Может указывать на ветвь. Состояние — «Detached HEAD»
HEAD используется репозиторием для определения того, что выбрано с помощью checkout.
Обратите внимание на это различие: «head» (в нижнем регистре) относится к любому из названных заголовков в хранилище; «HEAD» (верхний регистр) относится исключительно к текущему активному заголовку(ссылке). Это различие часто используется в документации Git. HEAD может указывать на именованную вершину какой-либо ветки или на commit.
Объекты Git. Четыре типа объектов: Blob, Tree, Commit и References.
Ветвь определяется не в самом Git, а наследуется от операционной и файловой систем.
Более подробно об объектах Git вы можете прочитать в документации.

git сервисы — сервисы предоставляющие услуги для пользователей git.

HEAD — указатель на текущую ветку. Текущая ветка. Более подробно: Ваше рабочее дерево обычно получается из состояния дерева, на которое ссылается HEAD. HEAD — это ссылка на один из заголовков в вашем хранилище, за исключением случаев использования отдельного HEAD, в этом случае он напрямую ссылается на произвольный коммит

working directory — рабочий каталог на вашем компьютере
staging area — область подготовленных файлов или рабочая область
branch — ветка, состоит из набора коммитов, обычно ссылается на последний коммит
merge — слияние, слияние веток в одну
pull — втянуть, взять проект с сервера, получить изменения из удаленного репозитория
push — вытолкнуть, отправить изменения на сервер

Символы:
# — в данном случае символ комментария
<> — угловые скобки, там где вам нужно вписать нужное исключая эти скобки
$ — приглашение ввода в терминале

Небольшое вступление

Хотел написать небольшую шпаргалку по git, а получилась довольно длинная публикация.
Но без объяснения тех или иных терминов и некоторой вводной теоретической части не обойтись.

Git — одна из систем контроля версий.

Предназначена, в основном, для работы распределенной команды разработчиков.
То есть разработчики могут находиться в разных концах света и работать над одним проектом.
Нет Git используют не только разработчики, но и дизайнеры, писатели, редакторы, проектировщики, переводчики. GitHub часто используют hr специалисты и hr менеджеры для поиска успешных кандидатов на те или иные вакасии в различных областях. Для математического анализа успешности проектов.
Система Git очень экономична и не требует рассылки большого количества файлов. Отслеживаются и пересылаются изменения в файлах и ссылки на эти изменения. То есть основная рассылка это рассылка разницы в ваших редактированиях.

Отсылаются только различия в папках и файлах. В любой момент времени вы можете возвратиться к тому или иному состоянию системы. Многие компании уделяют внимание хорошей и быстрой коммуникации между сотрудниками. В этом отношении, система контроля версий предоставляет большие возможности. Всю мощь и гибкость системы управления версиями вы сможете ощутить после изучения некоторого теоретического материала и применения на практике.

История создания

Git (произнoсится «гит»[8]) — распределённая система управления версиями. Проект был создан Линусом Торвальдсом для управления разработкой ядра Linux, первая версия выпущена 7 апреля 2005 года. На сегодняшний день его поддерживает Джунио Хамано.

Теоретическая часть(коротко)

Проект был создан Линусом Торвальдсом для управления разработкой ядра Linux
Git свободная система и распространяется она под лицензией GNU GPL 2.

Git is an Open Source project covered by the GNU General Public License version 2 (some parts of it are under different licenses, compatible with the GPLv2).

Основная задача системы управление версий — это упрощение работы с потоками изменяющейся информации. Главной парадигмой системы управления версий является локализация данных каждого разработчика проекта. Каждый разработчик имеет на своей машине локальный репозиторий. В случае необходимости изменения отправляются из локального репозитория в удаленное хранилище в определенную ветку. И любой разработчик из распределенной команды может скачать новые изменения в проекте, чтобы продолжить совместную работу над проектом. Тут я сделаю некоторую ремарку. Важно соблюдать стандарты по оформлению кода и работе с системой в вашей организации. Стандарты облегчают взаимодействие между разработчиками, экономят время, облегчают понимание того что вы делаете. Некоторая этика и культура по оформлению кода, по оформлению и структурированию рабочего процесса помогает разработчикам лучше и быстрее понимать друг друга.

Какие существуют системы управления версиями:
1. Централизованные
2. Децентрализованные(распределенные)

В централизованной системе управления версий код хранится на сервере. Все разработчики в команде имеют доступ к централизованному хранилищу. Однако существуют минусы такой организации работы. У разработчика нет своего локального репозитория, а есть только копия данных с сервера. В случае выхода из строя сервера команда не сможет продолжить работу над проектом. Второй минус использования централизованной системы управлени версиями в сложности досупа к одному ресурсу одновременно нескольким разработчикам.

В распределенной системе управления версий, кроме версии репозитория на сервере, у каждого разработчика есть свой репозиторий. Это позволяет быстро восстановить актуальное состояние нашего программного обеспечения.

Fork – удаленная копия репозитория на сервере, отличная от оригинала. Это даже не git-концепция, а, скорее, политико-социальная идея. Clone – это не то же самое, что и fork. Клон удаленного репозитория располагается локально. Фактически при клонировании копируются все данные, включая историю коммитов и существующие ветки.
Branch, или создание ветки, – это способ внести изменения в проект и объединить их в итоге с остальным кодом. Ветка является частью репозитория.

Некоторое отступление от темы: Зачем я так много привел цитат?
Ответ самый простой. Чтобы в дальнейшем дать более точные и ясные определения.

Практическая часть

Для использования системы git вам нужно:

1. Установить программу git на вашей системе.
2. Настроить программу и проверить её работоспособность локально
3. Зарегистрировать ваш аккаунт на GitHub
4. Создать локальный репозиторий или копировать репозиторий существующего проекта
5. Написать файл README.MD.
6. В случае, если вы начинаете проект, создать удаленный репозиторий
7. Фиксировать изменения локально
8. Отправлять изменения на GitHub
9. Зарегистрировать аккаунты разработчиков вашего проекта
10. Выдать им ссылку на проект

1. После установки вы можете кликнуть правой кнопкой мышки на папке в проводнике Windows и выбрать открыть «Git Bash Here». Git Bash Here — означает отрыть терминал git здесь.

В терминале введите команду
проверить версию вашего git.

В Linux,(Ctrl+Alt+T — терминал, если у вас не назначены другие горячие клавиши) откройте терминал и введите

В случае успешной установки на консоль выведется версия вашего git.

2.Настройка программы Git

Примечание:
Тут следует упомянуть, что настройку Git вы осуществляете на нескольких уровнях.
То есть некоторые настройки вы делаете для определенного пользователя операционной системы(не системы git, а операционной системы). Другие настройки вы делаете для всех пользователей операционной системы. Далее вы можете делать настройки для определенной папки(локально). Вы делает настройки для репозитория находящегося на сервере. Эти настройки вы можете не делать, если работаете только со своим локальным репозиторием.
В данной публикации я рассматриваю команды консоли в основном Windows git-bash.
Более подробно об отличиях вы можете посмотреть в документации. Упомяну только что есть некоторые отличия. Например в параметрах пути к файлам и папкам. В Windows используется / — слеш, а в Linux обратный слеш \. Хотя в Windows вы можете самостоятельно настроить на использование обратного слеша.

Настройка пользователя и емейл:

Настройка внешнего редактора.
#команда для Linux.
Вы можете выбрать другой текстовый редактор. Например не emacs, a vi или nano или другой на ваше усмотрение.

В Windows, такой командой вы можете задать текстовый редактор, например notepad++.

Для x64 Windows вы можете использовать команду(только пропишите свой путь):

Настройки git хранятся в файлах.

Каждый файл добавляет или переопределяет параметры git, определенные в файле над ним.

Конфигурация системы.
Конфигурация пользователя.
Конфигурация, специфичная для репозитория.

Вы можете просмотреть файлы конфигурации

#для системы и всех пользователей

Проверка настроек вашей конфигурации git:

Если список большой, вы можете пролистывать его с помощью стрелок клавиатуры или «pg up», «pg dn». Для выхода клавиша q.

#какая конфигурация, где установлена:

Для чего нужно рассмотреть консольные команды? Ведь существуют UI.
Часто в консоли вы можете сделать, что-то гораздо быстрее. С помощью набора консольных команд вы сами в будущем сможете автоматизировать процесс. Консольные команды более гибкий инструмент. Почему? Да потому что ваш UI может и «не знать» о существовании той или иной команды. UI может вообще отсутствовать как таковой, например на сервере ввиду своей небезопасности. На первом этапе консольные команды во многом помогут в общем понимании того как работает система. Все их запоминать нет необходимости. Вы в любой момент сможете найти справку по той или иной команде. Теоретические знания, без которых никуда, лучше усваиваются с применением на практике.

Опции:
-C — использовать указанную папку репозитория вместо текущей папки;
-c параметр=значение — использовать указанное значение параметра конфигурации;
-p — прокручивать весь вывод с помощью less;

Инициализация локального репозитория.

1. Переходим в папку проекта.

2.
3. Папку. Точка после add отделенная пробелом.
Можно добавить отдельный файл
Например
Таким образом мы говорим — отслеживать изменения нашего файла.
Для добавления всего в папке рекомендуют использовать команду

Тут нужно сделать некоторое замечание. Чтобы использовать русские буквы в комментариях, нужно сделать предварительные настройки. Вам нужно настроить кодировку символов в системе, кодировку символов в текстовом редакторе или IDE, кодировку символов в терминале, кодировку символов в git. Другой момент: Windows «не любит» одиночные апострофы, поэтому коментарий заклечен в кавычки. На Linux есть возможность использовать апострофы при оформлении коментария к коммиту.

6.
Показывает информацию — какая ветка текущая.
Какие файлы изменены и тд. Команда показывает, что находится в рабочей области(в staging area).

Ветка(branch) — ссылка на определенный коммит.

Создание ветки.
, используйте для имени латинские буквы. Тут есть одно замечание. Когда мы создали ветку с некоторым именем, текущей осталась ветка, которая была выделена до этого. Ну например master. И если после создания ветки мы скажем git commit, то будет продолжена ветка master. Не понимание этого часто приводит к ошибкам.

Совет: Чтобы продолжить новую ветку нужно её создать, потом переключиться на неё и сделать commit.

1. Создаем ветку:
2. Переключаемся на созданную ветку:
3. Делаем commit:

Теперь у нас есть вторая ветка с именем feature.

Объединение веток(merge).
Объединение веток создает коммит от двух родителей, от текущей ветки и ветки указанной в команде git.

1. Переключаемся на ветку master
2. Сморим какая ветка текущая
3. Объединяем ветки

Мы можем сделать по другому. Переключиться на ветку feature и объединить её с веткой master

Просмотр доступных веток:

stash — стек, временное хранилище
Не путайте со stage, это не одно и то же.

Команда сохраняет все не закомиченные изменения во временное хранилище и сбрасывает состояние ветки до HEAD.

git stash берет ваши изменения, подготовленные и неподготовленные к фиксации, сохраняет их для последующего использования и убирает из рабочей области.

Стеш(stash) предназначит для того, что бы спрятать не нужные на данный момент изменения, потому он и называется stash, в переводе — прятать, припрятывать.

рис 1.

На рисунке показана подготовка папки на локальном компьютере для git.
Добавление в staging area. Добавление изменений в локальный репозиторий(git commit).
Отправка в удаленный репозиторий(git push).
На данной схеме не показана сущность stash.

рис 2.

На диаграмме рис 2. показана работа команд add, commit all, commit, reset, git reset head, git update index.

Untacked files — непроиндексированные файлы.
Working tree — ваша рабочая папка
Index — индексация файлов
Commit — изменения файлов

Здесь нужно внести некоторую ясность. Диаграмма относится к вашему локальному репозиторию. Но это другой вид диаграммы. Это как будто мы рассматриваем работу git c различных точек, под «разным углом». Показан некоторый жизненный цикл индексации изменений локального репозитория.

Работа с командами:

Очень полезные команды. Рассмотрите их самостоятельно.

Работа с удаленным репозиторием

Далее я перейду к описанию работы с удаленным репозиторием.
Вы можете работать с удаленным репозиторием и вашим проектом через протокол [url]https://,[/url]
то есть в вашем браузере(chrome, mozilla, opera и других).

GitHub.com >>>
Интерфейс GitHub на английском языке.

Для начала, вам нужно зарегистрироваться на GitHub, если вы этого еще не сделали или
подключить нужную ветку и отправить изменения локального репозитория.
Узнать как зарегистрироваться вы можете на самом сайте GitHub.

Перед использованием удаленного репозитория у вас должен быть локальный проинициализированный репозиторий.
В папке на локальном компьютере:

Подключить ветку на удаленном(в данном случае GitHub) компьютере:

«имя_ник_пользователя» — в данном случае ник пользователя удаленного репозитория.
«ИмяРепозитория» — в данном случае это имя вашего уже созданного заранее репозитория на GitHub

Показать какие пути назначены:

Обычно там одна ветка origin.
То есть это не сама ветка, а её сокращенное название ассоциированное с репозиторием.
Вы можете добавить, ассоциировать еще одну ветку на удаленном репозитории.

имя_удаленного_реп — имеется в виду короткое имя которое будет ассоциировано с удаленным репозиторием.
имя_удаленного_репозитория — имеется в виду имя репозитория на сервере. То есть имя удаленного репозитория.

Только данная команда забирает одну ветку из удаленного репозитория.
Кроме того она сливает(объединяет, merge) все изменения из удаленного репозитория с вашими локальными. Эту команду следует применять, когда вы только начинаете работать с удаленным репозиторием и у вас своих наработок в локальном пока нет.

Эта команда создает папку с именем Lимя_локальной_папки.
Берет все изменения из репозитория «github.com/имя_пользователя/имя_удаленного_репозитория.git» и сохраняет их в папке «Lимя_локальной_папки».
Здесь я написал префикс L перед именем папки, чтобы отличить локальную папку от удаленной на сервере.

Диаграмма ниже показывает отличие работы с локальным репозиторием и с репозиторием на GitHub
[url]https://greenido.files.wordpress.com/2013/07/git-local-remote.png?w=696&h=570[/url]

Из данной диаграммы вы можете видеть, как работать с локальным репозиторием и как работать с репозиторием на сервере. Показаны только несколько команд для краткости и ясности.
Ваш локальный репозиторий находящийся на одной вашей рабочей станции — это такой же репозиторий. Вы можете не регистрироваться на GitHub или других серверах, а работать локально. Вам даже не нужно для этого подключения к интернет. У вас будет локальный репозиторий и контроль версий. Такие же ветки, по которым вы можете переключаться, объединять их и тд. То есть полноценно работать локально, как с сервером.
При желании, вы сможете потом отправить их на сервер.

В терминале cmd windows:

Вы можете создать глобальный файл для пользователя

Теперь вам нужно узнать куда ведет ссылка и создать файл.

Вам осталось создать этот файл. Откройте терминал(В Windows cmd).

рис 3.

На данной диаграмме показана работа команд: git add, git commit, git push и git fetch.

Команда fetch забирает данные в ваш локальный репозиторий, но не сливает их с какими-либо вашими наработками и не модифицирует то, над чем вы работаете в данный момент.

Модели ветвления в Git:

Для чего нужны модели ветвления?
Для лучшей организации потока работы(Workflow). Для стандартизации. То есть в вашей организации может быть принята, в зависимости от целей некоторая модель ветвления.

Central Workflow
Developer Branch Workflow
Feature Branch Workflow
Issue Branch Workflow
Forking Workflow
Patch Workflow

Central Workflow (центральный рабочий процесс) в этом контексте определяется как «вы отправляете изменения тому же репозиторий, из которого вы обычно получаете свои последние вышестоящие изменения», независимо от того, используете ли вы rebase или merge. (pull = fetch + merge или fetch + rebase, в зависимости от конфигурации и параметров)

Feature Branching являет логическим расширением Central Workflow (центрального рабочий процесса). Основная идея рабочего процесса Feature Branch: разработка всех функций должна осуществляться в выделенной ветви вместо основной ветви. Главная ветвь никогда не должна содержать неработающий код. Это является большим преимуществом в средах непрерывной интеграции.

Gitflow Workflow
Рабочий процесс Gitflow был впервые опубликован в блоге Винсента Дриссена от nvie за 2010 год. Рабочий процесс Gitflow определяет строгую модель ветвления, разработанную для выпуска проекта. Этот рабочий процесс не добавляет каких-либо новых концепций или команд помимо того, что требуется для рабочего процесса Feature Branch. Вместо этого он назначает очень конкретные роли различным ветвям и определяет, как и когда они должны взаимодействовать.

Forking Workflow
Рабочий процесс Forking отличается от других рабочих процессов. Вместо того чтобы использовать один серверный репозиторий в качестве «центральной» кодовой базы, он предоставляет каждому разработчику серверный репозиторий. Это означает, что у каждого участника есть не один, а два репозитория Git: частный локальный и общедоступный серверный.

Не существует одного рабочего процесса, подходящего для всех разработчиков в Git. Важно разработать рабочий процесс Git, который повысит производительность вашей команды. В дополнение к командной культуре, рабочий процесс должен также дополнять деловую культуру. Функции Git, такие как ветки и теги, должны дополнять график выпуска продукции. Если ваша команда использует программное обеспечение для управления проектами для отслеживания задач, вы можете использовать ветки, соответствующие выполняемым задачам.
Вы можете найти рекомендации по использованию рабочих процессов в документации к Git.

Выводы:
Мы с вами рассмотрели работу системы git и работу с удаленными репозиториями.
В некоторой степени коснулись вопроса установки и конфигурации git, регистрации удаленного репозитория на примере GitHub. Применения git как локально, так и удаленно. А также некоторые моменты организации рабочего процесса. В одной статье невозможно рассказать обо всем. Вы можете продолжить обучение изучая материалы документации и публикации других авторов. Что меня по настоящему восхищает в git, так это проектирование и реализация хорошей экосистемы.

Как установить:
1. Скачиваем файл в папку на локальном диске
2. Открываем IDE NetBeans
3. Tools/Plugin/Downloaded/Add Plugins
4. Указываем путь к плагину на вашем локальном компьютере.
5. Перезапуск IDE

Для IDE Intellij Idea вы можете скачать плагин «Add to gitignore»
plugins.jetbrains.com/plugin/7495—ignore

1.Переходим на сайт с плагином
2. Выбираем вашу версию IDE
3. Читаем инструкцию.
4. Скачиваем и устанавливаем

Вы можете установить плагин из IDE:
Preferences > Plugins > Browse repositories… > Search for «.ignore» > Install Plugin
После установки «Restart Idea».

Как вы знаете от версии к версии в программы вносятся изменения.
Какие изменения были сделаны для версии git 2.0: >>>

Здесь еще следует немного рассказать о безопасности использования git и то что относится к использованию различных UI для git.

Продолжение, уточнение следует…

Автор будет вынужден удалить свои публикации или скрыть их в черновики в случае отсутствия поддержки. Это не ультиматум. Если у вас есть возможность, вам пригодилось, вы можете помочь, то нажмите кнопку поддержать автора.

Источник