По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В интернете можно найти множество статей с описанием шаблонов масштабирования баз данных (БД), но, в основном, это разрозненная информация с перечислением методик и практически без объяснений.
Ниже приведено подробное руководство по шаблонам масштабирования БД, пошаговым объяснением принципов их работы и примерами использования.
Практический пример
Предположим, вы создали стартап, который предлагает совместные поездки по дешевой цене. Вы выбрали город для поездок, а первая реклама привлекла не более 10 клиентов.
Вы храните информацию обо всех клиентах, поездках, местах, бронированиях и историях заказов в одной и той же БД и, скорее всего, на одной физической машине. У вас нет навороченного кеширования или конвейера обработки больших данных, ведь ваше приложение только появилось. На данный момент это – идеальный вариант: в базе мало клиентов, и система, вряд ли, бронирует по поездке каждые 5 минут.
Но время идет. В вашей системе регистрируется все больше людей, ведь это самый дешевый сервис на рынке. Да и реклама сделала свое дело. Вы получаете по 10 заказов в минуту. Постепенно это количество увеличивается до 20, а затем и 30 бронирований в минуту.
В этот момент вы замечаете, что система начинает тормозить: время отклика API сильно увеличилось, а некоторые транзакции блокируются или зависают и, в конечном итоге, не проходят. Время ответа приложения также увеличилось, что вызвало недовольство клиентов. Как же решить эту проблему?
Шаблон №1 – оптимизация запросов и реализация пула соединений
Первое решение, которое приходит на ум: кэш слишком часто использует нединамические данные (история бронирования, история платежей, профили пользователей и т.д.). Но прикладным уровнем кеширования вы не сможете решить проблему с временем отклика API, предоставляющим динамические данные (текущее местоположение водителя, ближайшая машина для конкретного клиента, текущая стоимость поездки после выхода на маршрут и т.д.).
Вы приходите к выводу, что база данных слишком нормализована, поэтому вы решаете ее немного «разбавить» и добавляете несколько избыточных столбцов (такие столбцы часто попадают в операторы WHERE или JOIN ON в запросах). Это сокращает количество запросов на соединение, разбивает большие запросы на несколько маленьких и добавляет их результаты на прикладной уровень.
Можно заняться и параллельной оптимизацией – настроить подключения к базам данных. Внешние и клиентские библиотеки БД доступны практически для всех языков программирования. Для кеширования подключений к БД можно воспользоваться библиотеками пула соединений. Либо вы можете настроить размер пула соединений в самой СУБД.
Создание сетевого подключения – вещь весьма затратная, поскольку требует двусторонней коммуникации между клиентом и сервером. Пулы соединений помогают оптимизировать количество подключений. Библиотеки пула соединений реализуют мультиплексирование подключений – несколько потоков приложения могут пользоваться одним и тем же подключением.
Вы замеряете время отклика API и замечаете снижение задержки на 20-50% (или даже больше). На данный момент это хорошая оптимизация.
Затем вы расширили бизнес на еще один город и получили больше клиентов. Постепенно вы доходите до 80-100 бронирований в минуту. Ваша система не в состоянии справиться с таким объемом. Вы вновь замечаете увеличение времени ожидания API, а слой базы данных не справляется с нагрузкой. Но в этот раз оптимизация запросов не дает вам существенного улучшения производительности. Вы проверяете метрики системы и видите, что дисковое пространство заполнено, ЦП занят в 80% времени, а ОЗУ переполняется слишком быстро.
Шаблон № 2 – вертикальное масштабирование или масштабирование вверх
Изучив все системные метрики, вы не находите другого решения, кроме как обновить аппаратное обеспечение системы. Вы увеличиваете размер оперативной памяти в 2 раза, а объем диска – раза в 3. Это называется вертикальным масштабированием. Вы сообщаете группе по обслуживанию инфраструктуры, команде devops или агентам сторонних центров обработки данных (ЦОД) о необходимости обновления вашей машины.
Но как настроить саму машину для вертикального масштабирования?
Вы выделяете машину большего объема. Один из подходов заключается в том, чтобы не переносить данные со старой машины вручную, а настроить новую машину в качестве копии, или реплики (replica), уже существующего устройства, или источника (primary), прописав временную конфигурацию первичной реплики (primary replica). После завершения репликации назначьте новую машину в качестве primary и отключите старую. Поскольку обрабатывать запросы планируется на этой новой машине, все чтение/запись также будет вестись на ней.
Отлично. Вы прокачали систему, и теперь все работает намного быстрее.
Ваш бизнес идет на ура, и вы решаете расшириться еще до 3 городов. Теперь вы ведете деятельность в 5 городах. Трафик увеличился втрое, вы получаете по 300 заказов в минуту. Проблема с производительностью вернулась: размер индекса сильно сказывается на памяти, базу данных необходимо постоянно поддерживать, а сканирование таблицы с индексом замедлилось до невозможности. Вы подсчитали стоимость дальнейшего масштабирования системы, но цена не внушает доверия. Так что же делать?
Шаблон №3 – разделение ответственности на команды и запросы (CQRS):
Вы понимаете, что та самая большая машина не в состоянии обработать все запросы на чтение/запись. Да и чаще всего компаниям нужны транзакционные возможности на запись (write), а не чтение (read). Вас даже устраивает небольшая несогласованность данных или замедление операций read. В принципе, раньше это тоже не казалось вам проблемой. Вы решаете, что неплохо было бы разделить операции чтения и записи на физической машине. Это позволит отдельным машинам выполнять больше операций чтения/записи.
Теперь вы берете целых 2 большие машины и настраиваете их репликами для текущего компьютера. Репликация базы данных решит вопрос с переносом данных с primary машины на реплики. Вы перенаправляете все запросы на чтение (буква Q в CQRS, что означает «запрос» - Query) в реплики – любая реплика может обслуживать любой запрос на чтение. А все запросы на запись остаются на первичной машине. Возможна небольшая задержка в репликации, но в вашем конкретном случае это не критично.
Вариант с настройкой primary-replica вполне подходит для большинства стартапов среднего масштаба, получающих по сотням тысяч запросов ежедневно… но при условии, что компании периодически архивируют старые данные.
Вы вновь расширились на 2 города, и замечаете, что primary-машина не справляется со всеми запросами на запись. Многие такие запросы приходят с опозданием. Более того, задержка между primary и replica начинает сказываться на клиентах и водителях. Например, поездка завершена, клиент успешно ее оплачивает, но водитель не видит платеж, поскольку активность клиента – это запрос на запись, который идет на машину primary, а активность водителя – это запрос на чтение, который приходит на одну из реплик. Вся система настолько замедлилась, что водитель не видит платежа как минимум секунд 30, и это вызывает недовольство как со стороны клиента, так и у самого водителя. Как же поступить сейчас?
Шаблон №4 – репликация с несколькими источниками
Конфигурация primary-replica помогла вам успешно масштабироваться, однако теперь для операций записи не хватает возможностей. Быть может, вы согласитесь слегка пожертвовать быстротой запросов на чтение. А почему бы не перенести запросы на запись тоже в реплики?
В модели с несколькими источниками (multi-primary) все машины работают как источник, и как реплика. Такая структура чем-то напоминает замкнутый круг из машин: A->B->C->D->A. «B» может реплицировать данные из «A», «C» – реплицирует данные из «В», «D» – дублирует данные из «C», а «A» делает тоже самое из «D». Вы можете выполнять операцию чтения и одновременно записывать данные в любой узел; вы можете транслировать запрос во все узлы, а значение вернет один из откликнувшихся узлов. Все узлы имеют одинаковую схему БД, один и тот же набор таблиц, индекс и т.д. Но нужно следить, чтобы в узлах одной таблицы не было конфликта по id , иначе при трансляции запросов несколько узлов вернут разные данные по одному и тому же id.
Вообще считается, что для ID лучше использовать UUID или GUID. Еще один недочет данной системы: из-за трансляции запросов и поиска корректного результата, запросы на чтение могут оказаться неэффективными. Это, своего рода, принцип распределения/сборки в действии.
И вот вы вновь масштабировали бизнес. В этот раз на 5 новых городов. Система не справляется. Теперь вам нужно обрабатывать по 50 запросов в секунду. Вам очень не хватает обработки большого количества параллельных запросов. Но как это сделать?
Шаблон №5 – декомпозиция
Вы знаете, что база данных location получает много трафика на чтение/запись. Вполне возможно, что соотношение записи к чтению составляет 7:3. Это создает большую нагрузку на существующие БД. В таблицах location содержится несколько первичных данных: долгота (longitude), широта (latitude), отметка времени (timestamp), ID водителя (driver id), ID поездки (trip id) и т.д.
Там практически нет информации о поездках или данных пользователя, его платежах и т.д. Возможно, стоит разделить таблицы location на отдельную схему? Как насчет того, чтобы распределить эту БД по отдельным машинам с корректно настроенной конфигурацией primary-replica или multi-primary?
Это называется декомпозицией данных по функциональности. В разных БД можно хранить данные, разделенные по функциональному признаку, а результат (при необходимости) агрегируется на серверном уровне. Такой способ позволит вам масштабировать нужный функционал с большим количеством запросов на чтение/запись. В то же время прикладной или серверный уровень приложения должен будет заняться объединением результатов, что приведет к значительному изменению кода.
Теперь представьте себе, что вы масштабировались до 20 городов в своей стране и планируете открыть филиалы в Австралии. Растущий спрос на ваше приложение требует все более быстрого времени ответа. Ни один из методов выше с этим не поможет. Вам нужно масштабировать систему так, чтобы при расширении в другие страны/регионы не приходилось слишком часто проектировать и менять архитектуру. Как же тогда поступить?
Шаблон №6 – горизонтальное масштабирование
Вы хорошо загуглили эту тему, почитали массу статей о том, как другие компании решали такую проблему, и поняли, что настал момент масштабироваться горизонтально. Вы выделили, скажем, 50 машин – все с одинаковой схемой БД и одинаковыми наборами таблиц. На каждой машине хранится лишь часть данных.
Поскольку во всех БД хранится один и тот же набор таблиц, вы можете спроектировать систему таким образом, чтобы реализовать привязку данных (то есть все связанные данные хранятся на одной машине). В каждой машине может быть своя реплика; реплики используются для восстановления после сбоя. Каждая такая база данных называется «шардом». На физической машине может быть один или несколько шардов – их количество зависит от нужной вам схемы проектирования. Вы должны придумать ключ шардирования, который бы всегда относился к одной и той же машине. Представьте себе много машин с кучей связанных данных в одном наборе таблиц; операции на чтение/запись запрашиваются для одной и той же строки или набора ресурсов на одной и той же машине с БД.
Реализовать шардинг довольно сложно. По крайней мере, так говорят инженеры. Но при обслуживании миллионов или даже миллиардов запросов, рано или поздно вам придется пойти на столь непростой шаг.
Настроив шардинг, вы уверены, что сможете масштабироваться во многие страны. Ваш бизнес разросся настолько, что инвесторы вынуждают вас расширяться на другие континенты. И тут опять возникают проблемы. Все то же время отклика API. Ваш сервис находится в США, и у пользователей из Вьетнама возникают трудности при бронировании. Но почему? И что же делать?
Шаблон №7 – умное сегментирование центров обработки данных
Ваш бизнес развивается в Америке, Южной Азии и нескольких странах Европы. Каждый день вы получаете миллионы заказов, а ваш сервер атакуют миллиарды запросов. Поздравляю! Это пиковый момент в вашей деятельности.
Запросы из приложения поступают с разных континентов и проходят через сотни или даже тысячи серверов в интернете, поэтому время отклика растет. Может, распределить трафик по центрам обработки данных? Вы могли бы настроить ЦОД в Сингапуре, и он бы обрабатывал все запросы из Южной Азии. Затем сделать еще один в Германии – он займется всеми запросами из европейских стран, и оставить ЦОД в Калифорнии для обработки американских запросов.
Кроме того, вам понадобится репликация между ЦОД – на случай, если потребуется восстановление после сбоя. Если центр обработки данных в Калифорнии выполняет репликацию сингапурского ЦОД, то в случае аварии в Калифорнии (стихийные бедствия, отсутствие электричества и т.д.), все запросы из США будут передаваться в Сингапур и наоборот.
Такой метод масштабирования подходит для: обслуживания миллионов клиентов из разных стран, сохранения всех данных и поддержания постоянной доступности системы.
Заключение
В статье приведены общие методы по масштабированию базы данных. Стоит сказать, что у большинства инженеров нет достаточных возможностей для реализации всех шаблонов. Но лучше знать о существовании таких схем, которые в будущем могут помочь вам с проектированием архитектуры и систем.
В предыдущей статье мы рассмотрели необходимость перераспределения маршрутов, а также рассмотрели некоторые примеры конфигурации. Эта статья основана на предыдущей конфигурации и рассматривает возможность фильтрации маршрутов с помощью карт маршрутов.
В частности, в предыдущем примере показано взаимное перераспределение маршрутов между EIGRP и OSPF, где все маршруты были перераспределены между двумя автономными системами. Однако некоторые сценарии проектирования могут потребовать, чтобы мы предотвратили перераспределение каждого отдельного маршрута. Один из способов сделать эту фильтрацию - использовать карту маршрутов.
Для справки, вот топология, с которой мы работаем:
Кроме того, с нашей текущей конфигурацией перераспределения маршрутов таблица IP-маршрутизации на роутере OFF1 выглядит следующим образом:
Скажем, по какой-то причине мы не хотим, чтобы сеть 192.168.2.0 /24 была перераспределена из EIGRP в OSPF. Один из способов сделать эту фильтрацию - использовать карту маршрутов, которая ссылается на список управления доступом (ACL).
Во-первых, давайте перейдем к роутеру CENTR и создадим ACL, который соответствует сети, которую мы хотим отфильтровать.
CENTR # conf term
Enter configuration commands, one per line. End with CNTL/Z.
CENTR (config) access-list 1 permit 192.168.2.0 0.0.0.255
Обратите внимание на использование ключевого слова permit в ACL. В этом контексте слово permit одно из ключевых среди match, notallow. Далее мы будем ссылаться на этот ACL в карте маршрутов, и это карта маршрутов, расскажет, что мы хотим запретить этой сети быть перераспределенной. Вот как мы можем создать эту карту маршрута:
CENTR (config)# route-map LAB deny 10
CENTR (config-route-map) # match ip address 1
CENTR (config-route-map) #exit
CENTR (config)# route-map LAB permit 20
CENTR (config-route-map) exit
CENTR (config)#
Обратите внимание, что у нас есть два оператора route-map с порядковыми номерами 10 и 20. Как и в ACL, route-map обрабатываются сверху вниз. В этом примере мы хотим запретить сеть 192.168.2.0 / 24 с порядковым номером 10. Затем, чтобы разрешить перераспределение всего остального трафика, мы создаем инструкцию route-map с порядковым номером 20. Обратите внимание, что в отличие от предыдущего оператора route-map (который содержал ключевое слово deny), этот оператор route-map содержит ключевое слово permit. В результате, без необходимости указывать условие соответствия, мы сопоставляем (и разрешаем) все остальные маршруты.
Далее, давайте применим нашу карту маршрута к команде redistribute в нашем процессе маршрутизации OSPF на роутере CENTR. В настоящее время команда redistribute для процесса маршрутизации OSPF выглядит следующим образом: edistribute eigrp 1 metric-type 1 subnets
То, что мы хотим сделать - это переписать эту команду, добавив ссылку на нашу недавно созданную карту маршрутов.
CENTR (config)# router ospf 1
CENTR (config-router)# redistribute eigrp 1 metric-type 1 subnets route-map LAB
CENTR (config-router)#end
CENTR#
Теперь давайте вернемся к роутеру OFF1 и посмотрим, исчезла ли сеть 192.168.2.0/24 из таблицы IP-маршрутизации.
Все отлично! Маршрут 192.168.2.0/24 был успешно отфильтрован. В следующей статье мы рассмотрим, как можно устранить неполадки с перераспределением маршрутов.
Система контроля версий (Version Control System) – это инструмент, который используется для отслеживания, внесения и управления изменениями в программном коде. Это также можно назвать просто контролем версий.
Системы контроля версий помогает разработчикам сохранять изменения, внесенные в файл, на разных этапах, чтобы и они сами, и их коллеги могли их увидеть позже.
Существует три типа систем контроля версий:
Локальные системы контроля версий
Централизованные системы контроля версий
Распределенные системы контроля версий
Что такое локальная система контроля версий (LVCS)?
Этот тип системы контроля версий очень распространен и прост в использовании. Однако этот метод может выдавать ошибки и подвержен атакам, потому что файлы хранятся в вашей локальной системе.
Это означает, что вы можете потерять системный файл или случайно забыть каталог, с которым вы работаете (и затем записать в другой каталог).
Что такое централизованная система контроля версий (CVCS)?
В этом типе контроля версий сервер работает как общее хранилище, в котором находятся все версии кода. CVCS помогает разработчикам работать совместно.
Однако, несмотря на то, что такой метод позволяет разработчикам сотрудничать, если сервер отключится на несколько секунд или будет поврежден, то есть шанс, что вы потеряете все файлы. Это является серьезной проблемой при работе с CVCS.
В CVCS только несколько разработчиков могут работать совместно над проектом.
Что такое распределенная система контроля версий (DVCS)?
В настоящее время это новый и наиболее часто используемый тип системы контроля версий.
В DVCS у каждого разработчика есть полная резервная копия всех данных на сервере. Это означает, что всякий раз, когда сервер не будет работать или будет неисправен, то вы все равно сможете работать над своим проектом, а также копировать или создавать резервные копии своих хранилищ на сервере, чтобы восстановить их.
При работе с DVCS над одним проектом может работать много разработчиков. Одной из популярнейших DVCS является Git, о которой мы сейчас будем говорить подробнее.
Что такое Git?
Git – это бесплатная распределенная система контроля версий с открытым исходным кодом, которую можно использовать для отслеживания изменений в ваших файлах. В Git можно работать над всеми типами и размерами проектов.
С помощью Git вы можете добавлять изменения в свой код, а затем фиксировать их (или сохранять), когда это необходимо. Это означает, что у вас есть возможность вернуться к ранее внесенным изменениям. Git работает рука об руку с GitHub. А что же такое GitHub?
Что такое GitHub?
GitHub – это веб-интерфейс, в котором можно хранить свои репозитории Git, а также эффективно отслеживать и управлять своими изменениями. С его помощью разные разработчики имеют доступ к коду одного проекта. У вас есть возможность вносить свои собственные изменения в проект одновременно с другими разработчиками.
Например, если вы вдруг допустили какую-то ошибку во время внесения изменений, вы можете легко вернуться к предыдущему этапу, где ошибки еще нет.
Для чего нужно использовать GitHub?
Есть множество причин для использования GitHub. Давайте рассмотрим некоторые из них.
Эффективное управление проектами
GitHub – это своего рода хранилище ваших репозиториев. GitHub позволяет разработчикам работать над одним проектом, находясь в разных местах.
С помощью GitHub вы можете легко отслеживать внесенные вами изменения и управлять ими, а также проверять ход вашей работы над проектом.
Простое сотрудничество
С GitHub разработчики со всего мира могут работать вместе на одним проектом без каких-либо проблем.
Команды разработчиков могут оставаться на одной странице во время совместной работы над проектом и могут легко организовывать и эффективно управлять проектом.
Открытый исходный код
GitHub – это бесплатная система с открытым исходным кодом. Это означает, что разработчики могут легко получить доступ к различным типам кода/проектов, которые они могут использовать для обучения и развития своих навыков.
Универсальность
Это свойство GitHub очень важно. GitHub – это веб-интерфейс не только для разработчиков. Его также могут использовать дизайнеры, писатели и все, кто хочет отслеживать историю своих проектов.
Как настроить Git?
Чтобы использовать Git, его необходимо загрузить на свой компьютер. Сделать это можно, зайдя на официальный сайт.
Когда сайт откроется, прокрутите страницу вниз, и вы увидите кнопку загрузки. Нажмите на нее.
Выберите свою операционную систему: Windows, MacOS, Linux/Unix. В моем случае я выбираю Windows, потому что я использую компьютер именно с этой операционной системой.
Нажмите на первую ссылку в самом верху страницы, чтобы загрузить последнюю версию Git.
Когда загрузка будет завершена, установите Git на свой компьютер. Для этого вам нужно будет перейти в папку, куда был загружен файл, и установить его.
После завершения установки, необходимо убедиться, что Git успешно установлен в вашей системе. Откройте командную строку или Git bash (в зависимости от того, что вы решили использовать) и выполните команду:
git --version
Если Git был успешно установлен на вашем компьютере, то он должен отобразить текущую версию Git под командой, которую вы только что выполнили. Если отображается, то мои поздравления!
Как настроить Git?
Теперь, когда мы установили Git на компьютер, нам нужно его настроить. Мы делаем это для того, чтобы каждый раз, когда мы работаем в команде над проектом, мы могли бы легко идентифицировать сделанные нами коммиты в репозитории.
Чтобы настроить Git, нам нужно указать имя, адрес электронной почты и ветку с помощью команды git config --global. Например:
На изображении выше мы использовали git config --global user.name для настройки имени пользователя. То же самое относится и к конфигурации git config --global user.email.
Git имеет ветку по умолчанию master, можно поменять называние, чтобы она называлась main, с помощью команды git config --global init.default branch main.
Теперь вы готовы начать использовать Git.
Чтобы настроить учетную запись GitHub, зайдите на их официальный сайт. Нажмите на кнопку регистрации в правом верхнем углу:
Когда откроется форма регистрации, введите свой адрес электронной почты, создайте пароль, введите свое имя пользователя, а затем проверьте все, прежде чем нажимать кнопку создания учетной записи.
Популярные команды Git
Есть несколько основных команд Git, которые должен знать каждый разработчик:
git config
git init
git remote add origin
git add
git commit
git clone
git push
git rm
git branch
git diff
git log
git checkout
git merge
Давайте кратко рассмотрим каждую из них, чтобы вы понимали, как их использовать.
Как использовать команду git config
Эта команда используется для того, чтобы установить имя пользователя, адрес электронной почты и ветку пользователя, чтобы определить, кто зафиксировал изменения при работе над проектом. Эта команда используется, когда вы загрузили Git на свой компьютер и хотите настроить его для своего использования.
Например:
git config --global user.name “[username]”
git config --global user.email [email address]
Как использовать команду git init
Эта команда используется для того, чтобы запустить Git в своем проекте для отслеживания изменений, внесенных в проект.
git init
Когда вы запускаете эту команду, вы должны увидеть, что папка с названием .git автоматически создалась в текущей папке, над которой вы работаете.
Как использовать команду git remote add origin
Теперь мы укажем нашей кодовой базе (папке, в которой находится наш код), где хранить наш код в облаке. Мы введем git remote add origin [your-repo-url], который установит источник для нашего репозитория. Теперь мы можем заливать (пушить) код в наш источник (origin), чтобы сохранить его на наше облако в GitHub.
Как использовать команду git add
Эта команда добавляет ваш файл в промежуточную область (staging area). Промежуточная область – это та область, в которую добавляются файлы, в которые мы вносим изменения, и где они ждут следующего коммита.
Чтобы добавить файл в промежуточную область, нужно воспользоваться командой git add. Она добавляет все файлы в папке в промежуточную область.
git add (file name) добавляет имя конкретного файла, который вы хотите зафиксировать в промежуточной области.
Эту команду нужно использовать тогда, когда вы внесли изменения в файл и хотите зафиксировать их в своем проекте.
Как использовать команду git commit
Эта команда фиксирует любой файл, который был добавлен с помощью команды git add, а также все файлы в промежуточной области.
git commit –m “first commit”
Эта команда навсегда сохраняет файл в репозиторий Git. Ее необходимо использовать каждый раз, когда вы добавляете файл в промежуточную область с помощью команды git add.
-m называется «флагом» и сигнализирует о том, что есть необязательные действия, которые мы хотели бы выполнить с этим комитом. Флаг m означает, что впоследствии мы предоставим сообщение, которое является в нашем случае - «first commit».
Как использовать команду git clone
Эта команда используется для того, чтобы скопировать существующий репозиторий в другую область из одного места в другое.
git clone (repository name)
Эта команда используется, когда вы хотите продублировать репозиторий Git из GitHub в локальное хранилище.
Как использовать команду git push
Эта команда используется для того, чтобы загрузить/отправить файлы из локального репозитория/хранилища в другое хранилище, например, в удаленное, такое как GitHub.
git push (remote storage name)
Эта команда используется только тогда, когда вы довольны всеми изменениями и комитами, которые были сделаны в проекте, и, наконец, хотите отправить их в репозиторий Git на GitHub.
Как использовать команду git rm
Эта команда используется для того, чтобы удалить файл из рабочего репозитория.
git rm (filename)
Эта команда используется только тогда, когда вам необходимо избавиться от нежелательных изменений или файлов из репозитория Git.
Как использовать команду git branch
Эта команда используется для того, чтобы проверить текущую ветку, над который вы работаете, main или master.
git branch
Эта команда поможет вам узнать имя текущей ветки, над которой вы работаете.
Как использовать команду git diff
Git покажет вам разницу между кодом, который у вас есть сейчас, и кодом, когда он был сохранен в последний раз.
Немного сложно понять, что здесь происходит, но - — это удаления, а + — вставки. Мы удалили текст Hello, this is a git example и добавили текст Now I have changed the first line. Так Git отслеживает, что изменилось между версиями.
diff --git a/git.js b/git.js
index eb0f1d1..8dbf769 100644
--- a/git.js
+++ b/git.js
@@ -1,3 +1,3 @@
+console.log('Now I have changed the first line.')
-console.log('Hello, this is a git example!')
console.log('And here is another!')
console.log('And yet a third')
Как использовать команду git log
Мы можем просмотреть сделанные нами коммиты с помощью команды git log. Это может выглядеть так:
commit 67627dd44e84a3106a18a19e94cf9f3723e59b3c (HEAD -> master)
Author: amberwilkie amber@amberwilkie.com
Date: Wed Apr 22 16:55:39 2020 -0400
Update first console log
commit 49fe4152f474a9674a83e2b014a08828209d2690
Author: amberwilkie amber@amberwilkie.com
Date: Wed Apr 22 16:54:59 2020 -0400
Initial commit
Мы видим наши сообщения комиты, время, в которое мы их совершили, и уникальный идентификатор для нашго комита, который мы можем использовать для ссылки на коммиты в будущем.
Как использовать команду git checkout
Если мы хотим вернуться и увидеть изменения в нашем коде из предыдущего коммита, мы сделаем это с помощью:
git checkout 49fe4152f474a9674a83e2b014a08828209d2690
Git поместит наш код во временное состояние, чтобы мы могли посмотреть, как код выглядел на этом снимке во времени. Тут мы использовали идентификатор комитаю
Чтобы вернуться к нашей ветке, введите git checkout [branch_name].
Как использовать команду git merge
git merge возьмет все коммиты, которые вы сделали в этой ветке, и вставит их в основную ветку, сохранив вашу работу.
Ветки
Git полагается на ветвление для поддержки нашего кода. Вы можете считать главной веткой (обычно это master или main) ствол вашего дерева кода. Вы можете отпочковаться от нее и внести некоторые изменения, но конечная цель всегда состоит в том, чтобы вернуть их в ствол, в основную ветку.
Вы можете использовать git checkout для создания новой ветки, а не только для проверки предыдущих версий вашего кода. Попробуйте использовать git checkout -b new-branch. Флаг -b используется, когда мы создаем новую ветку, и после флага мы пишем имя нашей новой ветки. Мы можем сделать много коммитов в этой ветке, а затем вернуть их в master с помощью процесса, называемого слиянием (merging), используя для этого команду git merge.
На диаграмме ниже точки обозначают коммиты. Две ветки были сделаны от мастера. В разработке программного обеспечения мы часто называем эти «функциональные» (feature) ветки, в отличие от основной главной ветки. Синяя ветвь была объединена с мастером, а желтая ветвь все еще находится в разработке.
Обратите внимание, что несмотря на то, что желтая ветка была создана после синей ветки, в этой ветке будут видны только изменения из мастера. Если мы создадим третью ветку когда-нибудь в будущем, изменения как из master, так и из синей ветки будут присутствовать в новой, третьей ветке.
Просмотр кода в GitHub
Теперь ваш код находится GitHub!
Вы можете щелкать по файлам и папкам вашего репозитория, просматривая текущее состояние кода. Вы также можете просмотреть предыдущие версии кода. Вы увидите список коммитов, сделанных в репо, и если вы нажмете на них, вы сможете просмотреть файлы вашего проекта в том виде, в каком они существовали в этот период времени.
Пулл-реквесты
Есть много других возможностей GitHub, но самая важная в совместной работе с коллегами — это пулл реквесты (pull request). Пулл реквест (очень часто сокращается до PR или ПР) — это способ управления входящими изменениями в базе кода. По сути это событие, когда один участник просит влить свои изменения в ветку.
Чтобы сделать это, вы создадите новую ветку на своем локальном компьютере, создадите хотя бы один комит в этой ветке, а затем сделайте git push origin head отправите эту ветку на GitHub. (Вы можете указать имя своей ветки вместо заголовка, но это полезно для точного соответствия всех элементов).
Теперь, когда вы вернетесь на GitHub, вы увидите, что ваша ветка доступна для создания PR.
Если вы нажмете кнопку Compare & pull request, вы сможете изменить многие настройки для своего PR. Наиболее важными, как правило, являются заголовок и описание. Если вы работаете в команде, вы можете пометить коллег, чтобы попросить их просмотреть ваш код, добавить в проекты и использовать многие другие функции.
Обратите внимание, что мы сравниваем ветки. Здесь мы просим добавить изменения из этой ветки (pr-пример) в основную ветку. Но мы могли бы ориентироваться на любую другую ветку в нашем репо. А пока просто помните, что master — не единственная ветка, с которой вы можете сделать ПР.
Когда вы нажмете Create Pull Request, вы увидите этот экран:
Вы можете посмотреть все коммиты в этой ветке, а также можете слить свой пулреквест.
Помните, как мы могли объединить наш код локально при помощи merge, когда говорили о Git? Мы можем выполнить то же действие с нашим облачным кодом на GitHub. Если вы нажмете зеленую кнопку Merge pull request, ваши изменения будут объединены в мастер.
Заключение
Благодаря этому руководству, вы узнали, что такое системы контроля версий. Также вы узнали, как установить и настроить Git на своем компьютере и настроить учетную запись GitHub. И, наконец, мы рассмотрели некоторые популярные команды Git.