Что такое git в программировании
Перейти к содержимому

Что такое git в программировании

  • автор:

Что такое Git и для чего он нужен

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

  • Какие задачи решает контроль версий
  • Как работает контроль версий
  • Какие бывают системы контроля версий
  • Первое поколение
  • Второе поколение
  • Третье поколение
  • Заключение
  • Дополнительные ссылки

Какие задачи решает контроль версий

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

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

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

Представьте, что ваш проект состоит из сотни файлов и десятков тысяч строк кода. Вы делаете какую-то задачу, в процессе меняете 15 файлов и 300 строк кода и вдруг становится понятно, что эта задача больше не актуальна. На этом моменте нужно вернуться к состоянию исходного кода, которое было до изменений. И это только один из множества вариантов событий. Другой вариант — в процессе работы над кодом стало понятно, что нужно срочно внести исправление в рабочий проект (сайт). Новую задачу в нерабочем состоянии выкладывать на сайт нельзя, а это значит, что исправление нужно вносить в ту версию кода, которая была до начала реализации новой задачи.

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

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

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

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

В этом руководстве мы разберём общие принципы работы подобных программ.

Как работает контроль версий

Системы контроля версий (СКВ или VCS — Version Control System) часто встроены в инструменты, привычные даже далёким от программирования людям. Именно с них мы и начнём своё знакомство, а заодно погрузимся в соответствующую терминологию.

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

dropbox, история версий

На картинке выше текущая версия файла обозначена как current. Всё остальное — это предыдущие версии текущего файла. Как видно, Dropbox позволяет восстановить любую версию файла.

Обратите внимание на эту фразу:

Dropbox keeps a snapshot every time you save a file. (Дропбокс сохраняет снимок каждый раз, когда вы сохраняете файл)

Снимок (snapshot; разг. снепшот) — очень важное понятие, которое будет встречаться нам в будущем. Его ещё называют снимком состояния или даже мгновенным снимком (буквальный перевод), но для простоты будем называть его просто «снимок».

В данном случае, снимок — это сам файл после изменения. И чтобы лучше понять этот термин, посмотрим на альтернативу — дельту изменения (diff). Представьте, что вместо сохранения новой версии файла Dropbox бы вычислял разницу между новым и старым файлом (а это не сложно сделать для текстовых файлов) и сохранял только её. Зачем так делать, спросите вы? Такой подход позволяет сэкономить место на диске, хотя и вносит дополнительную сложность при работе с файлами.

В дальнейшем мы увидим, что разные инструменты используют разные подходы: некоторые работают с дельтой изменений, другие — со снимками. Кстати, термин «снимок» часто применяют к дискам. Например, можно сделать снимок диска и потом восстанавливаться с этой точки (прямо как в играх).

Другим хорошим примером использования контроля версий являются текстовые редакторы, в первую очередь онлайновые.

google docs, история версий

Сервис Google Docs автоматически делает снимки после каждого автосохранения (примерно раз в 5 секунд). Если документ за это время не изменился, то, естественно, новая версия не появляется. Множество таких версий образуют историю изменений.

На картинке выше история версий называется «Revision history». Ревизия — базовое понятие систем контроля версий. Любое зафиксированное изменение в системе контроля версий называется ревизией.

Обратите внимание на то, что ревизия и снимок — это не одно и то же. Фиксация изменений создаёт ревизию, но сама ревизия может содержать внутри себя либо дельту изменений, либо снимок.

Кстати, процесс переключения между ревизиями также имеет своё название. Когда мы загружаем конкретную ревизию, то говорят, что переключаемся на неё (checkout).

редактор, схема ревизий

Между ревизиями можно выявлять различия в случае, если СКВ использует снимки, что демонстрирует нам Microsoft Word на картинке выше. Эту функциональность невозможно переоценить,поскольку посмотреть «а что же изменилось» требуется постоянно не только при работе с кодом. Приведу пример из собственной практики: согласование разных юридических документов (договоров) происходит сквозь череду правок. После того, как юристы поправили договор, хочется увидеть, а что же там изменилось.

Более того, в системах Linux есть команда diff, с помощью которой можно выяснить различия между любыми файлами даже без использования СКВ. Эти изменения можно сохранить в файл, а затем, используя программу patch, применить к исходному файлу.

diff index.js index2.js > index.patch 1c1  const a = 5; --- > const a = 8; 3a4 > console.log (a - b ); patch index.js -i index.patch -o index2.js 

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

  • Сохранение.
  • Автосохранение.
  • По кнопке (команде).

Последнее используется уже при работе с кодом.

Какие бывают системы контроля версий

Во всех предыдущих примерах мы рассматривали СКВ, встроенные прямо в программы, в частности, в текстовые редакторы. А СКВ для исходного кода отделены от используемых средств разработки (хотя могут быть дополнительно интегрированы с ними).

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

В СКВ для кода процесс создания ревизии называется фиксацией (commit; разг. коммит). На работе вы будете часто слышать фразу «закоммитишь?» или «я закоммитил». Более того, обычно, вместо слова «ревизия» употребляют слово «коммит». И мы тоже так будем делать.

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

  • Хорошее описание. Как правило, оно начинается кратким однострочным заголовком не более 50 символов, после которого, через пустую строку, следует более детальный поясняющий текст, если он требуется. Обратите внимание, что хорошим тоном является использование повелительного наклонения в заголовке: «Fix scrolling» (Исправить прокрутку), а не «Fixed scrolling» (Исправлена прокрутка) или «Fixes scrolling» (Исправляет прокрутку).
  • Атомарность. Коммит должен решать одну задачу и желательно от начала до конца. Это позволит построить такую историю проекта, которую легко читать и понимать. А в случае необходимости можно легко откатить изменение или перенести его в другую версию программы.

Кроме этих базовых, существует и множество других рекомендаций входящих в понятие «хороший коммит».

Какие бы вы не использовали СКВ, базовый рабочий процесс один. Выглядит он так:

  1. Инициализация (создание) репозитория.
  2. Добавление новых файлов.
  3. Коммит.
  4. Любые операции с файлами (добавление, удаление или изменение).
  5. Коммит.
  6. .

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

СКВ принято делить на поколения, каждое из которых сильно изменяло подходы к работе.

Первое поколение

  • Работали с каждым файлом индивидуально.
  • Только локальная работа.

системы контроля версий, первое поколение

Второе поколение

CVS, SourceSafe, Subversion

  • Многофайловые.
  • Централизованные.
  • Требуют наличия сервера.

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

системы контроля версий, второе поколение

Третье поколение

Git, Bazaar, Mercurial

  • Распределённые.
  • У каждого участника свой полноценный локальный репозиторий.

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

системы контроля версий, третье поколение

Заключение

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

Что такое Git?

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

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

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

A staggering number of software projects rely on Git for version control, including commercial projects as well as open source. Developers who have worked with Git are well represented in the pool of available software development talent and it works well on a wide range of operating systems and IDEs (Integrated Development Environments).

Having a distributed architecture, Git is an example of a DVCS (hence Distributed Version Control System). Rather than have only one single place for the full version history of the software as is common in once-popular version control systems like CVS or Subversion (also known as SVN), in Git, every developer’s working copy of the code is also a repository that can contain the full history of all changes.

In addition to being distributed, Git has been designed with performance, security and flexibility in mind.

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

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

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

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

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

Настройка рабочей среды

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

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

Для работы с репозиторием удобно использовать разные ветки. Если коммиты можно сравнить с путешествием во времени, то ветки — это альтернативные реальности, в каждой из которых репозиторий развивается по своему особому пути. Например, отдельные разработчки могут использовать индивидуальные ветки для независимой работы друг от друга, а когда чья-то работа будет закончена, вмерджить (влить) изменения в общую ветку. В нашем курсе у репозиториев по две ветки: одна рабочая, в которой можно сохранять промежуточные результаты (ветка master), и ветка solution, в которую надо будет влить в решение задачи для проверки преподавателем.

Подробнее о том, как сдавать задания с помощью Git и Github, рассказано в разделе «Как сдавать задания»

Основные команды, которые Вам понадобятся в работе:

  • git add — добавление измененных файлов в индекс. После того, как все нужные файлы будут добавлены в индекс, можно будет из этих изменений сформировать коммит (= сделать сохранение в историю). Можно применять в нескольких формах: git add file1.txt file2.txt для сохранения file1.txt , file2.txt либо git add . — для сохранения всех изменений
  • git status — просмотр изменений. Показывает разницу между текущим состоянием репозитория и предыдущим коммитом (сохранением)
  • git commit — коммит (сохранение изменений в Git) в локальном репозитории. Сохраняются все изменения, которые были добавлены в индекс. Употреблять в форме git commit -m ‘commit message’ . Вместо commit message принято писать лаконичный комментарий на английском языке о том, зачем был сделан этот коммит
  • git push — отправить изменения из локального репозитория в удаленный репозиторий на GitHub. Используйте команду git push origin master (origin — это название удаленного репозитория, а master — это ветки, в которой вы будете работать)
  • git pull — подтянуть изменения из удаленного репозитория. Вам понадобится команда git pull origin master

Работа с Git не ограничивается этими командами, но для успешной работы в рамках нашего курса этого должно быть достаточно. Для дальнейшего знакомства с Git можно читать документацию. Можете попробовать интересный интерактивный способ изучения Git — тренажер по Git. Можете изучать все подряд для саморазвития, а рамках нашего курса будет полезно попрактиковаться только в двух разделах: “Основы. Введение” и “Удаленные репозитории. Push & Pull — удаленные репозитории в Git!”

  • Введение
  • Настройка рабочей среды
    • Установка и настройка VS Code
    • Что такое Git?
    • Установка Git for Windows
    • Установка компилятора
    • Установка CMake
    • Установка Miniconda3
    • Установка библиотеки GoogleTest
    • Как отправлять решение задач

    Что такое Git: объясняем на схемах

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

    Александр Бабаскин

    Александр Бабаскин

    Автор статей о программировании. Изучает Python, разбирает сложные термины и объясняет их на пальцах новичкам. Если что-то непонятно — возможно, вы ещё не прочли его следующую публикацию.

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

    Git — это система коммитов

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

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

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

    Git — это комплекс связанных веток

    Коммиты располагаются на master-ветке — основной версии проекта, которая после завершения работы превратится в продукт.

    Система контроля версий позволяет создавать ответвления от master-ветки и экспериментировать с проектом, не мешая другим участника команды.

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

    Git — это инструмент совместного создания кода

    Часто бывает так: разработчики отделяются от master-ветки и работают над частью проекта самостоятельно — например, чтобы протестировать дополнительные функции. Но не могут продолжить, пока кто-то из команды не допишет код.

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

    Бывают и обратные ситуации, когда несколько разработчиков одновременно дописывают код, заливают его в master-ветку и сталкиваются с конфликтом — один файл получает несколько несогласованных изменений. В этом случае Git попробует автоматически исправить ошибки. Если не получится, разработчики это увидят и смогут поправить код вручную.

    Git — это распределённая система версий

    Системы контроля версий бывают локальными, централизованными или распределёнными.

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

    Из-за удобства и гибкости распределённая система версий Git считается современным форматом. Это стандарт для большинства ИТ-команд.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *