From 4895a67f53ce5f9ca8f9348bfa1a18b3159feb5e Mon Sep 17 00:00:00 2001 From: Rikudo Date: Fri, 24 Jul 2026 20:28:24 +0300 Subject: [PATCH 1/2] =?UTF-8?q?=D0=9E=D1=82=D1=80=D0=B5=D0=B4=D0=B0=D0=BA?= =?UTF-8?q?=D1=82=D0=B8=D1=80=D0=BE=D0=B2=D0=B0=D0=BD=D0=BE:=20about-versi?= =?UTF-8?q?on-control.asc?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../sections/about-version-control.asc | 22 +++++++++---------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/book/01-introduction/sections/about-version-control.asc b/book/01-introduction/sections/about-version-control.asc index 11c36279..c4bf23de 100644 --- a/book/01-introduction/sections/about-version-control.asc +++ b/book/01-introduction/sections/about-version-control.asc @@ -7,7 +7,7 @@ Если вы графический или web-дизайнер и хотите сохранить каждую версию изображения или макета (скорее всего, захотите), система контроля версий (далее VCS) -- как раз то, что нужно. Она позволяет вернуть файлы к состоянию, в котором они были до изменений, вернуть проект к исходному состоянию, увидеть изменения, увидеть, кто последний менял что-то и вызвал проблему, кто поставил задачу и когда и многое другое. -Использование VCS также значит в целом, что, если вы сломали что-то или потеряли файлы, вы спокойно можете всё исправить. +Использование VCS также значит, в целом, что если вы сломали что-то или потеряли файлы, то спокойно можете всё исправить. В дополнение ко всему вы получите всё это без каких-либо дополнительных усилий. ==== Локальные системы контроля версий @@ -15,22 +15,22 @@ (((контроль версий,локальный))) Многие люди в качестве метода контроля версий применяют копирование файлов в отдельный каталог (возможно даже, каталог с отметкой по времени, если они достаточно сообразительны). Данный подход очень распространён из-за его простоты, однако он невероятно сильно подвержен появлению ошибок. -Можно легко забыть в каком каталоге вы находитесь и случайно изменить не тот файл или скопировать не те файлы, которые вы хотели. +Можно легко забыть, в каком каталоге вы находитесь, и случайно изменить не тот файл или скопировать не те файлы, которые вы хотели. -Для того, чтобы решить эту проблему, программисты давным-давно разработали локальные VCS с простой базой данных, которая хранит записи о всех изменениях в файлах, осуществляя тем самым контроль ревизий. +Для того чтобы решить эту проблему, программисты давным-давно разработали локальные VCS с простой базой данных, которая хранит записи о всех изменениях в файлах, осуществляя тем самым контроль версий. .Локальный контроль версий image::images/local.png["Диаграмма локального контроля версий"] Одной из популярных VCS была система RCS, которая и сегодня распространяется со многими компьютерами. -https://www.gnu.org/software/rcs/[RCS^] хранит на диске наборы патчей (различий между файлами) в специальном формате, применяя которые она может воссоздавать состояние каждого файла в заданный момент времени. +https://www.gnu.org/software/rcs/[RCS^] хранит на диске наборы патчей (различий между файлами) в специальном формате, применяя которые, она может воссоздавать состояние каждого файла в заданный момент времени. ==== Централизованные системы контроля версий (((контроль версий,централизованный))) Следующая серьёзная проблема, с которой сталкиваются люди, -- это необходимость взаимодействовать с другими разработчиками. -Для того, чтобы разобраться с ней, были разработаны централизованные системы контроля версий (Centralized Version Control System, далее CVCS). -Такие системы, как CVS, Subversion и Perforce, используют единственный сервер, содержащий все версии файлов, и некоторое количество клиентов, которые получают файлы из этого централизованного хранилища. (((CVS)))(((Subversion)))(((Perforce))) +Для того чтобы разобраться с ней, были разработаны централизованные системы контроля версий (Centralized Version Control System, далее CVCS). +Такие системы как CVS, Subversion и Perforce используют единственный сервер, содержащий все версии файлов, и некоторое количество клиентов, которые получают файлы из этого централизованного хранилища. (((CVS)))(((Subversion)))(((Perforce))) Применение CVCS являлось стандартом на протяжении многих лет. .Централизованный контроль версий @@ -42,8 +42,8 @@ image::images/centralized.png["Диаграмма централизованно Несмотря на это, данный подход тоже имеет серьёзные минусы. Самый очевидный минус -- это единая точка отказа, представленная централизованным сервером. -Если этот сервер выйдет из строя на час, то в течение этого времени никто не сможет использовать контроль версий для сохранения изменений, над которыми работает, а также никто не сможет обмениваться этими изменениями с другими разработчиками. -Если жёсткий диск, на котором хранится центральная БД, повреждён, а своевременные бэкапы отсутствуют, вы потеряете всё -- всю историю проекта, не считая единичных снимков репозитория, которые сохранились на локальных машинах разработчиков. +Если этот сервер выйдет из строя на час, то в течение этого времени никто не сможет ни сохранить сделанные изменения, ни обменяться ими с другими разработчиками. +Если жёсткий диск, на котором хранится центральная база данных, повреждён, а своевременные бэкапы отсутствуют, вы потеряете всё -- всю историю проекта, не считая единичных снимков репозитория, которые сохранились на локальных машинах разработчиков. Локальные VCS страдают от той же самой проблемы: когда вся история проекта хранится в одном месте, вы рискуете потерять всё. ==== Распределённые системы контроля версий @@ -51,11 +51,11 @@ image::images/centralized.png["Диаграмма централизованно (((контроль версий,распределённый))) Здесь в игру вступают распределённые системы контроля версий (Distributed Version Control System, далее DVCS). В DVCS (таких как Git, Mercurial, Bazaar или Darcs) клиенты не просто скачивают снимок всех файлов (состояние файлов на определённый момент времени) -- они полностью копируют репозиторий. -В этом случае, если один из серверов, через который разработчики обменивались данными, умрёт, любой клиентский репозиторий может быть скопирован на другой сервер для продолжения работы. -Каждая копия репозитория является полным бэкапом всех данных. +В этом случае если один из серверов, через который разработчики обменивались данными, умрёт, любой клиентский репозиторий может быть скопирован на другой сервер для продолжения работы. +Каждая копия репозитория является полной копией всех данных. .Распределённый контроль версий image::images/distributed.png["Диаграмма распределённого контроля версий"] Более того, многие DVCS могут одновременно взаимодействовать с несколькими удалёнными репозиториями, благодаря этому вы можете работать с различными группами людей, применяя различные подходы единовременно в рамках одного проекта. -Это позволяет применять сразу несколько подходов в разработке, например, иерархические модели, что совершенно невозможно в централизованных системах. +Это позволяет применять сразу несколько подходов в разработке -- например, иерархические модели, -- что совершенно невозможно в централизованных системах. From ff64222dc7ddeb56628ef29fa94747a8fe8bcb94 Mon Sep 17 00:00:00 2001 From: Rikudo Date: Fri, 24 Jul 2026 21:09:17 +0300 Subject: [PATCH 2/2] =?UTF-8?q?=D0=9E=D1=82=D1=80=D0=B5=D0=B4=D0=B0=D0=BA?= =?UTF-8?q?=D1=82=D0=B8=D1=80=D0=BE=D0=B2=D0=B0=D0=BD=D0=BE:=20history.asc?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- book/01-introduction/sections/history.asc | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/book/01-introduction/sections/history.asc b/book/01-introduction/sections/history.asc index 1a19d432..4afe4a9c 100644 --- a/book/01-introduction/sections/history.asc +++ b/book/01-introduction/sections/history.asc @@ -1,6 +1,6 @@ === Краткая история Git -Как и многие вещи в жизни, Git начинался с капелькой творческого хаоса и бурных споров. +Как и многие вещи в жизни, Git начался с капельки творческого хаоса и бурных споров. Ядро Linux -- это достаточно большой проект с открытым исходным кодом.(((Linux))) Большую часть времени разработки ядра Linux (1991–2002 гг.) изменения передавались между разработчиками в виде патчей и архивов. @@ -10,11 +10,11 @@ Это сподвигло сообщество разработчиков ядра Linux (а в частности Линуса Торвальдса -- создателя Linux) разработать свою собственную утилиту, учитывая уроки, полученные при работе с BitKeeper.(((Линус Торвальдс))) Некоторыми целями, которые преследовала новая система, были: -* Скорость -* Простая архитектура -* Хорошая поддержка нелинейной разработки (тысячи параллельных веток) -* Полная децентрализация -* Возможность эффективного управления большими проектами, такими как ядро Linux (скорость работы и разумное использование дискового пространства) +* скорость; +* простая архитектура; +* хорошая поддержка нелинейной разработки (тысячи параллельных веток); +* полная децентрализация; +* возможность эффективного управления большими проектами, такими как ядро Linux (скорость работы и разумное использование дискового пространства). -С момента своего появления в 2005 году, Git развился в простую в использовании систему, сохранив при этом свои изначальные качества. +С момента своего появления в 2005 году Git развился в простую в использовании систему, сохранив при этом свои изначальные качества. Он удивительно быстр, эффективен в работе с большими проектами и имеет великолепную систему веток для нелинейной разработки (см. главу <>).