Git и GitHub: что это такое и в чём разница
Авторизуйтесь
Git и GitHub: что это такое и в чём разница
Из этой статьи вы узнаете, что такое Git и какие в принципе бывают системы контроля версий, которые помогают разработчикам следить за изменениями в коде. Мы также посмотрим, что такое GitHub и какие ещё есть сервисы для работы с Git.
Примечание Вы читаете улучшенную версию некогда выпущенной нами статьи.
Содержание:
Что такое Git
Git — распределённая система контроля версий, которая даёт возможность разработчикам отслеживать изменения в файлах и работать над одним проектом совместно с коллегами. Она была разработана в 2005 году Линусом Торвальдсом, создателем Linux, чтобы другие разработчики могли вносить свой вклад в ядро Linux. Git известен своей скоростью, простым дизайном, поддержкой нелинейной разработки, полной децентрализацией и возможностью эффективно работать с большими проектами.
Подход Git к хранению данных похож на набор снимков миниатюрной файловой системы. Каждый раз, когда вы сохраняете состояние своего проекта в Git, система запоминает, как выглядит каждый файл в этот момент, и сохраняет ссылку на этот снимок.
Теперь пора разобраться, что такое GitHub и как он работает с Git.
Что такое GitHub и чем он отличается от Git
Как мы разобрались выше, Git — это инструмент, позволяющий реализовать распределённую систему контроля версий.
GitHub — сервис онлайн-хостинга репозиториев, обладающий всеми функциями распределённого контроля версий и функциональностью управления исходным кодом — всё, что поддерживает Git и даже больше. Также GitHub может похвастаться контролем доступа, багтрекингом, управлением задачами и вики для каждого проекта.
Git-репозиторий, загруженный на GitHub, доступен с помощью интерфейса командной строки Git и Git-команд. Также есть и другие функции: документация, запросы на принятие изменений (pull requests), история коммитов, интеграция со множеством популярных сервисов, email-уведомления, эмодзи, графики, вложенные списки задач, система @упоминаний, похожая на ту, что в Twitter, и т.д.
Кроме GitHub есть другие сервисы, которые используют Git, — например, Bitbucket и GitLab. Вы можете разместить Git-репозиторий на любом из них.
Что такое система контроля версий
Чтобы лучше понимать, что такое Git и как он работает, нужно ещё знать, что такое система контроля версий.
Системы контроля версий (СКВ, VCS, Version Control Systems) позволяют разработчикам сохранять все изменения, внесённые в код. При возникновении проблем они могут просто откатить код до рабочего состояния и не тратить часы на поиски ошибок.
СКВ также позволяют нескольким разработчикам работать над одним проектом и сохранять внесённые изменения независимо друг от друга. При этом каждый участник команды видит, над чем работают коллеги.
Типы систем контроля версий
Теперь вы знаете, что такое система контроля версий. Однако они тоже бывают разными. Существует три типа СКВ: локальная, централизованная и распределённая.
Локальные системы контроля версий (ЛСКВ)
Принцип работы локальной системы контроля версий
В качестве метода контроля версий можно копировать файлы в отдельную директорию. Изменения сохраняются в виде наборов патчей, где каждый патч датируется и получает отметку времени. Таким образом, если код перестаёт работать, наборы патчей можно совместить, чтобы получить исходное состояние файла. Такой подход всё ещё распространён среди разработчиков.
Централизованные системы контроля версий (ЦСКВ)
Принцип работы централизованной системы контроля версий
ЦСКВ были созданы для решения проблемы взаимодействия с другими разработчиками. Такие системы имеют единственный сервер, содержащий все версии файлов, и некоторое количество клиентов, которые получают файлы из этого централизованного хранилища и там же их сохраняют. Тем не менее, такой подход имеет существенный недостаток — выход сервера из строя обернётся потерей всех данных. Кроме того, в таких системах может быть затруднена одновременная работа нескольких разработчиков над одним файлом.
Распределённые системы контроля версий (РСКВ)
Принцип работы распределённой системы контроля версий
Недостаток ЦСКВ был исправлен в РСКВ, клиенты которых не просто скачивают снимок всех файлов (состояние файлов на определённый момент времени), а полностью копируют репозиторий. Это значит, что у каждого клиента есть копия всего исходного кода и внесённых изменений. В этом случае, если один из серверов выйдет из строя, любой клиентский репозиторий может быть скопирован на другой сервер для продолжения работы. Ещё одним преимуществом РСКВ является то, что они могут одновременно взаимодействовать с несколькими удалёнными репозиториями. Благодаря этому разработчики могут параллельно работать над несколькими проектами. Именно поэтому Git сейчас так популярен.
Git для новичков (часть 1)
Что такое Git и зачем он нужен?
С помощью Git-a вы можете откатить свой проект до более старой версии, сравнивать, анализировать или сливать свои изменения в репозиторий.
Репозиторием называют хранилище вашего кода и историю его изменений. Git работает локально и все ваши репозитории хранятся в определенных папках на жестком диске.
Так же ваши репозитории можно хранить и в интернете. Обычно для этого используют три сервиса:
Как работает
В итоге получается очень простой граф, состоящий из одной ветки ( main ) и четырех commit. Все это может превратиться в более сложный граф, состоящий из нескольких веток, которые сливаются в одну.
Об этом мы поговорим в следующих статьях. Для начала разберем работу с одной веткой.
Установка
Основой интерфейс для работы с Git-ом является консоль/терминал. Это не совсем удобно, тем более для новичков, поэтому предлагаю поставить дополнительную программу с графическим интерфейсом (кнопками, графиками и т.д.). О них я расскажу чуть позже.
Но для начала, все же установим сам Git.
Windows. Проходим по этой ссылке, выбираем под вашу ОС (32 или 64 битную), скачиваем и устанавливаем.
Для Mac OS. Открываем терминал и пишем:
Linux. Открываем терминал и вводим следующую команду.
Настройка
Вы установили себе Git и можете им пользоваться. Давайте теперь его настроим, чтобы когда вы создавали commit, указывался автор, кто его создал.
Открываем терминал (Linux и MacOS) или консоль (Windows) и вводим следующие команды.
Создание репозитория
Теперь вы готовы к работе с Git локально на компьютере.
Создадим наш первый репозиторий. Для этого пройдите в папку вашего проекта.
Теперь Git отслеживает изменения файлов вашего проекта. Но, так как вы только создали репозиторий в нем нет вашего кода. Для этого необходимо создать commit.
Отлично. Вы создали свой первый репозиторий и заполнили его первым commit.
Процесс работы с Git
Не стоит после каждого изменения файла делать commit. Чаще всего их создают, когда:
Создан новый функционал
Добавлен новый блок на верстке
Исправлены ошибки по коду
Вы завершили рабочий день и хотите сохранить код
Это поможет держать вашу ветки в чистоте и порядке. Тем самым, вы будете видеть историю изменений по каждому нововведению в вашем проекте, а не по каждому файлу.
Визуальный интерфейс
Как я и говорил ранее, существуют дополнительные программы для облегчения использования Git. Некоторые текстовые редакторы или полноценные среды разработки уже включают в себя вспомогательный интерфейс для работы с ним.
Но существуют и отдельные программы по работе с Git. Могу посоветовать эти:
Я не буду рассказывать как они работают. Предлагаю разобраться с этим самостоятельно.
Создаем свой первый проект и выкладываем на GitHub
Давайте разберемся как это сделать, с помощью среды разработки Visual Studio Code (VS Code).
Перед началом предлагаю зарегистрироваться на GitHub.
Создайте папку, где будет храниться ваш проект. Если такая папка уже есть, то создавать новую не надо.
Установите себе дополнительно анализаторы кода для JavaScript и PHP
Откройте вашу папку, которую создали ранее
После этого у вас появится вот такой интерфейс
Здесь будут располагаться все файлы вашего проекта
Здесь можно работать с Git-ом
Кнопка для создания нового файла
Кнопка для создания новой папки
Давайте теперь перейдем во вкладу для работы с Git-ом.
Откроется вот такое окно:
Кнопка для публикации нашего проекта на GitHub
Вы создали и опубликовали репозиторий на GitHub.
Теперь сделаем изменения в коде и попробуем их снова опубликовать. Перейдите во вкладку с файлами, отредактируйте какой-нибудь файл, не забудьте нажать crtl+s (Windows) или cmd+s (MacOS), чтобы сохранить файл. Вернитесь обратно во вкладу управления Git.
Если посмотреть на значок вкладки Git, то можно увидеть цифру 1 в синем кружке. Она означает, сколько файлов у нас изменено и незакоммичено. Давайте его закоммитим и опубликуем:
Кнопка для просмотра изменений в файле. Необязательно нажимать, указал для справки
Добавляем наш файл для будущего commit
Отправляем наш commit в GitHub
Поздравляю, вы научились создавать commit и отправлять его в GitHub!
Это первая вводная статья по утилите Git. Здесь мы рассмотрели:
Как его устанавливать
Как его настраивать
Как инициализировать репозиторий и создать commit через консоль
Как на примере VS Code, опубликовать свой код на GitHub
Забегая вперед, советую вам погуглить, как работают следующие команды:
P.S. Для облегчения обучения, оставлю вам ссылку на бесплатный тренажер по Git.
Национальная библиотека им. Н. Э. Баумана
Bauman National Library
Персональные инструменты
Git (произн. «гит» [1] ) — распределённая система управления версиями. Проект был создан Линусом Торвальдсом для управления разработкой ядра Linux, первая версия выпущена 7 апреля 2005 года. На сегодняшний день его поддерживает Джунио Хамано.
Программа является свободной и выпущена под лицензией GNU GPL версии 2.
Содержание
Возможности
Система спроектирована как набор программ, специально разработанных с учётом их использования в скриптах. Это позволяет удобно создавать специализированные системы контроля версий на базе Git или пользовательские интерфейсы. Например, Cogito является именно таким примером оболочки к репозиториям Git, а Stacked Git использует Git для управления коллекцией исправлений (патчей).
Git поддерживает быстрое разделение и слияние версий, включает инструменты для визуализации и навигации по нелинейной истории разработки. Как и Darcs, BitKeeper, Mercurial, Bazaar и Monotone, Git предоставляет каждому разработчику локальную копию всей истории разработки, изменения копируются из одного репозитория в другой.
Удалённый доступ к репозиториям Git обеспечивается git-daemon, SSH- или HTTP-сервером. TCP-сервис git-daemon входит в дистрибутив Git и является наряду с SSH наиболее распространённым и надёжным методом доступа. Метод доступа по HTTP, несмотря на ряд ограничений, очень популярен в контролируемых сетях, потому что позволяет использовать существующие конфигурации сетевых фильтров.
Особенности реализации
Ядро Git представляет собой набор утилит командной строки с параметрами. Все настройки хранятся в текстовых файлах конфигурации. Такая реализация делает Git легко портируемым на любую платформу и даёт возможность легко интегрировать Git в другие системы (в частности, создавать графические git-клиенты с любым желаемым интерфейсом).
Репозиторий Git представляет собой каталог файловой системы, в котором находятся файлы конфигурации репозитория, файлы журналов, хранящие операции, выполняемые над репозиторием, индекс, описывающий расположение файлов и хранилище, содержащее собственно файлы. Структура хранилища файлов не отражает реальную структуру хранящегося в репозитории файлового дерева, она ориентирована на повышение скорости выполнения операций с репозиторием. Когда ядро обрабатывает команду изменения (неважно, при локальных изменениях или при получении патча от другого узла), оно создаёт в хранилище новые файлы, соответствующие новым состояниям изменённых файлов. Существенно, что никакие операции не изменяют содержимого уже существующих в хранилище файлов.
По умолчанию репозиторий хранится в подкаталоге с названием «.git» в корневом каталоге рабочей копии дерева файлов, хранящегося в репозитории. Любое файловое дерево в системе можно превратить в репозиторий git, отдав команду создания репозитория из корневого каталога этого дерева (или указав корневой каталог в параметрах программы). Репозиторий может быть импортирован с другого узла, доступного по сети. При импорте нового репозитория автоматически создаётся рабочая копия, соответствующая последнему зафиксированному состоянию импортируемого репозитория (то есть не копируются изменения в рабочей копии исходного узла, для которых на том узле не была выполнена команда commit).
Архитектура
Нижний уровень git является т. н. файловой системой с адресацией по содержимому (content-addressed file system). Инструмент командной строки git содержит ряд команд по непосредственной манипуляции этим репозиторием на низком уровне. Эти команды не нужны при нормальной работе с git как с системой контроля версий, но нужны для реализации сложных операций (ремонт поврежденного репозитория и т. д.), а также дают возможность создать на базе репозитория git какое-то своё приложение.
Все ссылки на объекты репозитория, включая ссылки на один объект, находящийся внутри другого объекта, являются SHA-1 хешами.
Кроме того, в репозитории существует директория refs, которая позволяет задать читаемые человеком имена для каких-то объектов git. В командах git оба вида ссылок — читаемые человеком из refs, и нижележащие SHA-1 — полностью взаимозаменяемы.
В классическом обычном сценарии в репозитории git есть три типа объектов — файл, дерево и коммит. Файл есть какая-то версия какого-то пользовательского файла, дерево — совокупность файлов из разных поддиректорий, коммит — дерево + некая дополнительная информация (например, родительский(е) коммит(ы), а также комментарий).
В репозитории иногда производится сборка мусора, во время которой устаревшие файлы заменяются на «дельты» между ними и актуальными файлами (именно так! актуальная версия файла хранится не-инкрементально, инкременты используются только для шагания назад), после чего данные «дельты» складываются в один большой файл, к которому строится индекс. Это снижает требования по месту на диске.
Практически все обычные операции с системой контроля версий, такие, как коммит и слияние, производятся только с локальным репозиторием. Удаленный репозиторий можно только синхронизировать с локальным как «вверх» (push), так и «вниз» (pull).
Наличие полностью всего репозитория проекта локально у каждого разработчика дает git ряд преимуществ перед SVN. Так, например, все операции, кроме push и pull, можно осуществлять без наличия Интернет-соединения.
Очень мощной возможностью git являются ветви, реализованные куда более полно, чем в SVN. Создать новую ветвь так же просто, как и совершить коммит. По сути, ветвь git есть не более чем читаемое человеком имя, «навешенное» на некий коммит в репозитории (используется поддиректория refs). Коммит без создания новой ветви всего лишь передвигает эту ссылку на себя, а коммит с созданием ветви — оставляет старую ссылку на месте, но создает новую на новый коммит, и объявляет её текущей. Заменить локальные девелоперские файлы на набор файлов из иной ветви, тем самым перейдя к работе с ней — также тривиально.
Также поддерживаются суб-репозитории с синхронизацией текущих ветвей в них.
Команда push передает все новые данные (те, которых ещё нет в удаленном репозитории) из локального репозитория в репозиторий удаленный. Для исполнения этой команды необходимо, чтобы удаленный репозиторий не имел новых коммитов в себя от других клиентов, иначе push завершается ошибкой, и придётся делать pull и слияние.
Команда pull — обратна команде push. В случае, если одна и та же ветвь имеет независимую историю развития от какого-то момента в локальной и в удаленной копии, pull немедленно переходит к слиянию.
Слияние в пределах разных файлов осуществляется автоматически (все это поведение настраивается), а в пределах одного файла — стандартным трёхпанельным сравнением файлов. После слияния нужно объявить конфликты как разрешенные.
Результатом всего этого является новое состояние в локальных файлах у того разработчика, что осуществил слияние. Ему нужно немедленно сделать коммит, при этом в данном объекте коммита в репозитории окажется информация о том, что коммит есть результат слияния двух ветвей и имеет два родительских коммита.
Кроме слияния, git поддерживает ещё и rebase. Эта операция есть получение набора всех изменений в ветви А, с последующим их «накатом» на ветвь B. В результате ветвь B продвигается до состояния AB. В отличие от слияния, в истории ветви AB не останется никаких промежуточных коммитов ветви A (только история ветви B и запись о самом rebase, это упрощает интеграцию крупных и очень крупных проектов).
Также git имеет временный локальный индекс файлов. Это — промежуточное хранилище между собственно файлами и очередным коммитом (коммит делается только из этого индекса). С помощью этого индекса осуществляется добавление новых файлов (git add добавляет их в индекс, они попадут в следующий коммит), а также коммит НЕ ВСЕХ измененных файлов (коммит делается только тем файлам, которым был сделан git add). После git add можно редактировать файл далее, получатся три копии одного и того же файла — последняя, в индексе (та, что была на момент git add), и в последнем коммите.
Имя ветви по умолчанию: master.
Имя удаленного репозитория по умолчанию, создаваемое git clone во время типичной операции «взять имеющийся проект с какого-то сервера себе на машину»: origin.
Таким образом, в локальном репозитории всегда есть ветвь master, которая есть последний локальный коммит, и ветвь origin/master, которая есть последнее состояние удаленного репозитория на момент завершения исполнения последней команды pull или push.
Команда fetch (частичный pull) — берет с удаленного сервера все изменения в origin/master, и переписывает их в локальный репозиторий, продвигая метку origin/master.
Если после этого master и origin/master разошлись в стороны, то необходимо сделать слияние, установив master на результат слияния (команда pull есть fetch+merge). Далее возможно сделать push, отправив результат слияния на сервер и установив на него origin/master.
Детали реализации в Windows
В Windows версии (официальная Windows-версия называется mSysGit) используется пакет mSys — эмулятор POSIX-совместимой командной строки над Windows (производный от MinGW, примерный аналог Cygwin).
Под mSys перенесены все необходимые для git библиотеки и инструменты, а также сам git.
При работе с удаленными репозиториями по протоколу SSL будет использоваться хранилище сертификатов из mSys, а не из Windows.
Существует немало графических оболочек для Git, например, TortoiseGit. Все они реализованы через вызовы mSysGi и требуют его установки на машину. Не исключение и SourceTree, решение компании Atlassian, но mSysGit оно содержит внутри себя, что имеет свои плюсы и минусы (так установка в глубокую поддиректорию затрудняет добавление в mSys нужных SSL-сертификатов).
Сетевые возможности и серверные решения
git использует сеть только для операций обмена с удалёнными репозиториями.
Возможно использование следующих протоколов:
В последнем случае необходимо наличие на сервере некоего ПО веб-приложения, которое будет исполнять роль прослойки между командами git на сервере и HTTP-сервером. Такие прослойки существуют как под Linux, так и под Windows (например, WebGitNet, разработанный на ASP.NET MVC 4).
Кроме поддержки серверной стороны команд push и pull, такие веб-приложения могут также давать доступ только на чтение к репозиторию через веб-браузер.
Преимущества и недостатки
Преимущества и недостатки git по сравнению с централизованными системами управления версиями (такими как, например, Subversion) типичны для любой распределённой системы и описаны в статье «Система управления версиями». Если же сравнивать git с «родственными» ей распределёнными системами, можно отметить, что git изначально идеологически ориентирован на работу с изменениями, а не с файлами, «единицей обработки» для него является набор изменений, или патч. Эта особенность прослеживается как в структуре самой системы (в частности — в структуре репозитория), так и в принципах построения команд; она отражается на производительности системы в различных вариантах её использования и на достоинствах и недостатках git по сравнению с другими DVCS.
Часто называемые преимущества git перед другими DVCS:
В числе недостатков git обычно называют:
В ряде публикаций, относящихся преимущественно к 2005—2008 годам можно встретить также нарекания в отношении документации git, отсутствия удобной windows-версии и удобных графических клиентов. В настоящее время эта критика неактуальна: существует версия git на основе MinGW («родная» сборка под Windows), и несколько высококачественных графических клиентов для различных операционных систем, в частности, под Windows имеется клиент TortoiseGit, идеологически очень близкий к широко распространённому TortoiseSVN — клиенту SVN, встраиваемому в оболочку Windows.
Графические интерфейсы
Фронтенды для Web
| Название | Функции | Язык | Активность | Версия | Лицензия |
|---|---|---|---|---|---|
| GitWebAdmin | Управление репозиториями. | PHP | да | 1.0.1 (15 октября 2016) | MIT |
| GitLab | Просмотр репозитория и истории изменений, управление репозиториями. Права доступа. Система непрерывного тестирования | Ruby | да | 8.8.1 (23 мая 2016) | MIT |
| Gitblit | Просмотр репозитория и истории изменений, управление репозиториями. Права доступа | Java | да | 1.7.1 (23 ноября 2015) | Apache License 2.0 |
| Gerrit | Интеграция с репозиторием для организации совместной инспекции кода | Java | да | 2.12.2 (11 марта 2015) | Apache License 2.0 |
| Gitweb | Просмотр репозитория. Может работать как CGI скрипт в веб-сервере | Perl | да | поставляется с git | GPLv2 |
| cgit | Просмотр репозитория и истории изменений | C | да | 0.12 (14 января 2016) | GPLv2 |
| ViewGit | Просмотр репозитория и истории изменений | PHP | да | 0.0.7 (март 2013) | GNU AGPLv3 |
| GitList | Просмотр репозитория и истории изменений | PHP | нет | июль 2006 | New BSD license |
| git-php | Доработанная версия другого заброшенного проекта с одноимённым названием. | PHP | нет | 2011 | GPLv2 (?) |
| wit | . | Python | нет | 0.0.4 (сентябрь 2005) | GPLv2 |
| gitarella | Просмотр репозитория и истории изменений | Ruby | нет | 0.003 (июль 2006) | GPLv2 |
| Gogs | Просмотр репозитория и истории изменений, управление репозиториями. Права доступа | Go | да | 0.9.13 (19 марта 2016) | MIT License |
Обмен изменениями с другими системами контроля версий
Примечания
См. также
Другие распределённые системы управления версиями:
Сервисы, предоставляющие хостинг для git-репозиториев:
Git: полное руководство
Оглавление Базовые концепции Настройка среды Жизненный цикл Операция Create Операция Clone Perform изменения Review изменения Commit изменения Push операция Update…
Оглавление
Git – это распределенная система контроля версий и управления исходным кодом с упором на скорость. Первоначально Git был разработан и разработан Линусом Торвальдсом для разработки ядра Linux. Git – это бесплатное программное обеспечение, распространяемое в соответствии с условиями GNU General Public License версии 2. В этом руководстве объясняется, как использовать Git для управления версиями проекта в распределенной среде при разработке веб-приложений и приложений, не основанных на веб-технологиях.
Это руководство поможет новичкам изучить базовые функции системы контроля версий Git. После завершения этого руководства вы обнаружите, что обладаете умеренным опытом в использовании системы контроля версий Git, откуда вы сможете перейти на следующий уровень.
Мы предполагаем, что вы собираетесь использовать Git для обработки всех уровней Java и не-Java проектов. Так что будет хорошо, если у вас будет некоторое знакомство с жизненным циклом разработки программного обеспечения и практические знания по разработке веб-приложений и приложений, не основанных на Интернете.
Базовые концепции
Система контроля версий
Система контроля версий (VCS) – это программное обеспечение, которое помогает разработчикам программного обеспечения работать вместе и вести полную историю своей работы.
Ниже перечислены функции VCS –
Ниже приведены типы VCS –
В этой главе мы сосредоточимся только на распределенной системе контроля версий и особенно на Git. Git подпадает под распределенную систему контроля версий.
Распределенная система контроля версий
Централизованная система контроля версий (CVCS) использует центральный сервер для хранения всех файлов и обеспечивает совместную работу команды. Но главный недостаток CVCS – это ее единственная точка отказа, то есть отказ центрального сервера. К сожалению, если центральный сервер выйдет из строя на час, то в течение этого часа никто вообще не сможет сотрудничать. И даже в худшем случае, если диск центрального сервера будет поврежден и надлежащая резервная копия не будет сделана, вы потеряете всю историю проекта. Здесь на сцену выходит распределенная система контроля версий (DVCS).
Клиенты DVCS не только проверяют последний снимок каталога, но также полностью зеркалируют репозиторий. Если сервер выходит из строя, то репозиторий с любого клиента можно скопировать обратно на сервер, чтобы восстановить его. Каждая выписка – это полная резервная копия репозитория. Git не полагается на центральный сервер, и поэтому вы можете выполнять множество операций, когда находитесь в автономном режиме. Вы можете фиксировать изменения, создавать ветки, просматривать журналы и выполнять другие операции в автономном режиме. Сетевое подключение требуется только для публикации ваших изменений и принятия последних изменений.
Преимущества Git
1. Бесплатный и открытый исходный код
Git выпускается под лицензией GPL с открытым исходным кодом. Он доступен бесплатно в Интернете. Вы можете использовать Git для управления проектами недвижимости, не платя ни копейки. Поскольку это открытый исходный код, вы можете загрузить его исходный код, а также внести изменения в соответствии с вашими требованиями.
2. Быстрый и маленький
Поскольку большинство операций выполняется локально, это дает огромное преимущество с точки зрения скорости. Git не полагается на центральный сервер; поэтому нет необходимости взаимодействовать с удаленным сервером для каждой операции. Основная часть Git написана на C, что позволяет избежать накладных расходов времени выполнения, связанных с другими языками высокого уровня. Хотя Git отражает весь репозиторий, размер данных на стороне клиента невелик. Это демонстрирует эффективность Git при сжатии и хранении данных на стороне клиента.
3. Неявное резервное копирование
Шансы на потерю данных очень редки, если их несколько копий. Данные, присутствующие на любой стороне клиента, отражают репозиторий, поэтому их можно использовать в случае сбоя или повреждения диска.
4. Безопасность
Git использует общую криптографическую хеш-функцию, называемую защищенной хеш-функцией (SHA1), для именования и идентификации объектов в своей базе данных. Каждый файл и фиксация проверяются и извлекаются по контрольной сумме во время проверки. Это означает, что невозможно изменить файл, дату, сообщение фиксации и любые другие данные из базы данных Git, не зная Git.
5. Нет необходимости в мощном оборудовании
В случае CVCS центральный сервер должен быть достаточно мощным, чтобы обслуживать запросы всей команды. Для небольших команд это не проблема, но по мере роста размера команды аппаратные ограничения сервера могут стать узким местом для производительности. В случае DVCS разработчики не взаимодействуют с сервером, если им не нужно отправлять или извлекать изменения. Вся тяжелая работа выполняется на стороне клиента, поэтому серверное оборудование действительно может быть очень простым.
6. Более легкое ветвление
CVCS использует дешевый механизм копирования. Если мы создадим новую ветвь, она скопирует все коды в новую ветку, поэтому это требует много времени и неэффективно. Кроме того, удаление и объединение ветвей в CVCS сложно и требует много времени. Но управлять ветками с помощью Git очень просто. Создание, удаление и объединение веток занимает всего несколько секунд.
Терминология DVCS
Локальный репозиторий
Каждый инструмент VCS предоставляет частное рабочее место в качестве рабочей копии. Разработчики вносят изменения на своем рабочем месте, и после фиксации эти изменения становятся частью репозитория. Git делает еще один шаг вперед, предоставляя им частную копию всего репозитория. Пользователи могут выполнять множество операций с этим репозиторием, например добавлять файл, удалять файл, переименовывать файл, перемещать файл, фиксировать изменения и многое другое.
Рабочий каталог и промежуточная область или индекс
Рабочий каталог – это место, где файлы извлекаются. В других CVCS разработчики обычно вносят изменения и фиксируют свои изменения непосредственно в репозитории. Но Git использует другую стратегию. Git не отслеживает каждый измененный файл. Каждый раз, когда вы фиксируете операцию, Git ищет файлы в промежуточной области. Только те файлы, которые присутствуют в промежуточной области, рассматриваются для фиксации, а не все измененные файлы.
Давайте посмотрим на основной рабочий процесс Git.
Предположим, вы изменили два файла, а именно «sort.c» и «search.c», и вам нужно два разных коммита для каждой операции. Вы можете добавить один файл в промежуточную область и выполнить фиксацию. После первой фиксации повторите ту же процедуру для другого файла.
Блобы(Blobs)
Блоб означает большой двоичный объект. Каждая версия файла представлена большим двоичным объектом. Большой двоичный объект содержит данные файла, но не содержит метаданных о файле. Это двоичный файл, и в базе данных Git он называется хеш-кодом SHA1 этого файла. В Git к файлам не обращаются по именам. Все адресовано по содержанию.
Древо(Trees)
Древо – это объект, представляющий каталог. Он содержит блобы, а также другие подкаталоги. Древо – это двоичный файл, в котором хранятся ссылки на большие двоичные объекты и деревья, которые также называются хешем SHA1 объекта древа.
Коммиты(Commits)
Коммит содержит текущее состояние репозитория. Коммит также называется хешем SHA1. Вы можете рассматривать объект фиксации как узел связанного списка. Каждый объект фиксации имеет указатель на родительский объект фиксации. От заданной фиксации вы можете вернуться назад, посмотрев на родительский указатель, чтобы просмотреть историю фиксации. Если у фиксации есть несколько родительских коммитов, то эта конкретная фиксация была создана путем слияния двух ветвей.
Ветви(Branches)
Ветви используются для создания еще одной линии развития. По умолчанию у Git есть основная ветка, такая же, как и в Subversion. Обычно ветка создается для работы над новой функцией. Как только функция завершена, она снова объединяется с основной веткой, и мы удаляем ветку. На каждую ветку ссылается HEAD, который указывает на последнюю фиксацию в ветке. Каждый раз, когда вы делаете коммит, HEAD обновляется последней фиксацией.
Теги(Tags)
Тег присваивает значимое имя определенной версии в репозитории. Теги очень похожи на ветки, но разница в том, что теги неизменяемы. Значит, тег – это ветка, которую никто не собирается изменять. После создания тега для конкретной фиксации, даже если вы создаете новую фиксацию, он не будет обновлен. Обычно разработчики создают теги для выпусков продуктов.
Клонировать(Clone)
Операция клонирования создает экземпляр репозитория. Операция клонирования не только проверяет рабочую копию, но также отражает весь репозиторий. Пользователи могут выполнять множество операций с этим локальным репозиторием. Единственный раз, когда в сеть включается, – это когда экземпляры репозитория синхронизируются.
Операция Pull копирует изменения из экземпляра удаленного репозитория в локальный. Операция Pull используется для синхронизации между двумя экземплярами репозитория. Это то же самое, что и операция обновления в Subversion.
Операция push копирует изменения из экземпляра локального репозитория в удаленный. Это используется для постоянного хранения изменений в репозитории Git. Это то же самое, что и операция фиксации в Subversion.
HEAD – это указатель, который всегда указывает на последнюю фиксацию в ветке. Каждый раз, когда вы делаете коммит, HEAD обновляется последней фиксацией. Головы веток хранятся в каталоге .git/refs/heads/
Revision
Revision представляет собой версию исходного кода. Редакции в Git представлены коммитами. Эти коммиты идентифицируются безопасными хэшами SHA1.
URL-адрес представляет собой расположение репозитория Git. URL-адрес Git хранится в файле конфигурации.
Настройка среды
Прежде чем вы сможете использовать Git, вам необходимо установить и внести некоторые базовые изменения конфигурации. Ниже приведены шаги по установке клиента Git в Ubuntu и Centos Linux.
Установка клиента Git
Если вы используете базовый дистрибутив Debian GNU/Linux, то команда apt-get сделает все необходимое.
И если вы используете дистрибутив GNU / Linux на основе RPM, используйте команду yum, как указано.
Настройка среды Git
Вы также можете настроить общесистемную конфигурацию. Git хранит эти значения в файле /etc/gitconfig, который содержит конфигурацию для каждого пользователя и репозитория в системе. Чтобы установить эти значения, вы должны иметь права root и использовать параметр –system.
Когда приведенный выше код компилируется и выполняется, он дает следующий результат:
Установка имени пользователя
Эта информация используется Git для каждого commit.
Установка идентификатора электронной почты
Эта информация используется Git для каждого commit.
Избегайте слияния коммитов для pulling
Вы делаете pull последних изменений из удаленного репозитория, и если эти изменения расходятся, то по умолчанию Git создает коммиты слияния. Этого можно избежать с помощью следующих настроек.
Цветовое выделение
Следующие команды включают выделение цветом для Git в консоли.
Установка редактора по умолчанию
По умолчанию Git использует системный редактор по умолчанию, который берется из переменной среды VISUAL или EDITOR. Мы можем настроить другой, используя git config.
Установка инструмента merge по умолчанию
Git не предоставляет инструмент merge по умолчанию для интеграции конфликтующих изменений в ваше рабочее древо. Мы можем установить инструмент merge по умолчанию, включив следующие настройки.
Вывод настроек Git
Чтобы проверить настройки Git в локальном репозитории, используйте команду git config –list, как показано ниже.
Приведенная выше команда даст следующий результат.
Жизненный цикл
В этой главе мы обсудим жизненный цикл Git. В следующих главах мы рассмотрим команды Git для каждой операции.
Общий рабочий процесс выглядит следующим образом –
Ниже показано графическое изображение рабочего процесса.
Операция Create
В этой главе мы увидим, как создать удаленный репозиторий Git; с этого момента мы будем называть его Git Server. Нам нужен сервер Git для совместной работы команды.
Создать нового пользователя
Приведенная выше команда даст следующий результат.
Создать пустой репозиторий
Создание пары ключей RSA Public / Private RSA
Давайте рассмотрим процесс настройки Git-сервера, утилита ssh-keygen генерирует пару публичных / частных ключей RSA, которые мы будем использовать для аутентификации пользователя.
Приведенная выше команда даст следующий результат.
ssh-keygen сгенерировал два ключа, первый из которых является частным (т.е. id_rsa), а второй – открытым (т.е. id_rsa.pub).
Примечание. Никогда не сообщайте свой ЧАСТНЫЙ КЛЮЧ другим людям.
Добавление ключей в authorized_keys
Предположим, что над проектом работают два разработчика, а именно Том и Джерри. Оба пользователя сгенерировали открытые ключи. Давайте посмотрим, как использовать эти ключи для аутентификации.
Том добавил свой открытый ключ на сервер с помощью команды ssh-copy-id, как показано ниже –
Приведенная выше команда даст следующий результат.
Точно так же Джерри добавил свой открытый ключ на сервер с помощью команды ssh-copy-id.
Приведенная выше команда даст следующий результат.
Отправление изменений в репозиторий
Мы создали чистый репозиторий на сервере и разрешили доступ двум пользователям. С этого момента Том и Джерри могут отправлять свои изменения в репозиторий, добавляя его как дистанционный.
Том создает новый каталог, добавляет файл README и фиксирует свое изменение как начальную фиксацию. После фиксации он проверяет сообщение фиксации, выполнив команду git log.
Приведенная выше команда даст следующий результат.
Том проверяет сообщение журнала, выполнив команду git log.
Приведенная выше команда даст следующий результат.
Том зафиксировал свои изменения в локальном репозитории. Теперь пришло время отправить изменения в удаленный репозиторий. Но перед этим надо добавить репозиторий как пульт, это разовая операция. После этого он может безопасно отправить изменения в удаленный репозиторий.
Примечание. По умолчанию Git отправляет только соответствующие ветки: для каждой ветки, которая существует на локальной стороне, удаленная сторона обновляется, если ветка с таким же именем уже существует там. В наших руководствах каждый раз, когда мы отправляем изменения в исходную главную ветку, используйте соответствующее имя ветки в соответствии с вашими требованиями.
Приведенная выше команда даст следующий результат.
Теперь изменения успешно зафиксированы в удаленном репозитории.
Операция Clone
У нас есть пустой репозиторий на сервере Git, и Том также выпустил свою первую версию. Теперь Джерри может просматривать свои изменения. Операция Clone создает экземпляр удаленного репозитория.
Джерри создает новый каталог в своем домашнем каталоге и выполняет операцию клонирования.
Приведенная выше команда даст следующий результат.
Джерри меняет каталог на новый локальный репозиторий и перечисляет его содержимое.
Perform изменения
Джерри клонирует репозиторий и решает реализовать основные строковые операции. Итак, он создает файл string.c. После добавления содержимого string.c будет выглядеть следующим образом:
Он скомпилировал и протестировал свой код, и все работает нормально. Теперь он может безопасно добавить эти изменения в репозиторий.
Операция Git add добавляет файл в область подготовки.
Git показывает вопросительный знак перед именами файлов. Очевидно, что эти файлы не являются частью Git, и именно поэтому Git не знает, что с этими файлами делать. Вот почему Git показывает вопросительный знак перед именами файлов.
Джерри добавил файл в область хранения, команда git status покажет файлы, присутствующие в области подготовки.
Чтобы зафиксировать изменения, он использовал команду git commit с опцией –m. Если мы опускаем опцию –m. Git откроет текстовый редактор, в котором мы можем написать многострочное сообщение commit.
Приведенная выше команда даст следующий результат –
После commit для просмотра сведений журнала он запускает команду git log. Он будет отображать информацию обо всех коммитах с их commit ID, commit author, commit date и хешем SHA-1 фиксации.
Приведенная выше команда даст следующий результат –
Review изменения
После просмотра деталей фиксации Джерри понимает, что длина строки не может быть отрицательной, поэтому он решает изменить тип возвращаемого значения функции my_strlen.
Джерри использует команду git log для просмотра деталей журнала.
Приведенная выше команда даст следующий результат.
Джерри использует команду git show для просмотра деталей коммита. Команда git show принимает в качестве параметра идентификатор фиксации SHA-1.
Приведенная выше команда даст следующий результат –
Он меняет тип возвращаемого значения функции с int на size_t. После тестирования кода он проверяет свои изменения, выполнив команду git diff.
Приведенная выше команда даст следующий результат –
Git diff показывает знак «+» перед новыми добавленными строками и «-» для удаленных строк.
Commit изменения
Джерри уже зафиксировал изменения и хочет исправить свой последний коммит. В этом случае поможет операция git 180. Операция изменения изменяет последний коммит, включая ваше сообщение коммита; он создает новый идентификатор коммита.
Перед операцией изменения он проверяет журнал коммита.
Приведенная выше команда даст следующий результат.
Теперь git log покажет новое сообщение коммита с новым идентификатором commit ID –
Приведенная выше команда даст следующий результат.
Push операция
Джерри изменил свой последний коммит, используя операцию amend, и он готов отправить(push) изменения. Операция Push сохраняет данные постоянно в репозитории Git. После успешной операции отправки другие разработчики смогут увидеть изменения Джерри.
Он выполняет команду git log, чтобы просмотреть детали коммита.
Приведенная выше команда даст следующий результат:
Перед операцией push он хочет просмотреть свои изменения, поэтому он использует команду git show для просмотра своих изменений.
Приведенная выше команда даст следующий результат:
Джерри доволен своими изменениями, и он готов отправить свои изменения.
Приведенная выше команда даст следующий результат:
Изменения Джерри были успешно отправлены в репозиторий; теперь другие разработчики могут просматривать его изменения, выполняя операцию клонирования или обновления.
Update операция
Изменение существующущей функции
Том выполняет операцию клонирования и находит новый файл string.c. Он хочет знать, кто добавил этот файл в репозиторий и с какой целью, поэтому он выполняет команду git log.
Приведенная выше команда даст следующий результат –
Операция Clone создаст новый каталог внутри текущего рабочего каталога. Он меняет каталог на вновь созданный каталог и выполняет команду git log.
Приведенная выше команда даст следующий результат –
После просмотра журнала он понимает, что файл string.c был добавлен Джерри для реализации основных строковых операций. Ему интересно узнать код Джерри. Итак, он открывает string.c в текстовом редакторе и сразу находит ошибку. В функции my_strlen Джерри не использует постоянный указатель. Итак, он решает изменить код Джерри. После модификации код выглядит следующим образом –
Приведенная выше команда даст следующий результат –
После тестирования он делает коммит своего изменения.
Приведенная выше команда даст следующий результат –
Приведенная выше команда даст следующий результат –
Добавить новую функцию
Тем временем Джерри решает реализовать функцию сравнения строк. Итак, он модифицирует string.c. После модификации файл выглядит следующим образом –
Приведенная выше команда даст следующий результат –
После тестирования он готов внести свои изменения.
Перед операцией push он проверяет фиксацию, просматривая сообщения журнала.
Приведенная выше команда даст следующий результат –
Джерри доволен изменениями, и он хочет их отправить.
Приведенная выше команда даст следующий результат –
Но Git не позволяет Джерри отправить свои изменения. Потому что Git определил, что удаленный репозиторий и локальный репозиторий Джерри не синхронизированы. Из-за этого он может потерять историю проекта. Чтобы избежать этого беспорядка, Git провалил эту операцию. Теперь Джерри должен сначала обновить локальный репозиторий, и только после этого он сможет внести свои изменения.
Получить последние изменения
Джерри выполняет команду git pull для синхронизации своего локального репозитория с удаленным.
Приведенная выше команда даст следующий результат –
После операции pull, Джерри проверяет сообщения журнала и находит сведения о commit Тома с commit ID cea2c000f53ba99508c5959e3e12fff493ba6f69.
Приведенная выше команда даст следующий результат –
Теперь локальный репозиторий Джерри полностью синхронизирован с удаленным репозиторием. Так что он может спокойно отправлять свои изменения.
Приведенная выше команда даст следующий результат –
Stash операция
Предположим, вы внедряете новую функцию для своего продукта. Ваш код находится в разработке, и внезапно приходит эскалация клиентов. Из-за этого вам придется отложить работу над новой функцией на несколько часов. Вы не можете сделать коммит своего частичного кода, а также не можете выбросить свои изменения. Поэтому вам нужно временное пространство, где вы можете сохранить свои частичные изменения, а затем сделать их коммит.
В Git операция stash берет ваши измененные отслеживаемые файлы, обрабатывает изменения и сохраняет их в стеке незавершенных изменений, которые вы можете повторно применить в любое время.
Теперь вы хотите сменить ветвь для эскалации клиентов, но не хотите делать коммит того, над чем еще работали; так что вы сохраните изменения. Чтобы отправить новый stash в свой стек, выполните команду git stash.
Теперь ваш рабочий каталог чист, и все изменения сохранены в стеке. Давайте проверим это с помощью команды git status.
Теперь вы можете смело переключать ветку и работать в другом месте. Мы можем просмотреть список сохраненных изменений, используя команду git stash list.
Предположим, вы разрешили проблему эскалации клиентов и вернулись к своей новой функции в поисках своего недоделанного кода, просто выполните команду git stash pop, чтобы удалить изменения из стека и поместить их в текущий рабочий каталог.
Приведенная выше команда даст следующий результат:
Move операция
Как следует из названия, операция move перемещает каталог или файл из одного места в другое. Том решает переместить исходный код в каталог src. Измененная структура каталогов будет выглядеть следующим образом –
Чтобы сделать эти изменения постоянными, мы должны отправить измененную структуру каталогов в удаленный репозиторий, чтобы другие разработчики могли это увидеть.
В локальном репозитории Джерри перед операцией pull будет показана старая структура каталогов.
Но после операции извлечения структура каталогов обновится. Теперь Джерри может видеть каталог src и файл, находящийся внутри этого каталога.
Rename операция
До сих пор и Том, и Джерри использовали ручные команды для компиляции своего проекта. Теперь Джерри решает создать Makefile для своего проекта, а также присвоить файлу собственное имя «string.c».
Git показывает R перед именем файла, чтобы указать, что файл был переименован.
После коммита он отправляет свои изменения в репозиторий.
Приведенная выше команда даст следующий результат –
Теперь другие разработчики могут просматривать эти изменения, обновляя свой локальный репозиторий.
Delete операция
Том обновляет свой локальный репозиторий и находит скомпилированный двоичный файл в каталоге src. После просмотра сообщения о фиксации он понимает, что скомпилированный двоичный файл был добавлен Джерри.
VCS используется для хранения только исходного кода, а не исполняемых двоичных файлов. Итак, Том решает удалить этот файл из репозитория. Для дальнейшей работы он использует команду git rm.
После коммита он отправляет свои изменения в репозиторий.
Приведенная выше команда даст следующий результат.
Исправление ошибок
Человеку свойственно ошибаться. Таким образом, каждая VCS предоставляет возможность исправлять ошибки до определенного момента. Git предоставляет функцию, которую мы можем использовать для отмены изменений, внесенных в локальный репозиторий.
Предположим, пользователь случайно внес некоторые изменения в свой локальный репозиторий, а затем хочет отменить эти изменения. В таких случаях важную роль играет операция возврата(revert).
Отмена незафиксированных изменений
Предположим, Джерри случайно изменяет файл из своего локального репозитория. Но он хочет отменить свою модификацию. Чтобы справиться с этой ситуацией, мы можем использовать команду git checkout. Мы можем использовать эту команду, чтобы вернуть содержимое файла.
Кроме того, мы можем использовать команду git checkout для получения удаленного файла из локального репозитория. Предположим, Том удаляет файл из локального репозитория, и мы хотим вернуть этот файл. Мы можем добиться этого, используя ту же команду.
Git показывает букву D перед именем файла. Это означает, что файл был удален из локального репозитория.
Примечание. Мы можем выполнить все эти операции до коммита.
Удаление изменений из промежуточной области
Мы видели, что когда мы выполняем операцию добавления, файлы перемещаются из локального репозитория в указанную область. Если пользователь случайно изменяет файл и добавляет его в промежуточную область, он может отменить свои изменения с помощью команды git checkout.
В Git есть один указатель HEAD, который всегда указывает на последний коммит. Если вы хотите отменить изменение в поэтапной области, вы можете использовать команду git checkout, но с командой checkout вы должны указать дополнительный параметр, то есть указатель HEAD. Дополнительный параметр указателя коммита указывает команде git checkout сбросить рабочее древо, а также удалить поэтапные изменения.
Предположим, Том изменяет файл из своего локального репозитория. Если мы просмотрим статус этого файла, он покажет, что файл был изменен, но не добавлен в область подготовки.
Статус Git показывает, что файл присутствует в промежуточной области, теперь верните его, используя команду git checkout, и просмотрите статус возвращенного файла.
Перемещение указателя HEAD с помощью Git Reset
Сделав несколько изменений, вы можете решить удалить эти изменения. Команда сброса Git используется для сброса или отмены изменений. Мы можем выполнить три различных типа операций сброса.
На диаграмме ниже показано графическое представление команды сброса Git.
Каждая ветка имеет указатель HEAD, указывающий на последнюю фиксацию. Если мы используем команду сброса Git с параметром –soft, за которым следует commit ID, тогда он сбросит только указатель HEAD, ничего не разрушая.
Теперь просмотрите последний commit ID, который будет соответствовать указанному выше commit ID.
Приведенная выше команда даст следующий результат.
Сбросим указатель HEAD.
Commit ID из файла изменен, теперь проверьте его, просмотрев сообщения коммита.
Приведенная выше команда даст следующий результат.
mixed
Git reset с параметром –mixed отменяет те изменения из промежуточной области, которые еще не были зафиксированы. Он отменяет изменения только из области подготовки. Фактические изменения, внесенные в рабочую копию файла, не затрагиваются. Сброс Git по умолчанию эквивалентен сбросу git – смешанному.
Если вы используете опцию –hard с командой сброса Git, она очистит промежуточную область; он сбросит указатель HEAD на последний коммит конкретного идентификатора фиксации и также удалит изменения локального файла.
Давайте проверим commit ID.
Приведенная выше команда даст следующий результат.
Джерри изменил файл, добавив однострочный комментарий в начале файла.
Он проверил это с помощью команды git status.
Приведенная выше команда даст следующий результат.
Статус Git показывает, что файл присутствует в промежуточной области. Теперь сбросьте HEAD с опцией – hard.
Команда сброса Git выполнена успешно, которая вернет файл из промежуточной области, а также удалит все локальные изменения, внесенные в файл.
Статус Git показывает, что файл был возвращен из промежуточной области.
Команда head также показывает, что операция сброса также удалила локальные изменения.
Tag операция
Операция Tag позволяет дать осмысленные имена конкретной версии в репозитории. Предположим, Том и Джерри решили пометить код своего проекта, чтобы впоследствии легко получить к нему доступ.
Создание тэгов
Если вы хотите пометить конкретный коммит, используйте соответствующий идентификатор COMMIT вместо указателя HEAD. Том использует следующую команду, чтобы поместить тег в удаленный репозиторий.
Приведенная выше команда даст следующий результат –
Просмотр тегов
Том создал теги. Теперь Джерри может просматривать все доступные теги, используя команду Git tag с параметром –l.
Джерри использует команду Git show, за которой следует имя тега, чтобы просмотреть дополнительные сведения о теге.
Приведенная выше команда даст следующий результат –
Удаление тегов
Том использует следующую команду для удаления тегов как из локального, так и из удаленного репозитория.
Patch операция
Patch – это текстовый файл, содержимое которого похоже на Git diff, но вместе с кодом в нем также есть метаданные о коммитах; например, commit ID, дата, сообщение коммита и т. д. Мы можем создать патч из коммитов, и другие люди могут применить их к своему репозиторию.
Джерри реализует функцию strcat для своего проекта. Джерри может создать путь своего кода и отправить его Тому. Затем он может применить полученный патч к своему коду.
Джерри использует команду Git format-patch для создания патча для последней фиксации. Если вы хотите создать патч для конкретной фиксации, используйте COMMIT_ID с командой format-patch.
Чтобы применить патч и создать коммит, используйте следующую команду –
Патч успешно применен, теперь мы можем просмотреть изменения с помощью команды git diff.
Приведенная выше команда даст следующий результат –
Управление ветвями
Операция Branch позволяет создать еще одно направление развития. Мы можем использовать эту операцию, чтобы разделить процесс разработки на два разных направления. Например, мы выпустили продукт для версии 6.0, и мы могли бы захотеть создать ветку, чтобы разработка функций 7.0 могла быть отделена от исправлений ошибок 6.0.
Создание ветки
Создана новая ветка; Том использовал команду git branch, чтобы вывести список доступных веток. Git показывает звездочку перед выбранной веткой.
Наглядное представление операции создания ветки показано ниже –
Переключение между ветками
Джерри использует команду git checkout для переключения между ветвями.
Ярлык для создания и переключения ветки
В приведенном выше примере мы использовали две команды для создания и переключения ветвей соответственно. Git предоставляет параметр –b с командой checkout; эта операция создает новую ветку и немедленно переключается на новую ветку.
Удаление ветки
Ветку можно удалить, указав параметр –D с командой git branch. Но перед удалением существующей ветки переключитесь на другую ветку.
Джерри в настоящее время находится на test_branch и хочет удалить эту ветку. Поэтому он переключает ветку и удаляет ветку, как показано ниже.
Теперь Git покажет только две ветки.
Переименовывание ветки
Джерри решает добавить поддержку широких символов в свой проект строковых операций. Он уже создал новую ветку, но имя ветки не подходит. Поэтому он меняет имя ветки, используя параметр –m, за которым следует имя старой ветки и имя новой ветки.
Теперь команда git branch покажет новое имя ветки.
Объединие двух ветвей
Джерри реализует функцию для возврата длины строки из строки широких символов. Новый код будет выглядеть следующим образом –
Приведенная выше команда дает следующий результат –
После тестирования он делает коммит и помещает свои изменения в новую ветку.
Обратите внимание, что Джерри переносит эти изменения в новую ветку, поэтому он использовал имя ветки wchar_support вместо главной ветки.
Приведенная выше команда даст следующий результат.
После фиксации изменений новая ветка будет выглядеть следующим образом –
Тому интересно, что делает Джерри в своей частной ветке, и он проверяет журнал ветки wchar_support.
Приведенная выше команда даст следующий результат.
Просматривая сообщения коммита, Том понимает, что Джерри реализовал функцию strlen для широких символов и ему нужна такая же функциональность в главной ветви. Вместо повторной реализации он решает взять код Джерри, объединив свою ветку с основной веткой.
После операции слияния главная ветвь будет выглядеть следующим образом:
Теперь ветка wchar_support объединена с главной ветвью. Мы можем проверить это, просмотрев сообщение о фиксации или просмотрев изменения, внесенные в файл string_operation.c.
Приведенная выше команда даст следующий результат.
После тестирования он отправляет свои изменения кода в основную ветку.
Перебазировать ветви
Команда Git rebase – это команда слияния веток, но разница в том, что она изменяет порядок коммитов.
Команда Git merge пытается поместить коммиты из других веток поверх HEAD текущей локальной ветки. Например, ваша локальная ветка имеет коммиты A-> B-> C-> D, а ветвь слияния имеет коммиты A-> B-> X-> Y, тогда git merge преобразует текущую локальную ветвь во что-то вроде A-> B-> C-> D-> X-> Y
Команда Git rebase пытается найти общего предка между текущей локальной веткой и ветвью слияния. Затем он отправляет коммиты в локальную ветвь, изменяя порядок коммитов в текущей локальной ветке. Например, если ваша локальная ветка имеет коммиты A-> B-> C-> D, а ветвь слияния имеет коммиты A-> B-> X-> Y, то Git rebase преобразует текущую локальную ветку во что-то вроде A- > B-> X-> Y-> C-> D.
Когда несколько разработчиков работают с одним удаленным репозиторием, вы не можете изменить порядок коммитов в удаленном репозитории. В этой ситуации вы можете использовать операцию rebase, чтобы поместить ваши локальные коммиты поверх коммитов удаленного репозитория, и вы можете отправить эти изменения.
Разрешение конфликтов
Внесение изменений в ветку wchar_support
Джерри работает над веткой wchar_support. Он меняет название функций и после тестирования делает коммит своих изменений.
Приведенная выше команда дает следующий результат –
После проверки кода он фиксирует свои изменения.
Приведенная выше команда даст следующий результат –
Выполнение изменений в главной ветви
Тем временем в главной ветке Том также меняет имя той же функции и передает свои изменения в главную ветку.
Приведенная выше команда дает следующий результат –
После проверки diff он фиксирует свои изменения.
Приведенная выше команда даст следующий результат –
В ветви wchar_support Джерри реализует функцию strchr для строки широких символов. После тестирования он фиксирует и отправляет свои изменения в ветку wchar_support.
Приведенная выше команда дает следующий результат –
После проверки он фиксирует свои изменения.
Приведенная выше команда даст следующий результат –
Разрешение конфликтов
Том хочет увидеть, что Джерри делает в своей частной ветке, поэтому он пытается получить последние изменения из ветки wchar_support, но Git прерывает операцию со следующим сообщением об ошибке.
Приведенная выше команда дает следующий результат –
Как разрешить конфликты
Из сообщения об ошибке видно, что существует конфликт в src/string_operations.c. Он запускает команду git diff, чтобы просмотреть дополнительные сведения.
Приведенная выше команда дает следующий результат –
Поскольку и Том, и Джерри изменили имя одной и той же функции, Git находится в замешательстве и просит пользователя разрешить конфликт вручную.
Том решает сохранить имя функции, предложенное Джерри, но оставил комментарий, добавленный им, как есть. После удаления маркеров конфликта git diff будет выглядеть так.
Приведенная выше команда дает следующий результат.
Поскольку Том изменил файлы, он должен сначала зафиксировать эти изменения, а после этого он сможет их извлечь.
Том разрешил конфликт, теперь операция извлечения завершится успешно.
Разные платформы
РУССКИЙGNU / Linux и Mac OS используют перевод строки (LF) или новую строку в качестве символа конца строки, тогда как Windows использует комбинацию перевода строки и возврата каретки (LFCR) для представления символа конца строки.
Чтобы избежать ненужных коммитов из-за этих различий в конце строки, мы должны настроить клиент Git для записи того же окончания строки в репозиторий Git.
Для системы Windows мы можем настроить клиент Git для преобразования окончаний строк в формат CRLF при извлечении и преобразования их обратно в формат LF во время операции фиксации. Следующие настройки сделают необходимое.
Для GNU / Linux или Mac OS мы можем настроить клиент Git для преобразования окончаний строк из CRLF в LF при выполнении операции проверки.
Интернет-репозитории
GitHub – это веб-хостинг для проектов разработки программного обеспечения, использующий систему контроля версий Git. Он также имеет стандартное приложение с графическим интерфейсом, доступное для загрузки (Windows, Mac, GNU / Linux) непосредственно с веб-сайта службы. Но в этом сеансе мы увидим только часть CLI.
Создание репозитория GitHub
Зайдите на github.com. Если у вас уже есть учетная запись GitHub, войдите с помощью этой учетной записи или создайте новую. Следуйте инструкциям на сайте github.com, чтобы создать новый репозиторий.
Push операция
Том решает использовать сервер GitHub. Чтобы начать новый проект, он создает новый каталог и один файл внутри него.
Приведенная выше команда даст следующий результат:
После проверки своего кода он инициализирует каталог с помощью команды git init и фиксирует свои изменения локально.
После этого он добавляет URL-адрес репозитория GitHub в качестве удаленного источника и отправляет свои изменения в удаленный репозиторий.
Операция push запросит имя пользователя и пароль GitHub. После успешной аутентификации операция завершится успешно.
Приведенная выше команда даст следующий результат:
С этого момента Том может отправлять любые изменения в репозиторий GitHub. Он может использовать все команды, обсуждаемые в этой главе, с репозиторием GitHub.
Pull операция
Том успешно отправил все свои изменения в репозиторий GitHub. Теперь другие разработчики могут просмотреть эти изменения, выполнив операцию клонирования или обновив свой локальный репозиторий.
Джерри создает новый каталог в своем домашнем каталоге и клонирует репозиторий GitHub с помощью команды git clone.
Приведенная выше команда дает следующий результат:
Он проверяет содержимое каталога, выполняя команду ls.
