Клиентские хуки

Author: Morganov

book/08-customizing-git/sections/policy.asc

@@ -279,19 +279,19 @@ error: failed to push some refs to 'git@gitserver:project.git'
 
 С момента как скрипт `update` существует и исполняем, ваш репозиторий не будет содержать коммиты с сообщением, неудовлетворяющем установленному шаблону, а доступ ваших пользователей будет ограничен.
 
-==== Client-Side Hooks
+==== Клиентские хуки
 
-The downside to this approach is the whining that will inevitably result when your users' commit pushes are rejected.
-Having their carefully crafted work rejected at the last minute can be extremely frustrating and confusing; and furthermore, they will have to edit their history to correct it, which isn't always for the faint of heart.
+Недостатком этого подхода является неизбежное нытьё ваших пользователей, к которому приводит отклонение отправки коммитов.
+Получение отказа в последний момент при отправке тщательно продуманной работы может сильно расстроить и вызвать непонимание; кроме этого, придётся ещё актуализировать историю, что не всегда для слабонервных.
 
-The answer to this dilemma is to provide some client-side hooks that users can run to notify them when they're doing something that the server is likely to reject.
-That way, they can correct any problems before committing and before those issues become more difficult to fix.
-Because hooks aren't transferred with a clone of a project, you must distribute these scripts some other way and then have your users copy them to their `.git/hooks` directory and make them executable.
-You can distribute these hooks within the project or in a separate project, but Git won't set them up automatically.
+Решением в данной ситуации является предоставление клиентских хуков, которые пользователи могут использовать для получения уведомлений, когда они делают то, что сервер скорее всего отклонит.
+Таким образом они могут исправить любые проблемы до создания коммита и до того, как исправление проблемы станет гораздо сложнее.
+Так как хуки не копируются при клонировании репозитория, вам следует распространять их каким-то другим способом, а ваши пользователи должны будут их скопировать в директорию `.git/hooks` и сделать исполняемыми.
+Вы можете хранить эти хуки внутри проекта или в отдельном проекте -- в любом случае Git не установит их автоматически.
 
-To begin, you should check your commit message just before each commit is recorded, so you know the server won't reject your changes due to badly formatted commit messages.
-To do this, you can add the `commit-msg` hook.
-If you have it read the message from the file passed as the first argument and compare that to the pattern, you can force Git to abort the commit if there is no match:
+Для начала, необходимо проверять сообщение коммита непосредственно перед его созданием, так вы будете уверены, что сервер не отклонит ваши изменения из-за плохо оформленных сообщений.
+Это реализуется созданием `commit-msg` хука.
+Если читать файл, переданный в качестве первого аргумента, и сравнивать его содержимое с заданным шаблоном, то можно заставить Git отменять создание коммита в случае отсутствия совпадения:
 
 [source,ruby]
 ----
@@ -307,32 +307,32 @@ if !$regex.match(message)
 end
 ----
 
-If that script is in place (in `.git/hooks/commit-msg`) and executable, and you commit with a message that isn't properly formatted, you see this:
+Если скрипт на месте (`.git/hooks/commit-msg`) и исполняем, а вы создаёте коммит с плохо оформленным сообщением, то увидите следующее:
 
 [source,console]
 ----
-$ git commit -am 'test'
+$ git commit -am 'Test'
 [POLICY] Your message is not formatted correctly
 ----
 
-No commit was completed in that instance.
-However, if your message contains the proper pattern, Git allows you to commit:
+В этом случае коммит создан не будет.
+Однако, если ваше сообщение соответствует заданному шаблону, то коммит будет создан:
 
 [source,console]
 ----
-$ git commit -am 'test [ref: 132]'
-[master e05c914] test [ref: 132]
+$ git commit -am 'Test [ref: 132]'
+[master e05c914] Test [ref: 132]
  1 file changed, 1 insertions(+), 0 deletions(-)
 ----
 
-Next, you want to make sure you aren't modifying files that are outside your ACL scope.
-If your project's `.git` directory contains a copy of the ACL file you used previously, then the following `pre-commit` script will enforce those constraints for you:
+Далее, следует убедиться, что внесенные изменения соответствуют вашим правам доступа.
+Если в директории `.git` содержится файл списка контроля доступа, который использовался ранее, то следующий `pre-commit` скрипт поможет вам реализовать такую проверку:
 
 [source,ruby]
 ----
 #!/usr/bin/env ruby
 
-$user    = ENV['USER']
+$user = ENV['USER']
 
 # [ insert acl_access_data method from above ]
 
@@ -358,50 +358,50 @@ end
 check_directory_perms
 ----
 
-This is roughly the same script as the server-side part, but with two important differences.
-First, the ACL file is in a different place, because this script runs from your working directory, not from your `.git` directory.
-You have to change the path to the ACL file from this
+Этот скрипт практически такой же как и серверный, за исключением двух важных отличий.
+Во первых, файл списка контроля доступа находится в другом месте, так как скрипт запускается из рабочей директории, а не из директории `.git`.
+Поэтому необходимо изменить путь к файлу с:
 
 [source,ruby]
 ----
 access = get_acl_access_data('acl')
 ----
 
-to this:
+на следующий:
 
 [source,ruby]
 ----
 access = get_acl_access_data('.git/acl')
 ----
 
-The other important difference is the way you get a listing of the files that have been changed.
-Because the server-side method looks at the log of commits, and, at this point, the commit hasn't been recorded yet, you must get your file listing from the staging area instead.
-Instead of
+Второе отличие состоит в способе получения списка изменённых файлов.
+Если на сервере метод извлекает его из истории коммитов, то в данный момент на стороне клиента коммит ещё не создан, поэтому извлекать этот список необходимо из индекса.
+Вместо 
 
 [source,ruby]
 ----
 files_modified = `git log -1 --name-only --pretty=format:'' #{ref}`
 ----
 
-you have to use
+следует использовать:
 
 [source,ruby]
 ----
 files_modified = `git diff-index --cached --name-only HEAD`
 ----
 
-But those are the only two differences -- otherwise, the script works the same way.
-One caveat is that it expects you to be running locally as the same user you push as to the remote machine.
-If that is different, you must set the `$user` variable manually.
+Вот и все отличия -- в остальном скрипт работает одинаково.
+Так же предполагается, что локально скрипт будет запускаться от имени того же пользователя, что и на удалённом сервере.
+Если имя вашего локального пользователя не совпадает с именем пользователя на сервере, то следует задать значение переменной `$user` вручную.
 
-One other thing we can do here is make sure the user doesn't push non-fast-forwarded references.
-To get a reference that isn't a fast-forward, you either have to rebase past a commit you've already pushed up or try pushing a different local branch up to the same remote branch.
+Ещё одна вещь, которую можно здесь сделать, это убедиться, что пользователь не отправляет ветки, которые не могут быть обновлены простым смещением вперёд.
+Чтобы создать такую ситуацию, вам нужно либо перебазировать уже отправленный коммит, либо попытаться отправить другую локальную ветку в ту же удалённую.
 
-Presumably, the server is already configured with `receive.denyDeletes` and `receive.denyNonFastForwards` to enforce this policy, so the only accidental thing you can try to catch is rebasing commits that have already been pushed.
+Предположим, что на сервере уже включены опции `receive.denyDeletes` и `receive.denyNonFastForwards` для обеспечения политики, поэтому воспроизвести ситуацию можно только перебазировав отправленные коммиты.
 
-Here is an example pre-rebase script that checks for that.
-It gets a list of all the commits you're about to rewrite and checks whether they exist in any of your remote references.
-If it sees one that is reachable from one of your remote references, it aborts the rebase.
+Ниже представлен скрипт `pre-rebase`, который выполняет такую проверку.
+Он получает список коммитов, которые вы собираетесь перезаписать, и проверяет их наличие в удаленных ветках.
+Если хотя бы один из этих коммитов будет доступен из какой-либо удалённой ветки, то процесс перебазирования прерывается.
 
 [source,ruby]
 ----
@@ -427,15 +427,17 @@ target_shas.each do |sha|
   end
 end
 ----
-This script uses a syntax that wasn't covered in the Revision Selection section of Chapter 6. You get a list of commits that have already been pushed up by running this:
+
+Скрипт использует синтаксис, который не был рассмотрен в разделе <<ch07-git-tools#r_revision_selection>>.
+Получить список коммитов, которые уже были отправлены, можно с помощью команды:
 
 [source,ruby]
 ----
 `git rev-list ^#{sha}^@ refs/remotes/#{remote_ref}`
 ----
 
-The `SHA^@` syntax resolves to all the parents of that commit.
-You're looking for any commit that is reachable from the last commit on the remote and that isn't reachable from any parent of any of the SHA-1s you're trying to push up -- meaning it's a fast-forward.
+Синтаксис `SHA^@` позволяет получить список всех родителей коммита.
+Вы ищите любой коммит, который доступен относительно последнего коммита на удалённом сервере, но недоступен относительно любого родителя отправляемых SHA-1, что определяет простое смещение вперёд.
 
-The main drawback to this approach is that it can be very slow and is often unnecessary -- if you don't try to force the push with `-f`, the server will warn you and not accept the push.
-However, it's an interesting exercise and can in theory help you avoid a rebase that you might later have to go back and fix.
+Основной недостаток этого подхода в том, что он может быть очень медленным и не всегда необходим -- если вы не форсируете отправку опцией `-f`, то сервер отклонит её с соответствующим предупреждением.
+Тем не менее, это интересная задача, которая теоретически может вам помочь избежать перебазирования, которое в будущем, возможно, придётся исправлять.