From 3c9980e5e5315287bb1d76825068c3c07f0ba616 Mon Sep 17 00:00:00 2001 From: Tikhon Tarnavsky Date: Tue, 27 Jul 2010 10:57:18 +0300 Subject: [PATCH] ru/clone.txt editing: five chapters left --- en/clone.txt | 3 +-- ru/clone.txt | 26 +++++++++++++------------- 2 files changed, 14 insertions(+), 15 deletions(-) diff --git a/en/clone.txt b/en/clone.txt index a81f976..5f10c80 100644 --- a/en/clone.txt +++ b/en/clone.txt @@ -66,8 +66,7 @@ To check in local changes into the central repository: $ git push If the main server has new changes due to activity by other developers, the -push fails, and the developer should pull the latest version, resolve any merge -conflicts, then try again. +push fails, and the developer should pull the latest version, resolve any merge conflicts, then try again. === Bare repositories === diff --git a/ru/clone.txt b/ru/clone.txt index ca8682f..c8a0c30 100644 --- a/ru/clone.txt +++ b/ru/clone.txt @@ -1,23 +1,23 @@ == Все о клонировании == -В старых системах управления версиями стандартная операция для получения файлов — это checkout. Вы получаете файлы в конкретном сохраненном состоянии. +В старых системах управления версиями стандартная операция для получения файлов — это checkout. Вы получаете набор файлов в конкретном сохраненном состоянии. -В Git и других распределенных системах управления версиями стандартный способ — клонирование. Для получение файлов вы создаете «клон» всего хранилища. Другими словами, вы создаете зеркало центрального сервера. При этом всё, что можно делать в основном хранилище, можно делать и в локальном. +В Git и других распределенных системах управления версиями стандартный способ — клонирование. Для получение файлов вы создаете «клон» всего хранилища. Другими словами, вы фактически создаете зеркало центрального сервера. При этом всё, что можно делать с основным хранилищем, можно делать и с локальным. === Синхронизация компьютеров === Я вполне приемлю создание архивов или использование *rsync* для резервного копирования и простейшей синхронизации. Но я работаю то на ноутбуке, то на стационарном компьютере, которые могут никак между собой не взаимодействовать между этим. -Создайте хранилище Git и сделайте коммит файлов на одном компьютере. А потом выполните на другом +Создайте хранилище Git и закоммитьте файлы на одном компьютере. А потом выполните на другом - $ git clone другой.компьютер:/путь/к/файлам + $ git clone первый.компьютер:/путь/к/файлам для создания второго экземпляра файлов и хранилища Git. С этого момента $ git commit -a $ git pull другой.компьютер:/путь/к/файлам HEAD -синхронизирует состояние ваших файлов с состоянием файлов другого компьютера. Если вы внесли конфликтующие изменения в один и тот же файл, Git даст вам знать, и нужно будет сделать коммит заново после устранения конфликта. +«втянет» состояние файлов с другого компьютера на тот, где вы работаете. Если вы недавно внесли конфликтующие изменения в один и тот же файл, Git даст вам знать, и нужно будет сделать коммит заново после разрешения ситуации. === Классическое управление исходным кодом === @@ -27,7 +27,7 @@ $ git add . $ git commit -m "Начальный коммит" -На центральном сервере создайте т.н. «голое» (bare) хранилище Git с неким именем: +На центральном сервере создайте т.н. «голое» (bare) хранилище Git в неком каталоге: $ mkdir proj.git $ cd proj.git @@ -64,21 +64,21 @@ $ git push -Если на главном сервере были новые изменения, сделанные другими разработчиками, команда push прервется с ошибкой. В этом случае разработчику нужно будет сгрузить к себе (pull) последнюю версию, разрешить возможные конфликты слияний и попробовать еще раз. +Если на главном сервере были новые изменения, сделанные другими разработчиками, команда push не сработает. В этом случае разработчику нужно будет сгрузить к себе (pull) последнюю версию, разрешить возможные конфликты слияний и попробовать еще раз. === Голые (bare) хранилища === Голое (bare) хранилище называются так потому, что у него нет рабочего каталога. Оно содержит только файлы, которые обычно скрыты в подкаталоге .git. Другими словами, голое хранилище содержит историю изменений, но не содержит снимка какой-либо определенной версии. -Голое хранилище играет роль, похожую на основной сервер в централизованной системе управления версиями: это дом вашего проекта. Разработчики клонируют с него проект и закачивают в него свежие официальные изменения. Как правило, он располагается на сервере, который не делает почти ничего кроме раздачи данных. Разработка идет в клонах, поэтому домашнее хранилище может обойтись и без рабочего каталога. +Голое хранилище играет роль, похожую на роль основного сервера в централизованной системе управления версиями: это дом вашего проекта. Разработчики клонируют с него проект и закачивают в него свежие официальные изменения. Как правило, он располагается на сервере, который не делает почти ничего кроме раздачи данных. Разработка идет в клонах, поэтому домашнее хранилище может обойтись и без рабочего каталога. -Многие команды Git не работают в голых хранилищах, если переменная среды GIT_DIR не содержит путь до хранилища или не указан параметр --bare. +Многие команды Git не работают в голых хранилищах, если переменная среды GIT_DIR не содержит путь до хранилища и не указан параметр --bare. === Push или pull? === -Зачем вводится команда push, вместо использования уже знакомой pull? Прежде всего, pull не работает в голых хранилищах, вместо нее нужно использовать команду 'fetch', которая будет рассмотрена позже. Но даже если держать на центральном сервере нормальное хранилище, использование команды pull в нем будет затруднительным. Нужно будет сначала войти на сервер интерактивно и сообщить команде pull адрес машины, с которой мы хотим забрать изменения. Этому могут мешать сетевые брандмауэры (firewall), но в первую очередь: что если у нас нет интерактивного доступа к серверу? +Зачем вводится команда push, вместо использования уже знакомой pull? Прежде всего, pull не работает в голых хранилищах, вместо нее нужно использовать команду fetch, которая будет рассмотрена позже. Но даже если держать на центральном сервере нормальное хранилище, использование команды pull в нем будет затруднительным. Нужно будет сначала войти на сервер интерактивно и сообщить команде pull адрес машины, с которой мы хотим забрать изменения. Этому могут мешать сетевые брандмауэры (firewall), но в первую очередь: что если у нас нет интерактивного доступа к серверу? -Тем не менее, не рекомендутся push-ить в хранилище помимо этого случая: из-за путаницы, которая может возникнуть, если у целевого хранилища есть рабочий каталог. +Тем не менее, не рекомендутся push-ить в хранилище помимо этого случая — из-за путаницы, которая может возникнуть, если у целевого хранилища есть рабочий каталог. Короче говоря, пока изучаете Git, push-те только в голые хранилища. В остальных случаях pull-те. @@ -96,11 +96,11 @@ === Максимальные бэкапы === -Хотите создать множество защищенных, географически разнесенных избыточных архивов? Если в вашем проекте много разработчиков, не делайте ничего! Каждый клон — это и есть резервная копия; не только текущего состояния, но и всей истории изменений проекта. Благодаря криптографическому хэшированию, повреждение какого-либо из клонов будет обнаружено при первой же попытке взаимодействия с другими клонами. +Хотите иметь множество защищенных, географически разнесенных избыточных архивов? Если в вашем проекте много разработчиков, ничего делать не нужно! Каждый клон — это и есть резервная копия; не только текущего состояния, но и всей истории изменений проекта. Благодаря криптографическому хешированию, повреждение какого-либо из клонов будет обнаружено при первой же попытке взаимодействия с другими клонами. Если ваш проект не такой популярный, найдите как можно больше серверов для размещения клонов. -Особо беспокоящимся рекомендуется всегда записывать самый последний 20-байтный SHA1 хэш HEAD в каком-нибудь безопасном месте. Оно должно быть безопасным, а не тайным. Например, хороший вариант — публикация в газете, потому что атакующему сложно изменить каждую копию газеты. +Особо беспокоящимся рекомендуется всегда записывать самый последний 20-байтный SHA1 хеш HEAD в каком-нибудь безопасном месте. Оно должно быть безопасным, а не тайным. Например, хороший вариант — публикация в газете, потому что атакующему сложно изменить каждый экземпляр газеты. === Многозадачность со скоростью света === -- 2.11.4.GIT