From b572024acf75034834cf6a082e693a96b4dee96b Mon Sep 17 00:00:00 2001 From: Tikhon Tarnavsky Date: Fri, 17 Dec 2010 20:29:07 +0200 Subject: [PATCH] many minor edits in ru/*.txt --- ru/branch.txt | 26 +++++++++++++------------- ru/clone.txt | 4 ++-- ru/drawbacks.txt | 2 +- ru/grandmaster.txt | 4 ++-- ru/history.txt | 4 ++-- ru/multiplayer.txt | 20 ++++++++++---------- ru/secrets.txt | 8 ++++---- 7 files changed, 34 insertions(+), 34 deletions(-) diff --git a/ru/branch.txt b/ru/branch.txt index f85a829..a04f00f 100644 --- a/ru/branch.txt +++ b/ru/branch.txt @@ -10,7 +10,7 @@ *Решение*: у Git есть более удобный инструмент для таких случаев, который сэкономит и время, и дисковое пространство по сравнению с клонированием — это *git branch* (branch — ветка, прим. пер.). -Этим волшебным словом файлы в вашем каталоге мгновенно преобразуются от одной версии к другой. Это изменение позволяет сделать намного больше, чем просто вернуться назад или продвинуться вперед в истории. Ваши файлы могут изменится с последней выпущенной версии на экспериментальную, с экспериментальной — на текущую версию в разработке, с неё — на версию вашего друга и так далее. +Этим волшебным словом файлы в вашем каталоге мгновенно преобразуются от одной версии к другой. Это изменение позволяет сделать намного больше, чем просто вернуться назад или продвинуться вперед в истории. Ваши файлы могут изменится с последней выпущенной версии на экспериментальную, с экспериментальной — на текущую версию в разработке, с нее — на версию вашего друга и так далее. === Кнопка босса === @@ -61,9 +61,9 @@ $ git checkout dirty -Мы говорили об этой команде в одной из предыдущих глав, когда обсуждали загрузку старых состояний. Теперь у нас перед глазами полная картина: файлы изменились к нужному состоянию, но мы должны покинуть ветвь master. Любые коммиты, сделанные с этого момента, направят файлы по другому пути, который может быть указан позже. +Мы говорили об этой команде в одной из предыдущих глав, когда обсуждали загрузку старых состояний. Теперь у нас перед глазами полная картина: файлы изменились к нужному состоянию, но мы должны покинуть главную ветку. Любые коммиты, сделанные с этого момента, направят файлы по другому пути, к которому можно будет вернуться позже. -Другими словами, после переключения на более старое состояние Git автоматически направляет вас по новой безымянной ветке, которой можно дать имя и сохранить с помощью *git checkout -b*. +Другими словами, после переключения на более старое состояние Git автоматически направляет вас по новой безымянной ветке, которой можно дать имя и сохранить ее с помощью *git checkout -b*. === Быстрые исправления === @@ -87,7 +87,7 @@ В некоторых системах управления версиями создавать ветки легко, а вот сливать их воедино трудно. В Git слияние столь тривиально, что вы можете его не заметить. -На самом деле мы сталкивались со слияниями уже давно. Команда *pull* по сути получает коммиты, а затем сливает их с вашей текущей веткой. Если у вас нет локальных изменений, слияние произойдёт само собой, как вырожденный случай вроде получения последней версии в централизованной системе управления версиями. Если же у вас есть локальные изменения, Git автоматически произведет слияние и сообщит о любых конфликтах. +На самом деле мы сталкивались со слияниями уже давно. Команда *pull* по сути получает коммиты, а затем сливает их с вашей текущей веткой. Если у вас нет локальных изменений, слияние произойдет само собой, как вырожденный случай вроде получения последней версии в централизованной системе управления версиями. Если же у вас есть локальные изменения, Git автоматически произведет слияние и сообщит о любых конфликтах. Обычно у коммита есть один «родитель», а именно предыдущий коммит. Слияние веток приводит к коммиту как минимум с двумя родителями. Отсюда возникает вопрос: к какому коммиту на самом деле отсылает HEAD~10? Коммит может иметь несколько родителей, так за которым из них следовать далее? @@ -113,7 +113,7 @@ И в разработке ПО может быть то же. Вторая часть нового функционала может быть вынуждена ожидать выпуска и тестирования первой части. Некоторые проекты требуют проверки вашего кода перед его принятием, так что вы должны дождаться утверждения первой части, прежде чем начинать вторую. -Благодаря безболезненным ветвлению и слиянию, мы можем изменить правила и работать над второй частью до того, как первая официально будет готова. Допустим, вы закоммитили первую часть и выслали её на проверку. Скажем, вы в ветке master. Теперь смените ветку: +Благодаря безболезненным ветвлению и слиянию, мы можем изменить правила и работать над второй частью до того, как первая официально будет готова. Допустим, вы закоммитили первую часть и выслали ее на проверку. Скажем, вы в ветке master. Теперь смените ветку: $ git checkout -b part2 # часть2 @@ -125,7 +125,7 @@ $ git checkout part2 # Возвращаемся ко второй части. $ git merge master # Вливаем сделанные исправления. -В конечном счёте, первая часть утверждена: +В конечном счете, первая часть утверждена: $ git checkout master # Возвращаемся к первой части. $ отправка файлов # Выпускаем в мир! @@ -134,21 +134,21 @@ Теперь вы снова в ветке master, а вторая часть — в вашем рабочем каталоге. -Этот приём легко расширить на любое количество частей. Столь же легко сменить ветку задним числом. Предположим, вы слишком поздно обнаружили, что должны были создать ветку семь коммитов назад. Тогда введите: +Этот прием легко расширить на любое количество частей. Столь же легко сменить ветку задним числом. Предположим, вы слишком поздно обнаружили, что должны были создать ветку семь коммитов назад. Тогда введите: $ git branch -m master part2 # Переименовываем ветку master в part2. - $ git branch master HEAD~7 # Создаём новую ветку master семью коммитами выше. + $ git branch master HEAD~7 # Создаем новую ветку master семью коммитами выше. -Теперь ветка master содержит только первую часть, а ветка part2 — всё остальное. В последней мы и находимся. Мы создали ветку master, не переключаясь на неё, потому что хотим продолжить работу над part2. Это непривычно: до сих пор мы переключались на ветки сразу же после их создания, вот так: +Теперь ветка master содержит только первую часть, а ветка part2 — всё остальное. В последней мы и находимся. Мы создали ветку master, не переключаясь на нее, потому что хотим продолжить работу над part2. Это непривычно: до сих пор мы переключались на ветки сразу же после их создания, вот так: - $ git checkout HEAD~7 -b master # Создаём ветку и переключаемся на неё. + $ git checkout HEAD~7 -b master # Создаем ветку и переключаемся на нее. === Изменяем состав смеси === Предположим, вам нравится работать над всеми аспектами проекта в одной и той же ветке. Вы хотите закрыть свой рабочий процесс от других, чтобы все видели ваши коммиты только после того, как они будут хорошо оформлены. Создайте пару веток: - $ git branch sanitized # Создаём ветку для очищенных коммитов. - $ git checkout -b medley # Создаём ветку для работы и переключаемся на неё. + $ git branch sanitized # Создаем ветку для очищенных коммитов. + $ git checkout -b medley # Создаем ветку для работы и переключаемся на нее. Далее делайте всё что нужно: исправляйте ошибки, добавляйте новые функции, добавляйте временный код и так далее, при этом почаще выполняя коммиты. После этого @@ -171,7 +171,7 @@ === Временные Ветки === -Через какое-то время вы можете обнаружить, что создаете множество временных веток для одной и той же краткосрочной цели: каждая такая ветка всего лишь сохраняет текущее состояние, чтобы вы могли вернуться назад и исправить серьёзную ошибку или сделать что-то еще. +Через какое-то время вы можете обнаружить, что создаете множество временных веток для одной и той же краткосрочной цели: каждая такая ветка всего лишь сохраняет текущее состояние, чтобы вы могли вернуться назад и исправить серьезную ошибку или сделать что-то еще. Это похоже на то, как вы переключаете телевизионные каналы, чтобы посмотреть что показывают по другим. Но вместо того, чтобы нажать на пару кнопок, вам нужно создавать, выбирать (checkout), сливать (merge) а затем удалять временные ветки. К счастью, в Git есть сокращенная команда, столь же удобная, как пульт дистанционного управления. diff --git a/ru/clone.txt b/ru/clone.txt index 1454bf4..2982258 100644 --- a/ru/clone.txt +++ b/ru/clone.txt @@ -12,12 +12,12 @@ $ git clone первый.компьютер:/путь/к/файлам -для создания второго экземпляра файлов и хранилища Git. С этого момента +для создания второго экземпляра файлов и хранилища Git. С этого момента команды $ git commit -a $ git pull другой.компьютер:/путь/к/файлам HEAD -«втянет» состояние файлов с другого компьютера на тот, где вы работаете. Если вы недавно внесли конфликтующие изменения в один и тот же файл, Git даст вам знать, и нужно будет сделать коммит заново после разрешения ситуации. +будут «втягивать» состояние файлов с другого компьютера на тот, где вы работаете. Если вы недавно внесли конфликтующие изменения в один и тот же файл, Git даст вам знать, и нужно будет сделать коммит заново после разрешения ситуации. === Классическое управление исходным кодом === diff --git a/ru/drawbacks.txt b/ru/drawbacks.txt index ddd5a94..cebd1f9 100644 --- a/ru/drawbacks.txt +++ b/ru/drawbacks.txt @@ -54,7 +54,7 @@ Git была написан, чтобы быть быстрым при отно Возможно, вам была нужна база данных или система резервного/архивного копирования, а не система управления версиями. Например, управление версиями может быть плохо приспособлено для обращения с фотографиями периодически получаемыми с веб-камеры. -Если файлы действительно должны постоянно изменяться и при этом версироваться, может иметь смысл использовать Git централизованным образом. Можно создать мелкие клоны, с небольшой историей или без истории вообще. Конечно, многие инструменты Git будут недоступны, и исправления придется представлять в виде патчей. Возможно, это и хорошо, так как неясно, зачем кому-либо понадобится история крайне нестабильных файлов. +Если файлы действительно должны постоянно изменяться и при этом версироваться, может иметь смысл использовать Git централизованным образом. Можно создавать мелкие клоны, с небольшой историей или без истории вообще. Конечно, многие инструменты Git будут недоступны, и исправления придется представлять в виде патчей. Возможно, это и хорошо, так как неясно, зачем кому-либо понадобится история крайне нестабильных файлов. Другой пример — это проект, зависимый от прошивки, принимающей форму огромного двоичного файла. Ее история неинтересна пользователям, а обновления плохо сжимаются, потому ревизии прошивки будут неоправдано раздувать размер хранилища. diff --git a/ru/grandmaster.txt b/ru/grandmaster.txt index 3b7bb1b..347790a 100644 --- a/ru/grandmaster.txt +++ b/ru/grandmaster.txt @@ -149,7 +149,7 @@ Git записывает каждый подсчитанный им хеш ко Аналогично, попытка перезаписи ветки путем перемещения будет прервана, если может привести к потере данных. Для принудительного перемещений ветки введите - $ git branch -M источник цель #вместо -m + $ git branch -M источник цель # вместо -m В отличии от checkout и reset, эти две команды дают отсрочку в удалении данных. Изменения остаются в каталоге .git и могут быть возвращены восстановлением нужного хеша из .git/logs (смотрите выше раздел «Охота за „головами“»). По умолчанию они будут храниться по крайней мере две недели. @@ -179,4 +179,4 @@ if git ls-files -o | grep '\.txt$'; then exit 1 fi -Несколько операций Git поддерживают хуки, смотрите *git help hooks*. Мы использовали пример хука *post-update* раньше, при обсуждении использования Git через http. Он запускался при каждом перемещении «головы». Пример скрипта *post-update* обновляет файлы, которые нужны Git для связи через не считающиеся с ним средства сообщения, такие как HTTP. +Хуки поддерживаются несколькими различными операциями Git, смотрите *git help hooks*. Мы использовали пример хука *post-update* раньше, при обсуждении использования Git через http. Он запускался при каждом перемещении «головы». Пример скрипта *post-update* обновляет файлы, которые нужны Git для связи через не считающиеся с ним средства сообщения, такие как HTTP. diff --git a/ru/history.txt b/ru/history.txt index 9eeca6b..e3a2dc1 100644 --- a/ru/history.txt +++ b/ru/history.txt @@ -57,7 +57,7 @@ Git учитывает оба мнения. Переписывание исто Это работа для команды *git rebase*, описанной выше. Зачастую, имеет смысл использовать флаг *--onto* и убрать переплетения. -Также смотрите *git help rebase* для получения подробных примеров использования этой замечательной команды. Вы можете расщеплять коммиты. Вы можете даже переупорядочить ветки. +Также смотрите *git help rebase* для получения подробных примеров использования этой замечательной команды. Вы можете расщеплять коммиты. Вы можете даже переупорядочивать ветки. === Переписывая историю === @@ -127,7 +127,7 @@ $ git fast-import --date-format=rfc2822 < /tmp/history === Когда же все пошло не так? === -Вы только что обнаружили, что кое-какой функционал вашей программы не работает, но вы совершенно отчетливо помните, что он работал всего несколько месяцев назад. Ну вот, блин! Откуда же взялась ошибка? Вы же это проверяли сразу как разработали. +Вы только что обнаружили, что кое-какой функционал вашей программы не работает, но вы совершенно отчетливо помните, что он работал всего несколько месяцев назад. Ох… Откуда же взялась ошибка? Вы же это проверяли сразу как разработали. В любом случае, уже слишком поздно. Однако, если вы фиксировали свои изменения достаточно часто, то Git сможет точно указать проблему: diff --git a/ru/multiplayer.txt b/ru/multiplayer.txt index ea90275..97a098c 100644 --- a/ru/multiplayer.txt +++ b/ru/multiplayer.txt @@ -2,7 +2,7 @@ Сначала я использовал Git для личного проекта, в котором был единственным разработчиком. Среди команд, относящихся к распределенным свойствам Git, мне были нужны только *pull* и *clone*, чтобы хранить один и тот же проект в разных местах. -Позднее я захотел опубликовать свой код при помощи Git и включать изменения помощников. Мне пришлось научиться управлять проектами, которые с многими разработчиками по всему миру. К счастью, в этом сильная сторона Git и, возможно, сам смысл его существования. +Позднее я захотел опубликовать свой код при помощи Git и включать изменения помощников. Мне пришлось научиться управлять проектами, в которых участвуют многие люди по всему миру. К счастью, в этом сильная сторона Git и, возможно, сам смысл его существования. === Кто я? === @@ -36,11 +36,11 @@ hooks/post-update Теперь вы можете публиковать свои последние правки через SSH с любого клона: $ git push -web.server:/path/to/proj.git master +веб.сервер:/путь/к/proj.git master и кто угодно сможет взять ваш проект с помощью - $ git clone http://web.server/proj.git + $ git clone http://веб.сервер/proj.git === Git через что угодно === @@ -54,9 +54,9 @@ web.server:/path/to/proj.git master $ git pull некий-файл -Получатель может сделать это даже в пустом хранилище. Несмотря на свой размер, +некий-файл+ содержит всё исходное хранилище Git. +Получатель может сделать это даже в пустом хранилище. Несмотря на свой небольшой размер, +некий-файл+ содержит всё исходное хранилище Git. -В больших проектах для устраннения излишков объема пакетируют только изменения, которых нет в других хранилищах. К примеру, пусть коммит «1b6d…» — последний, общий для обеих групп: +В больших проектах для устранения излишков объема пакетируют только изменения, которых нет в других хранилищах. К примеру, пусть коммит «1b6d…» — последний общий для обеих групп: $ git bundle create некий-файл HEAD ^1b6d @@ -115,7 +115,7 @@ web.server:/path/to/proj.git master Опция +branch.master.merge+ задает удаленную ветку по умолчанию для *git pull*. В ходе первоначального клонирования она устанавливается на текущую ветку исходного хранилища, так что даже если HEAD исходного хранилища впоследствии переместится на другую ветку, pull будет верно следовать изначальной ветке. -Этот параметр обращается только к хранилищу, который мы изначально клонировали и который записан в параметре +branch.master.remote+. При выполнении pull из других хранилищ мы должны указать нужную ветку: +Этот параметр обращается только к хранилищу, которое мы изначально клонировали и которое записано в параметре +branch.master.remote+. При выполнении pull из других хранилищ мы должны указать нужную ветку: $ git pull git://пример.com/other.git master @@ -155,7 +155,7 @@ web.server:/path/to/proj.git master $ git diff origin/experimental^ other/некая_ветка~5 -Но что, если мы просто хотим сравнить их изменения, не затрагивая свою работу? Иными словами, мы хотим изучить чужие ветки, не давая их изменениям вторгаться в наш рабочий каталог. Тогда вместо pull наберите +Но что если мы просто хотим сравнить их изменения, не затрагивая свою работу? Иными словами, мы хотим изучить чужие ветки, не давая их изменениям вторгаться в наш рабочий каталог. Тогда вместо pull наберите $ git fetch # Перенести из origin, по умолчанию. @@ -166,7 +166,7 @@ other/некая_ветка~5 Держим в уме, что pull это просто *fetch*, а затем *merge*. Обычно мы используем *pull*, потому что мы хотим влить к себе последний коммит после получения чужой ветки. Описанная ситуация — примечательное исключение. -О том, как отключить удаленные хранилища, игнорировать отдельные ветки и многом другом смотрите *git help remote*. +О том, как отключить удаленные хранилища, игнорировать отдельные ветки и многом другом смотрите в *git help remote*. === Мои Настройки === @@ -174,6 +174,6 @@ other/некая_ветка~5 После получения дерева из удаленного хранилища я запускаю команды Git для навигации и изучения изменений, в идеале хорошо организованных и описанных. Я делаю слияние со своими изменения и возможно вношу дальнейшие правки. Когда я доволен результатом, я заливаю изменения в главное хранилище. -Хотя со мной мало сотрудничают, я верю, что этот подход хорошо масштабируется. Смотрите http://torvalds-family.blogspot.com/2009/06/happiness-is-warm-scm.html[эту пост в блоге Линуса Торвальдса]. +Хотя со мной мало сотрудничают, я верю, что этот подход хорошо масштабируется. Смотрите http://torvalds-family.blogspot.com/2009/06/happiness-is-warm-scm.html[эту запись в блоге Линуса Торвальдса]. -Оставаться в мире Git несколько удобнее, чем использовать патч-файлы, так как это избавляет меня от преобразования их в коммиты Git. Кроме того, Git управляет деталями вроде сохранения имени автора и адреса электронной почты, а также даты и времени, и просит авторов описывать свои изменения. +Оставаться в мире Git несколько удобнее, чем использовать файлы патчей, так как это избавляет меня от преобразования их в коммиты Git. Кроме того, Git управляет деталями вроде сохранения имени автора и адреса электронной почты, а также даты и времени, и просит авторов описывать свои изменения. diff --git a/ru/secrets.txt b/ru/secrets.txt index b482c99..a0769ce 100644 --- a/ru/secrets.txt +++ b/ru/secrets.txt @@ -6,7 +6,7 @@ Как Git может быть таким ненавязчивым? За исключением периодических коммитов и слияний, вы можете работать так, как будто и не подозреваете о каком-то управлении версиями. Так происходит до того момента, когда Git вам понадобится, и тогда вы с радостью увидите, что он наблюдал за вами все это время. -Другие системы управления версиями вынуждают вас постоянно бороться с загородками и бюрократией. Файлы могут быть доступны только для чтения, пока вы явно не укажите центральному серверу, какие файлы вы намереваетесь редактировать. С увеличением количества пользователей большинство базовых команд начинают ползать всё медленнее. Неполадки с сетью или с центральным сервером полностью останавливают работу. +Другие системы управления версиями вынуждают вас постоянно бороться с загородками и бюрократией. Файлы могут быть доступны только для чтения, пока вы явно не укажете центральному серверу, какие файлы вы намереваетесь редактировать. С увеличением количества пользователей большинство базовых команд начинают ползать всё медленнее. Неполадки с сетью или с центральным сервером полностью останавливают работу. В противоположность этому, Git просто хранит историю проекта в подкаталоге .git вашего рабочего каталога. Это ваша личная копия истории, поэтому вы можете оставаться вне сети, пока не захотите взаимодействовать с остальными. У вас есть полный контроль над судьбой ваших файлов, поскольку Git может легко восстановить сохраненное состояние из .git в любое время. @@ -18,7 +18,7 @@ SHA1 хеш можно рассматривать как уникальный 16 Так как SHA1 хеш сам является последовательностью байтов, мы можем получить хеш строки байтов, содержащей другие хеши. Это простое наблюдение на удивление полезно: ищите «hash chains» (цепочки хешей). Позднее мы увидим, как Git использует их для эффективного обеспечения целостности данных. -Говоря кратко, Git хранит ваши данные в подкаталоге ".git/objects", где вместо нормальных имен файлов вы найдете только идентификаторы. Благодаря использованию идентификаторов в качестве имен файлов, а также некоторым хитростям с файлами блокировки временными метками, Git преобразует любую скромную файловую систему в эффективную и надежную базу данных. +Говоря кратко, Git хранит ваши данные в подкаталоге ".git/objects", где вместо нормальных имен файлов вы найдете только идентификаторы. Благодаря использованию идентификаторов в качестве имен файлов, а также некоторым хитростям с файлами блокировки и временными метками, Git преобразует любую скромную файловую систему в эффективную и надежную базу данных. === Интеллект === @@ -36,7 +36,7 @@ Git эвристически находит файлы, которые были === Происхождение Git === -Это http://lkml.org/lkml/2005/4/6/121 [сообщение в почтовой рассылке ядра Linux] описывает последовательность событий, которые привели к появлению Git. Весь этот тред — привлекательный археологический раскоп для историков Git. +Это http://lkml.org/lkml/2005/4/6/121[сообщение в почтовой рассылке ядра Linux] описывает последовательность событий, которые привели к появлению Git. Весь этот тред — привлекательный археологический раскоп для историков Git. === База данных объектов === @@ -104,7 +104,7 @@ SHA1 хеш его содержимого: Проверка хеша с помощью cat-file сложнее, поскольку ее вывод содержит не только «сырой» распакованный файл объекта. -Этот файл — объект «дерево» (tree, прим. пер): список цепочек, состоящих из типа, имени файла и его хеша. В нашем примере: тип файла — 100644, что означает, что «rose» это обычный файл; а хеш — блоб-объект, в котором находится содержимое «rose». Другие возможные типы файлов: исполняемые файлы, символические ссылки или каталоги. В последнем случае, хеш указывает на объект «дерево». +Этот файл — объект «дерево» (tree, прим. пер.): список цепочек, состоящих из типа, имени файла и его хеша. В нашем примере: тип файла — 100644, что означает, что «rose» это обычный файл; а хеш — блоб-объект, в котором находится содержимое «rose». Другие возможные типы файлов: исполняемые файлы, символические ссылки или каталоги. В последнем случае, хеш указывает на объект «дерево». Если вы запускали filter-branch, у вас есть старые объекты которые вам больше не нужны. Хотя по окончании срока хранения они будут выброшены автоматически, мы удалим их сейчас, чтобы было легче следить за нашим игрушечным примером: -- 2.11.4.GIT