diff --git a/book/01-introduction/sections/about-version-control.asc b/book/01-introduction/sections/about-version-control.asc index afc4875d..11c36279 100644 --- a/book/01-introduction/sections/about-version-control.asc +++ b/book/01-introduction/sections/about-version-control.asc @@ -5,9 +5,9 @@ Система контроля версий -- это система, записывающая изменения в файл или набор файлов в течение времени и позволяющая вернуться позже к определённой версии. Для контроля версий файлов в этой книге в качестве примера будет использоваться исходный код программного обеспечения, хотя на самом деле вы можете использовать контроль версий практически для любых типов файлов. -Если вы графический или web-дизайнер и хотите сохранить каждую версию изображения или макета (скорее всего, захотите), система контроля версий (далее СКВ) -- как раз то, что нужно. +Если вы графический или web-дизайнер и хотите сохранить каждую версию изображения или макета (скорее всего, захотите), система контроля версий (далее VCS) -- как раз то, что нужно. Она позволяет вернуть файлы к состоянию, в котором они были до изменений, вернуть проект к исходному состоянию, увидеть изменения, увидеть, кто последний менял что-то и вызвал проблему, кто поставил задачу и когда и многое другое. -Использование СКВ также значит в целом, что, если вы сломали что-то или потеряли файлы, вы спокойно можете всё исправить. +Использование VCS также значит в целом, что, если вы сломали что-то или потеряли файлы, вы спокойно можете всё исправить. В дополнение ко всему вы получите всё это без каких-либо дополнительных усилий. ==== Локальные системы контроля версий @@ -17,45 +17,45 @@ Данный подход очень распространён из-за его простоты, однако он невероятно сильно подвержен появлению ошибок. Можно легко забыть в каком каталоге вы находитесь и случайно изменить не тот файл или скопировать не те файлы, которые вы хотели. -Для того, чтобы решить эту проблему, программисты давным-давно разработали локальные СКВ с простой базой данных, которая хранит записи о всех изменениях в файлах, осуществляя тем самым контроль ревизий. +Для того, чтобы решить эту проблему, программисты давным-давно разработали локальные VCS с простой базой данных, которая хранит записи о всех изменениях в файлах, осуществляя тем самым контроль ревизий. .Локальный контроль версий image::images/local.png["Диаграмма локального контроля версий"] -Одной из популярных СКВ была система RCS, которая и сегодня распространяется со многими компьютерами. +Одной из популярных VCS была система RCS, которая и сегодня распространяется со многими компьютерами. https://www.gnu.org/software/rcs/[RCS^] хранит на диске наборы патчей (различий между файлами) в специальном формате, применяя которые она может воссоздавать состояние каждого файла в заданный момент времени. ==== Централизованные системы контроля версий (((контроль версий,централизованный))) Следующая серьёзная проблема, с которой сталкиваются люди, -- это необходимость взаимодействовать с другими разработчиками. -Для того, чтобы разобраться с ней, были разработаны централизованные системы контроля версий (ЦСКВ). +Для того, чтобы разобраться с ней, были разработаны централизованные системы контроля версий (Centralized Version Control System, далее CVCS). Такие системы, как CVS, Subversion и Perforce, используют единственный сервер, содержащий все версии файлов, и некоторое количество клиентов, которые получают файлы из этого централизованного хранилища. (((CVS)))(((Subversion)))(((Perforce))) -Применение ЦСКВ являлось стандартом на протяжении многих лет. +Применение CVCS являлось стандартом на протяжении многих лет. .Централизованный контроль версий image::images/centralized.png["Диаграмма централизованного контроля версий"] -Такой подход имеет множество преимуществ, особенно перед локальными СКВ. +Такой подход имеет множество преимуществ, особенно перед локальными VCS. Например, все разработчики проекта в определённой степени знают, чем занимается каждый из них. -Администраторы имеют полный контроль над тем, кто и что может делать, и гораздо проще администрировать ЦСКВ, чем оперировать локальными базами данных на каждом клиенте. +Администраторы имеют полный контроль над тем, кто и что может делать, и гораздо проще администрировать CVCS, чем оперировать локальными базами данных на каждом клиенте. Несмотря на это, данный подход тоже имеет серьёзные минусы. Самый очевидный минус -- это единая точка отказа, представленная централизованным сервером. Если этот сервер выйдет из строя на час, то в течение этого времени никто не сможет использовать контроль версий для сохранения изменений, над которыми работает, а также никто не сможет обмениваться этими изменениями с другими разработчиками. Если жёсткий диск, на котором хранится центральная БД, повреждён, а своевременные бэкапы отсутствуют, вы потеряете всё -- всю историю проекта, не считая единичных снимков репозитория, которые сохранились на локальных машинах разработчиков. -Локальные СКВ страдают от той же самой проблемы: когда вся история проекта хранится в одном месте, вы рискуете потерять всё. +Локальные VCS страдают от той же самой проблемы: когда вся история проекта хранится в одном месте, вы рискуете потерять всё. ==== Распределённые системы контроля версий (((контроль версий,распределённый))) -Здесь в игру вступают распределённые системы контроля версий (РСКВ). -В РСКВ (таких как Git, Mercurial, Bazaar или Darcs) клиенты не просто скачивают снимок всех файлов (состояние файлов на определённый момент времени) -- они полностью копируют репозиторий. +Здесь в игру вступают распределённые системы контроля версий (Distributed Version Control System, далее DVCS). +В DVCS (таких как Git, Mercurial, Bazaar или Darcs) клиенты не просто скачивают снимок всех файлов (состояние файлов на определённый момент времени) -- они полностью копируют репозиторий. В этом случае, если один из серверов, через который разработчики обменивались данными, умрёт, любой клиентский репозиторий может быть скопирован на другой сервер для продолжения работы. Каждая копия репозитория является полным бэкапом всех данных. .Распределённый контроль версий image::images/distributed.png["Диаграмма распределённого контроля версий"] -Более того, многие РСКВ могут одновременно взаимодействовать с несколькими удалёнными репозиториями, благодаря этому вы можете работать с различными группами людей, применяя различные подходы единовременно в рамках одного проекта. +Более того, многие DVCS могут одновременно взаимодействовать с несколькими удалёнными репозиториями, благодаря этому вы можете работать с различными группами людей, применяя различные подходы единовременно в рамках одного проекта. Это позволяет применять сразу несколько подходов в разработке, например, иерархические модели, что совершенно невозможно в централизованных системах. diff --git a/book/01-introduction/sections/history.asc b/book/01-introduction/sections/history.asc index f3727ff6..1a19d432 100644 --- a/book/01-introduction/sections/history.asc +++ b/book/01-introduction/sections/history.asc @@ -4,7 +4,7 @@ Ядро Linux -- это достаточно большой проект с открытым исходным кодом.(((Linux))) Большую часть времени разработки ядра Linux (1991–2002 гг.) изменения передавались между разработчиками в виде патчей и архивов. -В 2002 году проект ядра Linux начал использовать проприетарную децентрализованную СКВ BitKeeper.(((BitKeeper))) +В 2002 году проект ядра Linux начал использовать проприетарную децентрализованную систему контроля версий BitKeeper.(((BitKeeper))) В 2005 году отношения между сообществом разработчиков ядра Linux и коммерческой компанией, которая разрабатывала BitKeeper, прекратились, и бесплатное использование утилиты стало невозможным. Это сподвигло сообщество разработчиков ядра Linux (а в частности Линуса Торвальдса -- создателя Linux) разработать свою собственную утилиту, учитывая уроки, полученные при работе с BitKeeper.(((Линус Торвальдс))) diff --git a/book/01-introduction/sections/what-is-git.asc b/book/01-introduction/sections/what-is-git.asc index 6086e496..922ca5c1 100644 --- a/book/01-introduction/sections/what-is-git.asc +++ b/book/01-introduction/sections/what-is-git.asc @@ -3,13 +3,13 @@ Что же такое Git, если говорить коротко? Очень важно понять эту часть материала, потому что если вы поймёте, что такое Git и основы того, как он работает, тогда, возможно, вам будет гораздо проще его использовать. -Пока вы изучаете Git, попробуйте забыть всё, что вы знаете о других СКВ, таких как Subversion и Perforce. +Пока вы изучаете Git, попробуйте забыть всё, что вы знаете о других системах контроля версий, таких как Subversion и Perforce. Это позволит вам избежать определённых проблем при использовании инструмента. Git хранит и использует информацию совсем иначе по сравнению с другими системами, даже несмотря на то, что интерфейс пользователя достаточно похож, и понимание этих различий поможет вам избежать путаницы во время использования.(((Subversion)))(((Perforce))) ==== Снимки, а не различия -Основное отличие Git от любой другой СКВ (включая Subversion и её собратьев) -- это подход к работе со своими данными. +Основное отличие Git от любой другой системы контроля версий (включая Subversion и её собратьев) -- это подход к работе со своими данными. Концептуально, большинство других систем хранят информацию в виде списка изменений в файлах. Эти системы (CVS, Subversion, Perforce, Bazaar и т. д.) представляют хранимую информацию в виде набора файлов и изменений, сделанных в каждом файле, по времени (обычно это называют контролем версий, _основанным на различиях_). @@ -25,7 +25,7 @@ Git представляет свои данные как, скажем, *пот .Хранение данных как снимков проекта во времени image::images/snapshots.png["Хранение данных как снимков проекта во времени"] -Это очень важное отличие между Git и почти любой другой СКВ. +Это очень важное различие между Git и почти любой другой системой контроля версий. Git переосмысливает практически все аспекты контроля версий, которые были скопированы из предыдущего поколения большинством других систем. Это делает Git больше похожим на миниатюрную файловую систему с удивительно мощными утилитами, надстроенными над ней, нежели просто на СКВ. Когда мы будем рассматривать управление ветками в главе <>, мы увидим, какие преимущества вносит такой подход к работе с данными в Git. @@ -33,7 +33,7 @@ Git переосмысливает практически все аспекты ==== Почти все операции выполняются локально Для работы большинства операций в Git достаточно локальных файлов и ресурсов -- в основном, системе не нужна никакая информация с других компьютеров в вашей сети. -Если вы привыкли к ЦСКВ, где большинство операций страдают от задержек из-за работы с сетью, то этот аспект Git заставит вас думать, что боги скорости наделили Git несказанной мощью. +Если вы привыкли к централизованным системам контроля версий, где большинство операций страдают от задержек из-за работы с сетью, то этот аспект Git заставит вас думать, что боги скорости наделили Git несказанной мощью. Так как вся история проекта хранится прямо на вашем локальном диске, большинство операций кажутся чуть ли не мгновенными. Для примера, чтобы посмотреть историю проекта, Git не нужно соединяться с сервером для её получения и отображения -- система просто считывает данные напрямую из локальной базы данных. @@ -71,7 +71,7 @@ SHA-1 хеш выглядит примерно так: Когда вы производите какие-либо действия в Git, практически все из них только _добавляют_ новые данные в базу Git. Очень сложно заставить систему удалить данные либо сделать что-то, что нельзя впоследствии отменить. -Как и в любой другой СКВ, вы можете потерять или испортить свои изменения, пока они не зафиксированы, но после того, как вы зафиксируете снимок в Git, будет очень сложно что-либо потерять, особенно, если вы регулярно синхронизируете свою базу с другим репозиторием. +Как и в любой другой системе контроля версий, вы можете потерять или испортить свои изменения, пока они не зафиксированы, но после того, как вы зафиксируете снимок в Git, будет очень сложно что-либо потерять, особенно, если вы регулярно синхронизируете свою базу с другим репозиторием. Всё это превращает использование Git в одно удовольствие, потому что мы знаем, что можем экспериментировать, не боясь серьёзных проблем. Для более глубокого понимания того, как Git хранит свои данные и как вы можете восстановить данные, которые кажутся утерянными, см. <>. diff --git a/book/02-git-basics/sections/tagging.asc b/book/02-git-basics/sections/tagging.asc index 22d34e3b..e4512f93 100644 --- a/book/02-git-basics/sections/tagging.asc +++ b/book/02-git-basics/sections/tagging.asc @@ -2,7 +2,7 @@ === Работа с тегами (((теги))) -Как и большинство СКВ, Git имеет возможность помечать определённые моменты в истории как важные. +Как и большинство других систем контроля версий, Git имеет возможность помечать определённые моменты в истории как важные. Как правило, эта функциональность используется для отметки моментов выпуска версий (v1.0, и т. п.). Такие пометки в Git называются тегами. В этом разделе вы узнаете, как посмотреть имеющиеся теги, как создать новые или удалить существующие, а также какие типы тегов существуют в Git. diff --git a/book/03-git-branching/sections/workflows.asc b/book/03-git-branching/sections/workflows.asc index 1d8e430d..7fc7fa54 100644 --- a/book/03-git-branching/sections/workflows.asc +++ b/book/03-git-branching/sections/workflows.asc @@ -36,7 +36,7 @@ image::images/lr-branches-2.png["Представление диаграммы (((ветки, тематические))) А вот такая вещь, как тематические ветки, полезна вне зависимости от величины проекта. Тематической веткой называется временная ветка, создаваемая и используемая для работы над конкретной функциональной возможностью или решения сопутствующих задач. -Скорее всего, при работе с другими СКВ вы никогда ничего подобного не делали, так как там создание и слияние веток -- затратные операции. +Скорее всего, при работе с другими системами контроля версий вы никогда ничего подобного не делали, так как там создание и слияние веток -- затратные операции. Но в Git это обычное дело -- много раз в день создавать ветки, работать с ними, сливать их и удалять. Пример тематических веток вы видели в предыдущем разделе, когда мы создавали ветки `iss53` и `hotfix`. diff --git a/book/05-distributed-git/sections/distributed-workflows.asc b/book/05-distributed-git/sections/distributed-workflows.asc index d80fbd68..606f174d 100644 --- a/book/05-distributed-git/sections/distributed-workflows.asc +++ b/book/05-distributed-git/sections/distributed-workflows.asc @@ -1,7 +1,7 @@ === Распределенный рабочий процесс (((рабочие процессы))) -В отличие от централизованных систем контроля версий (ЦСКВ), распределенная природа Git позволяет более гибко взаимодействовать разработчикам в рамках проекта. +В отличие от централизованных систем контроля версий, распределенная природа Git позволяет более гибко взаимодействовать разработчикам в рамках проекта. В централизованных системах каждый разработчик представляет собой узел, который более или менее одинаково взаимодействует с центральным хабом. Однако, в Git каждый разработчик это и узел и хаб, то есть каждый разработчик может как отправлять код в другие репозитории, так и поддерживать публичный репозиторий, в который другие разработчики смогут отправлять свой код, взяв его за основу. Это предоставляет огромное количество вариаций для организации рабочего процесса над проектом и/или для команды, поэтому мы расскажем об основных парадигмах, отражающих преимущество гибкости Git. @@ -19,7 +19,7 @@ image::images/centralized_workflow.png["Централизованный раб Это означает, что если два разработчика клонируют репозиторий и каждый внесёт изменения, то первый из них сможет отправить свои изменения в репозиторий без проблем. Второй разработчик должен слить изменения, сделанные первым разработчиком, чтобы избежать их перезаписи во время отправки на сервер. -Эта концепция верна как для Git, так и для Subversion(((Subversion))) (или любой ЦСКВ), и прекрасно работает в Git. +Эта концепция верна как для Git, так и для Subversion(((Subversion))) (или любой другой централизованной системы контроля версий), и прекрасно работает в Git. Если в вашей организации или команде уже используется централизованный рабочий процесс, то вам ничего не нужно менять для работы с Git. Достаточно создать один репозиторий и предоставить каждому члену команды push-доступ; Git не позволит перезаписать изменения, сделанные другими. diff --git a/book/09-git-and-other-scms/sections/client-bzr.asc b/book/09-git-and-other-scms/sections/client-bzr.asc index a1f06bc3..e2516201 100644 --- a/book/09-git-and-other-scms/sections/client-bzr.asc +++ b/book/09-git-and-other-scms/sections/client-bzr.asc @@ -1,7 +1,8 @@ ==== Git и Bazaar -Ещё одна известная ДСКВ https://bazaar.canonical.com[Bazaar^]. +Ещё одна известная распределённая система контроля версий https://bazaar.canonical.com[Bazaar^]. Bazaar -- это бесплатная система с открытым исходным кодом, являющаяся частью проекта https://www.gnu.org[GNU Project^]. + Её поведение сильно отличается от Git. Иногда, чтобы сделать то же самое, что и в Git, следует использовать другое ключевое слово, а некоторые такие же ключевые слова имеют другое значение. В частности, управления ветками сильно отличается и может вызвать путаницу, особенно для кого-нибудь из вселенной Git. diff --git a/book/09-git-and-other-scms/sections/client-hg.asc b/book/09-git-and-other-scms/sections/client-hg.asc index 5af6319d..46c7d9b9 100644 --- a/book/09-git-and-other-scms/sections/client-hg.asc +++ b/book/09-git-and-other-scms/sections/client-hg.asc @@ -296,7 +296,7 @@ o 0 0a04b987be5a 2005-08-26 01:20 -0700 mpm ---- Обратите внимание на метку `[featureA]` на пятой ревизии. -Таким образом, со стороны Git «закладки» выглядят как обычные ветки с одним лишь исключением: нельзя удалить закладку через Git (это одно из ограничений обёрток для взаимодействия с другими СКВ). +Таким образом, со стороны Git «закладки» выглядят как обычные ветки с одним лишь исключением: нельзя удалить закладку через Git (это одно из ограничений обёрток для взаимодействия с другими системами контроля версий). Можно работать и с полноценными ветками Mercurial -- просто поместите Git ветку в пространство имён `branches`: @@ -394,4 +394,4 @@ o 0 0a04b987be5a 2005-08-26 01:20 -0700 mpm ===== Заключение Git и Mercurial довольно похожи, их относительно просто можно «подружить». -Если вы будете избегать изменения уже опубликованной истории (это в целом хорошая идея, не только в контексте взаимодействия с Mercurial), вы даже не заметите что работаете с другой СКВ. +Если вы будете избегать изменения уже опубликованной истории (это в целом хорошая идея, не только в контексте взаимодействия с Mercurial), вы даже не заметите что работаете с другой системой контроля версий. diff --git a/book/09-git-and-other-scms/sections/client-p4.asc b/book/09-git-and-other-scms/sections/client-p4.asc index a4194c5c..1bef84d9 100644 --- a/book/09-git-and-other-scms/sections/client-p4.asc +++ b/book/09-git-and-other-scms/sections/client-p4.asc @@ -3,7 +3,7 @@ (((Взаимодействие с другими VCS, Perforce))) (((Perforce))) Perforce -- очень распространённая система контроля версий в корпоративной среде. -Она появилась в 1995 году, что делает её самой старой СКВ, рассматриваемой в этой главе. +Она появилась в 1995 году, что делает её самой старой системой контроля версий, рассматриваемой в этой главе. Perforce разработан в духе тех времён; он предполагает постоянное подключение к центральному серверу, а локально хранится одна-единственная версия файлов. На самом деле, его возможности, как и ограничения, разрабатывались для решения вполне конкретных проблем; хотя многие проекты, использующие Perforce сегодня, выиграли бы от перехода на Git. diff --git a/book/09-git-and-other-scms/sections/client-svn.asc b/book/09-git-and-other-scms/sections/client-svn.asc index 7a88975f..985cf4bc 100644 --- a/book/09-git-and-other-scms/sections/client-svn.asc +++ b/book/09-git-and-other-scms/sections/client-svn.asc @@ -11,7 +11,7 @@ Этот инструмент позволяет использовать Git в качестве полноценного SVN клиента; вы можете использовать всю функциональность Git для работы с локальным репозиторием, скомпоновать ревизии и отправить их на сервер, словно вы использовали обычный SVN. Да, вы не ослышались: можно создавать локальные ветки, производить слияния, использовать индекс для неполного применения изменений, перемещать коммиты и повторно применять их (cherry-pick) и т. д., в то время как ваши коллеги, использующие SVN, застряли в палеолите. Это отличный способ по-партизански внедрить Git в процесс разработки и помочь соратниками стать более продуктивными, а затем потребовать от инфраструктуры полной поддержки Git. -`git svn` -- это первый укол наркотика «РСКВ», вызывающего сильнейшее привыкание. +`git svn` -- это первый укол наркотика «DVCS», вызывающего сильнейшее привыкание. ===== `git svn` diff --git a/book/09-git-and-other-scms/sections/import-bzr.asc b/book/09-git-and-other-scms/sections/import-bzr.asc index 4d85cb6c..1d1b6e33 100644 --- a/book/09-git-and-other-scms/sections/import-bzr.asc +++ b/book/09-git-and-other-scms/sections/import-bzr.asc @@ -1,7 +1,7 @@ ==== Bazaar (((Bazaar)))(((Импорт, из Bazaar))) -Bazaar это ДСКВ очень похожая на Git, поэтому репозиторий Bazaar достаточно легко сконвертировать в репозиторий Git. +Bazaar -- это распределённая система контроля версий очень похожая на Git, поэтому репозиторий Bazaar достаточно легко сконвертировать в репозиторий Git. Для этого вам необходимо подключить плагин `bzr-fastimport`. ===== Установка плагина bzr-fastimport diff --git a/book/09-git-and-other-scms/sections/import-custom.asc b/book/09-git-and-other-scms/sections/import-custom.asc index 9931a495..e4a58d74 100644 --- a/book/09-git-and-other-scms/sections/import-custom.asc +++ b/book/09-git-and-other-scms/sections/import-custom.asc @@ -4,7 +4,7 @@ (((команды git, fast-import))) (((Импорт, из других))) Если вы пользуетесь какой-либо другой системой контроля версий, не перечисленной выше, вам следует поискать инструмент для импорта в Сети -- качественные решения доступны для CVS, Clear Case, Visual Source Safe и даже каталогов с архивами. -Если всё же существующие решения вам не подошли, вы пользуетесь менее известной СКВ или вам нужно больше контроля над процессом импорта -- используйте `git fast-import`. +Если всё же существующие решения вам не подошли, вы пользуетесь менее известной системой контроля версий или вам нужно больше контроля над процессом импорта -- используйте `git fast-import`. Эта команда читает простые инструкции из потока ввода и записывает данные в Git. Создать Git-объекты таким путём намного проще, чем через низкоуровневые Git-команды или пытаясь воссоздать их вручную (обратитесь к главе <> за деталями). Таким образом, вы можете написать небольшой скрипт, считывающий нужную информацию из вашего хранилища и выводящий инструкции в стандартный поток вывода. diff --git a/book/10-git-internals/sections/plumbing-porcelain.asc b/book/10-git-internals/sections/plumbing-porcelain.asc index 86523d27..f28bc9c5 100644 --- a/book/10-git-internals/sections/plumbing-porcelain.asc +++ b/book/10-git-internals/sections/plumbing-porcelain.asc @@ -2,7 +2,7 @@ === Сантехника и Фарфор В этой книге было описано, как пользоваться Git, применяя примерно три десятка команд, таких как `checkout`, `branch`, `remote` и так далее. -Но так как сначала Git был скорее инструментарием для создания системы контроля версий, чем самой СКВ, удобной для пользователей, то в нём полно команд, выполняющих низкоуровневые операции, которые спроектированы так, чтобы их можно было использовать объединив в цепочку в стиле UNIX, а также использовать в скриптах. +Но так как сначала Git был скорее инструментарием для создания системы контроля версий, чем самой VCS, удобной для пользователей, то в нём полно команд, выполняющих низкоуровневые операции, которые спроектированы так, чтобы их можно было использовать объединив в цепочку в стиле UNIX, а также использовать в скриптах. Эти команды, как правило, называют служебными («plumbing» -- трубопровод), а ориентированные на пользователя называют пользовательскими («porcelain» -- фарфор). Первые девять глав книги были посвящены в основном пользовательским командам. diff --git a/book/introduction.asc b/book/introduction.asc index f5f8e776..71be0874 100644 --- a/book/introduction.asc +++ b/book/introduction.asc @@ -5,7 +5,7 @@ Давайте уделим минуту на объяснение, что же вы получите. Здесь представлено краткое описание десяти глав и трёх приложений данной книги. -В *Главе 1* мы охватим Системы Контроля Версий (VCS) и азы Git. +В *Главе 1* мы охватим системы контроля версий (Version Control System, VCS) и азы Git. Никаких технических штучек, только то, что, собственно, такое Git, почему он пришёл на землю уже полную систем контроля версий, что его отличает и почему так много людей им пользуются. Затем мы объясним как впервые скачать и настроить Git, если в вашей системе его ещё нет. diff --git a/ch03-git-branching.asc b/ch03-git-branching.asc index dc7a20c5..e2defacc 100644 --- a/ch03-git-branching.asc +++ b/ch03-git-branching.asc @@ -2,14 +2,14 @@ == Ветвление в Git (((ветки))) -Почти каждая система контроля версий (СКВ) в какой-то форме поддерживает ветвление. +Почти каждая система контроля версий в той или иной форме поддерживает ветвление. Используя ветвление, Вы отклоняетесь от основной линии разработки и продолжаете работу независимо от неё, не вмешиваясь в основную линию. -Во многих СКВ создание веток -- это очень затратный процесс, часто требующий создания новой копии каталога с исходным кодом, что может занять много времени для большого проекта. +Во многих системах контроля версий создание веток -- это очень затратный процесс, часто требующий создания новой копии каталога с исходным кодом, что может занять много времени для большого проекта. -Некоторые люди, говоря о модели ветвления Git, называют её «киллер-фича», что выгодно выделяет Git на фоне остальных СКВ. +Некоторые люди, говоря о модели ветвления Git, называют её «киллер-фича», что выгодно выделяет Git на фоне остальных систем контроля версий. Что в ней такого особенного? Ветвление Git очень легковесно: операция создания ветки выполняется почти мгновенно, переключение между ветками туда-сюда, обычно, также быстро. -В отличие от многих других СКВ, Git поощряет процесс работы, при котором ветвление и слияние выполняется часто, даже по несколько раз в день. +В отличие от многих других систем контроля версий, Git поощряет процесс работы, при котором ветвление и слияние выполняется часто, даже по несколько раз в день. Понимание и владение этой функциональностью дает вам уникальный и мощный инструмент, который может полностью изменить привычный процесс разработки. include::book/03-git-branching/sections/nutshell.asc[] diff --git a/ch09-git-and-other-systems.asc b/ch09-git-and-other-systems.asc index ab306824..4ef183f8 100644 --- a/ch09-git-and-other-systems.asc +++ b/ch09-git-and-other-systems.asc @@ -12,7 +12,7 @@ === Git как клиент (((Git как клиент))) -Git оставляет настолько положительное впечатление у разработчиков, что многие из них придумывают способы, как использовать его на своём компьютере, в случае если остальная часть команды использует другую СКВ. +Git оказывает настолько положительное впечатление на разработчиков, что многие из них придумывают способы, как использовать его на своём компьютере, в случае если остальная часть команды использует другую систему контроля версий. Для этого разработан целый ряд специальных адаптеров, называемых «мостами» («bridges»). Здесь мы рассмотрим те, с которыми вы, скорее всего, столкнётесь при работе над реальными проектами. @@ -28,9 +28,9 @@ include::book/09-git-and-other-scms/sections/client-p4.asc[] === Переход на Git (((переход на Git))) -Если у вас уже есть кодовая база в другой СКВ, но вы решили начать использовать Git, вам необходимо перенести проект тем или иным способом. +Если у вас уже есть кодовая база в другой системе контроля версий, но вы решили начать использовать Git, вам необходимо перенести проект тем или иным способом. В этом разделе описаны некоторые существующие варианты импорта для распространённых систем, а затем показано, как разрабатывать собственные нестандартные варианты импорта. -Вы узнаете, как импортировать данные из некоторых основных профессионально используемых СКВ, так как они используются большинством разработчиков, желающих переключиться на использование Git, а так же для них легко найти качественные инструменты миграции. +Вы узнаете, как импортировать данные из некоторых основных профессионально используемых систем контроля версий, так как они используются большинством разработчиков, желающих переключиться на использование Git, а так же для них легко найти качественные инструменты миграции. include::book/09-git-and-other-scms/sections/import-svn.asc[] @@ -44,5 +44,5 @@ include::book/09-git-and-other-scms/sections/import-custom.asc[] === Заключение -После всего вышесказанного вы должны чувствовать себя уверенно, используя Git как клиент для других СКВ, или, импортируя практически любой существующий репозиторий в Git без потери данных. +После всего вышесказанного вы должны чувствовать себя уверенно, используя Git как клиент для других систем контроля версий или импортируя практически любой существующий репозиторий в Git без потери данных. Следующая глава раскроет перед вами внутреннюю механику Git, так что вы будете способны контролировать каждый байт данных, если это потребуется.