Содержание
Git для начинающих. Часть 1. Что такое системы контроля версий?
Система контроля версий (Version Control System, VCS) представляет собой программное обеспечение, которое позволяет отслеживать изменения в документах, при необходимости производить их откат, определять, кто и когда внес исправления и т.п. В статье рассмотрены виды VCS, принципы их работы, а также приведены примеры программных продуктов.
Что такое система контроля версий?
Наверное, всем знакома ситуация, когда при работе над проектом, возникает необходимость внести изменения, но при этом нужно сохранить работоспособный вариант, в таком случае, как правило, создается новая папка, название которой скорее всего будет “Новая папка” с дополнением в виде даты или небольшой пометки, в нее копируется рабочая версия проекта и уже с ним производится работа. Со временем количество таких папок может значительно возрасти, что создает трудности в вопросе отката на предыдущие версии, отслеживании изменений и т.
п. Эта ситуация значительно ухудшается, когда над проектом работает несколько человек.
Для решения таких проблем как раз и используется система контроля версий, она позволяет комфортно работать над проектом как индивидуально, так в коллективе. VCS отслеживает изменения в файлах, предоставляет возможности для создания новых и слияние существующих ветвей проекта, производит контроль доступа пользователей к проекту, позволяет откатывать исправления и определять кто, когда и какие изменения вносил в проект. Основным понятием VCS является репозиторий (repository) – специальное хранилище файлов и папок проекта, изменения в которых отслеживаются. В распоряжении разработчика имеется так называемая “рабочая копия” (working copy) проекта, с которой он непосредственно работает. Рабочую копию необходимо периодически синхронизировать с репозиторием, эта операция предполагает отправку в него изменений, которые пользователь внес в свою рабочую копию (такая операция называется commit) и актуализацию рабочей копии, в процессе которой к пользователю загружается последняя версия из репозитория (этот процесс носит название update).
Централизованные и распределенные системы контроля версий
Системы контроля версий можно разделить на две группы: распределенные и централизованные.
Централизованные системы контроля версий
Централизованные системы контроля версий представляют собой приложения типа клиент-сервер, когда репозиторий проекта существует в единственном экземпляре и хранится на сервере. Доступ к нему осуществлялся через специальное клиентское приложение. В качестве примеров таких программных продуктов можно привести CVS, Subversion.
CVS (Concurrent Versions System, Система одновременных версий) одна из первых систем получивших широкое распространение среди разработчиков, она возникла в конце 80-х годов прошлого века. В настоящее время этот продукт не развивается, это в первую очередь связано с рядом ключевых недостатков, таких как невозможность переименования файлов, неэффективное их хранение, практически полное отсутствие контроля целостности.
Subversion (SVN) – система контроля версий, созданная на замену CVS. SVN была разработана в 2004 году и до сих пор используется. Несмотря на многие преимущества по сравнению с CVS у SVN все-таки есть недостатки, такие как проблемы с переименованием, невозможность удаления данных из хранилища, проблемы в операции слияния ветвей и т.д. В целом SVN был (и остается) значительным шагом вперед по сравнению с CVS.
Распределенные системы контроля версий
Распределенные системы контроля версий (Distributed Version Control System, DVCS) позволяют хранить репозиторий (его копию) у каждого разработчика, работающего с данной системой. При этом можно выделить центральный репозиторий (условно), в который будут отправляться изменения из локальных и, с ним же эти локальные репозитории будут синхронизироваться. При работе с такой системой, пользователи периодически синхронизируют свои локальные репозитории с центральным и работают непосредственно со своей локальной копией.
После внесения достаточного количества изменений в локальную копию они (изменения) отправляются на сервер. При этом сервер, чаще всего, выбирается условно, т.к. в большинстве DVCS нет такого понятия как “выделенный сервер с центральным репозиторием”.
Большое преимущество такого подхода заключается в автономии разработчика при работе над проектом, гибкости общей системы и повышение надежности, благодаря тому, что каждый разработчик имеет локальную копию центрального репозитория. Две наиболее известные DVCS – это Git и Mercurial.
Начнем с Mercurial, эта система представляет собой свободную DVCS, которая построена таким образом, что в ней отсутствует понятие центрального репозитория, для работы с этой VCS используется (как правило) консольная утилита hg. Mercurial обладает всеми возможностями системы контроля версий, такими как ветвление, слияние, синхронизация с другими репозиториями.
Данный проект используют и поддерживают большое количество крупных разработчиков, среди них Mozilla, OpenOffice, OpenJDK и многие другие. Сам продукт написан на языке Python и доступен на большинстве современных операционных систем (Windows, Mac OS, Linux), также существует значительное количество утилит с графическим интерфейсом для работы с Mercurial. Основным конкурентом Mercurial на рынке распределенных систем контроля версий является Git, который, на сегодняшний день, выиграл гонку за лидерство.
Git – распределенная система контроля версий, разработанная Линусом Торвальдсем для работы над ядром операционной системы Linux. Среди крупных проектов, в рамках которых используется git, можно выделить ядро Linux, Qt, Android. Git свободен и распространяется под лицензией GNU GPL 2 и, также как Mercurial, доступен практически на всех операционных системах.
По своим базовым возможностям git схож с Mercurial (и другими DVCS), но благодаря ряду достоинств (высокая скорость работы, возможность интеграции с другими VCS, удобный интерфейс) и очень активному сообществу, сформировавшемуся вокруг этой системы, git вышел в лидеры рынка распределенных систем контроля версий. Необходимо отметить, что несмотря на большую популярность таких систем как git, крупные корпорации, подобные Google, используют свои VCS.
Это была вводная лекция по системам контроля версий. В дальнейшем, все изложение будет касаться только git.
Если вам больше нравится учиться по видео-лекциям, то рекомендуем классный курс по git от GeekBrains, перейдите по ссылке и найдите в разделе “Курсы” курс “Git. Быстрый старт”. Он бесплатный, нужно только зарегистрироваться на сайте. Рекомендуем повнимательнее посмотреть на этот ресурс, на нем ещё очень много чего интересного!
Часть 2.
Установка Git >>>
Система контроля версий Git. Урок 2
Продолжаем изучать систему контроля версий git. Сегодня говорим про GitHub. На прошлом уроке мы создали локальный репозиторий для проекта. Но хранить данные только на компьютере опасно, если папка с репозиторием удалится или потеряется, весь проект пропадет. Поэтому важно дублировать все файлы и историю их изменений на сервере. Самая популярная платформа, на которой разработчики размещают репозитории — GitHub. Зарегистрируйтесь на нем. Это так же просто, как создать аккаунт в соцсетях.
Съемка и монтаж: Глеб Лиманский
Настраиваем доступ по токену
Когда вы зарегистрировались и зашли в аккаунт, стоит настроить доступ по токену. Это важная мера безопасности. Даже если ваш пароль кто-то украдет, зайти в аккаунт он не сможет.
Токен — более продвинутый метод защиты, чем пароль. Аутентификация по токену генерирует входные данные отдельно для каждого устройства и сеанса. У токенов можно менять права доступа или отзывать их. Подобрать токен перебором невозможно.
Переходим в меню под фото профиля. Settings → Developer settings → Personal access tokens → Create new token.
Разные токены нужны для разных доступов, чтобы не запутаться, давайте дадим нашему токену название tutorial. В настройках для начала достаточно поставить галочку рядом с repo. Создаем токен. Получившийся токен нужно обязательно сохранить в какой-то надежный файл, а лучше в менеджер паролей.
Откроем терминал по адресу нашего проекта. На mac нужно выбрать «новый терминал по адресу папки». На Windows будет вариант «GitBush here».
Чтобы настроить доступ по токену, воспользуемся уже известной утилитой git config: git config —global user.name <username, который задавали при регистрации>
Теперь вводим токен: git config —global user.
password <ваш токен>
Устанавливаем двухфакторную аутентификацию
Вторая важная настройка безопасности — двухфакторная аутентификация. Settings → Password and Autentication → Enable Two-Factor Authentication.
В качестве второго фактора лучше использовать не SMS, а приложение, например Google Аuthenticator. Его нужно скачать на телефон, нажать на плюс, чтобы добавить новый код, затем отсканировать qr-код, который появится на сайте, и ввести сгенерированный шестизначный код. После этого нужно скачать коды восстановления и сохранить их в надежное место.
Создаем репозиторий на GitHub
Можем создать первый удаленный репозиторий. Нажимаем на + в правом верхнем углу, выбираем New repository.
Задаем имя репозитория, например, git_tutorial.
Можем добавить описание: «Учимся работать с удаленным репозиторием».
GitHub предлагает нам сразу создать два базовых файла README.md и .gitignore. Но у нас уже есть локальный репозиторий, с которым мы начали работать, добавим эти файлы в него.
А на этом шаге просто нажимаем create repository.
Файлы README и gitignore
Файл README.md — это текстовый файл, в котором на языке markdown можно добавить описание проекта. Файл README необязателен, но помогает лучше ориентироваться в своих и чужих репозиториях. Давайте его добавим в нашу папку с проектом. Напишем заголовок «Тестовый репозиторий» и описание: «Это тестовый репозиторий, в котором я учусь работать с git».
Описания могут быть и гораздо более подробными, содержать картинки, ссылки, вставки кода. Подробнее о языке markdown можно прочитать в официальном гайде.
В проекте появился новый файл. Вернемся в терминал и добавим его в отслеживание: git add README.md
Закоммитим: git commit -m “Add README”
Файл .gitignore нужен, чтобы прописать те файлы, которые мы не хотим отслеживать. Это могут быть конфигурационные или временные файлы, которые автоматически создаются по ходу работы. Учесть все ненужные файлы, которые могут появиться, и самостоятельно создать gitignore-документ сложно.
Поэтому можно использовать шаблоны, а потом уже дополнять их самостоятельно по ходу работы. Мы программируем на python, поэтому для примера я нашла gitignore для python. Создадим файл .gitignore в нашей папке и скопируем в него названия файлов.
Добавим новый файл в отслеживание и закоммитим изменения.
git add .gitignore
git commit -m “Add gitignore”
Проверим git status. Все закоммичено.
Теперь в репозитории есть все нужные файлы, можем добавить его на GitHub. GitHub можно использовать как обычное хранилище и загружать почти любые файлы. Для этого нужно нажать «загрузка нового файла» и выбрать, что мы хотим загрузить.
Можно таким путем добавить и наш репозиторий. Но так файлы просто скопируются из одного место в другое, а нам нужно привязать локальный репозиторий к серверу.
Просматриваем историю изменений
Вернемся в терминал. Вспомним, какие изменения мы уже локально коммитили на прошлом уроке.
Посмотреть все коммиты можно с помощью команды git log. Сейчас мы видим все коммиты.
У каждого коммита есть уникальный идентификатор — набор цифр и букв. Мы видим кто и когда сделал каждый коммит, какое сообщение он написал. Подробнее посмотреть информацию о конкретном коммите можно с помощью команды: git show <5 первых символов идентификатора>
В таком режиме мы видим, какие изменения были внесены.
Зеленые плюсы — какие строки добавились, красные минусы — какие удалились.
Чтобы выйти из log, нужно нажать q в английской раскладке.
Еще раз посмотрим всю историю: git log. Наши изменения лежат в ветке master (на Windows будет ветка main), подробнее про ветки мы еще будем говорить на следующем занятии. Сейчас достаточно знать, что это основная ветка. Но на GitHub основная ветка называется main.
Чтобы не возникало проблем при сохранении проекта на сервере, переименуем нашу локальную ветку: git branch -m master main.
(Для Windows это делать не нужно)
Проверим историю: git log. Видим, что ветка переименовалась.
Передаем репозиторий на сервер
Передадим наш репозиторий на сервер. Связаться с удаленным репозиторием можно по ссылке. Откроем репозиторий на GitHub и скопируем ссылку.
В открытом терминале пишем команду:
git remote add origin <ссылка на репозиторий>
(Чтобы вставить скопированную ссылку в терминал на Windows, нужно зажать ctrl и нажать левой кнопкой мыши или тачпада.)
Origin — это имя удаленного репозитория, которое мы будем дальше использовать вместо ссылки. Проверим, подключился ли репозиторий. Команда git remote -v показывает, какие удаленные репозитории присоединены. Мы видим присоединенный репозиторий.
Теперь можем отправить на него наш локальный репозиторий: git push -u origin main
Обновим страницу: наш репозиторий появился на сайте.
В заголовке видим последний коммит.
Если нажмем на часы — увидим историю коммитов. Такую же, как в git log.
Теперь пройдем весь путь от внесения изменений, до передачи их на сервер.
Вносим изменения и исправляем ошибки
Вносим изменения в наш файл test.py: print(“We learn GitHub”)
Добавляем изменение в отслеживание и закоммитим: git commit -a -m “Add third line”
В работе над реальным проектом, важно емко описывать изменения, которые вы внесли. Это поможет лучше ориентироваться в репозитории.
Теперь давайте представим, что мы закоммитили ошибочное изменение. Допишем в файл строку: print(“False line”)
Добавим изменение в отслеживание и закоммитим: git commit -a -m “False commit”
Проверим историю: git log
Мы видим ошибочный коммит.
Чтобы отменить его, воспользуемся командой: git revert <первые 5 символов идентификатора коммита>
Мы попали в текстовый редактор, где уже есть сообщение об отмене коммита, можем написать другое сообщение или сохранить предложенное, чтобы выйти из текстового редактора нажмем cmd+X, затем y и enter.
Проверим историю: git log. Мы видим, что git создал новое сохранение с отменой коммита, а в файле ненужная строка удалилась.
Заливаем изменения на сервер
Проверим git status. Дерево чистое, можем заливать коммиты на сервер: git push. Нам не нужно еще раз писать origin main, потому изменения из ветки main на ветку origin мы уже передавали в прошлый раз. Откроем наш репозиторий на сайте. Зайдем в файл test.py. Видим, что третья строка появилась, а четвертая ошибочная строка не закоммитилась, как нам и было нужно.
Копируем удаленные репозитории
GitHub позволяет не только создавать свои репозитории, но и копировать чужие. Зайдем на GitHub «Важных историй», выберем любой репозиторий. Скопируем ссылку.
Создадим папку на компьютере для этого репозитория. Откроем терминал в этой папке. Введем команду git clone <ссылка на репозиторий>
Вы можете просто открыть папку и проверить, что в нее скопировались все файлы из репозитория.
Можно это сделать и в терминале, просмотрев все внутренние папки: ls
Перейдем в репозиторий: cd <название клонированной папки с репозиторием>
Теперь мы можем работать с этим репозиторием локально: вносить изменения, просматривать историю коммитов.
Если у вас появятся вопросы, попробуйте найти ответ в интернете. Часто достаточно скопировать полученную ошибку и забить ее в поиск в браузере. Если все же не получается найти ответ, пишите нам в чате в Telegram.
система контроля версий · Темы GitHub · GitHub
Здесь
82 публичных репозитория
соответствует этой теме…
снежная дорожка
/
снежинки
Звезда
1,2к
акваметаллабс
/
аквамета
Звезда
1к
Рейндерт-Веттер
/
API-управление версиями
Звезда
154
самрат
/
коврик
Звезда
127
АКСВ
/
Выйти из магазина
Звезда
84
свежая команда
/
свежий
Звезда
80
Дженкински
/
p4-плагин
Звезда
75
sdslabs
/
кишки
Звезда
56
хпи-сва
/
Сквот
Звезда
53
павпонн
/
наблюдатель
Звезда
31
нкр413
/
rustix-vcs
Звезда
20
Ритиш Барадвадж
/
GitLearn
Звезда
16
Джинна Балу
/
GitCheatSheet
Звезда
15
карманные приложения
/
действие-обновление-версия
Звезда
14
мичмих212
/
версия-бампер
Звезда
13
Крейгтауб
/
наш собственный мерзавец
Звезда
10
Агент6-6-6
/
Excel-VBA-XML-Export-Pre-Commit-Hook
Звезда
10
флоуак
/
Сидр
Звезда
7
Джаздотдев
/
кишки
Звезда
6
мираллка
/
UCU_Linux_Course
Звезда
5
Улучшить эту страницу
Добавьте описание, изображение и ссылки на
система контроля версий
страницу темы, чтобы разработчикам было легче узнать о ней.
Курировать эту тему
Добавьте эту тему в свой репозиторий
Чтобы связать ваш репозиторий с
система контроля версий
тему, перейдите на целевую страницу репозитория и выберите «управление темами».
Учить больше
Система контроля версий Git — javatpoint
следующий → Система контроля версий — это программное обеспечение, которое отслеживает изменения в файле или наборе файлов с течением времени, чтобы вы могли позже вызвать определенные версии. Это также позволяет вам работать вместе с другими программистами. Система контроля версий — это набор программных инструментов, которые помогают команде управлять изменениями в исходном коде. Он использует базу данных особого типа для отслеживания каждой модификации кода. Разработчики могут сравнивать более ранние версии кода с более старой версией, чтобы исправить ошибки. Преимущества системы контроля версийСистема контроля версий очень полезна и полезна при разработке программного обеспечения; разработка программного обеспечения без контроля версий небезопасна. Он обеспечивает резервные копии для неопределенности. Системы контроля версий предлагают быстрый интерфейс для разработчиков. Это также позволяет группам разработчиков программного обеспечения сохранять эффективность и гибкость в соответствии с масштабами команды, чтобы включать больше разработчиков. Вот некоторые ключевые преимущества наличия системы контроля версий.
Типы системы контроля версий
Локализованные системы контроля версий Метод локализованного управления версиями является распространенным подходом из-за его простоты. Чтобы решить эту проблему, программисты разработали локальные системы контроля версий с простой базой данных. В таких базах данных все изменения в файлах находились под контролем версий. Локальная система контроля версий хранит локальные копии файлов. Основным недостатком Local VCS является наличие единой точки отказа. Централизованная система контроля версийРазработчикам нужно было сотрудничать с другими разработчиками в других системах. Локализованная система контроля версий в этом случае не сработала. Для решения этой проблемы были разработаны централизованные системы контроля версий. В этих системах есть один сервер, содержащий версии файлов, и несколько клиентов для извлечения файлов из центрального места. Централизованные системы контроля версий имеют много преимуществ, особенно по сравнению с локальными системами контроля версий.
Он также имеет тот же недостаток, что и локальная система контроля версий, а именно единую точку отказа. Распределенная система контроля версийЦентрализованная система управления версиями использует центральный сервер для хранения всей базы данных и совместной работы группы. Но из-за одноточечного отказа, что означает выход из строя центрального сервера, разработчики его не предпочитают. Далее разрабатывается распределенная система контроля версий. В распределенной системе управления версиями (например, Git, Mercurial, Bazaar или Darcs) у пользователя есть локальная копия репозитория. DVCS позволяет автоматически управлять разветвлением и слиянием. Это ускоряет большинство операций, кроме толкания и вытягивания. DVCS расширяет возможности автономной работы и не зависит от одного места для резервного копирования. Если какой-либо сервер остановился и другие системы взаимодействовали через него, то любой из клиентских репозиториев мог быть восстановлен этим сервером. Каждая касса — это полная резервная копия всех данных. Эти системы не обязательно зависят от центрального сервера для хранения всех версий файла проекта. Разница между централизованной системой контроля версий и распределенной системой контроля версийЦентрализованные системы контроля версий — это системы, использующие архитектуру клиент/сервер . Существует множество преимуществ и недостатков использования обеих систем контроля версий. Давайте посмотрим на некоторые существенные различия между централизованной и распределенной системой контроля версий.
|
Но такой подход ведет к более высокой вероятности ошибки. При таком подходе вы можете забыть, в каком каталоге вы находитесь, и случайно записать не тот файл или скопировать файлы, которые вам не нужны.
Таким образом, клиенты не просто извлекают последний снимок файлов, даже если они могут полностью отразить репозиторий. Локальный репозиторий содержит все файлы и метаданные, присутствующие в основном репозитории.
В централизованной системе контроля версий одна или несколько клиентских систем напрямую подключены к центральному серверу. Напротив, распределенные системы контроля версий — это системы, использующие одноранговая архитектура .