Как использовать Git Hooks для автоматизации задач разработки и развертывания

Введение

Контроль версий стал центральным требованием для современной разработки программного обеспечения. Это позволяет проектам безопасно отслеживать изменения и включать возвраты, проверку целостности и совместную работу среди других преимуществ.

Используя систему «ловушек», git позволяет разработчикам и администраторам расширять функциональность, указывая сценарии, которые git будет вызывать на основе различных событий и действий.

В этом руководстве вы изучите идею git hooks и продемонстрируете, как реализовать код, который может помочь вам автоматизировать задачи в вашей собственной уникальной среде. В этом руководстве вы будете использовать сервер Ubuntu 20.04, но любая система, на которой можно запустить git, должна работать аналогичным образом.

Предпосылки

• Прежде чем начать, на вашем сервере должен быть установлен git. Если вы следите за Ubuntu 20.04, вы можете ознакомиться с нашим руководством по установке git в Ubuntu 20.04.
• Вы должны быть знакомы с тем, как использовать git в общем смысле. Если вам нужно введение, серия статей, частью которой является установка, называется Introduction to Git: Installation, Usage, and Branches. Это хорошее место для начала.

Примечание. Если вы уже знакомы с концепциями git и git hook и хотите погрузиться в практические примеры, вы можете сразу перейти к разделу «Настройка репозитория».

Когда вы закончите с вышеуказанными требованиями, продолжайте.

Основная идея с Git Hooks

Git-хуки — это довольно простая концепция, которая была реализована для удовлетворения потребности. При разработке программного обеспечения в общем проекте, поддержании стандартов руководств по стилю или развертывании программного обеспечения часто возникают повторяющиеся задачи, которые вы захотите выполнять каждый раз, когда предпринимается действие.

Перехватчики Git основаны на событиях. Когда вы запускаете определенные команды git, программное обеспечение проверяет каталог hooks в репозитории git, чтобы увидеть, есть ли соответствующий скрипт для запуска.

Некоторые сценарии запускаются перед выполнением действия, которое можно использовать для обеспечения соответствия кода стандартам, проверки работоспособности или настройки среды. Другие скрипты запускаются после события для развертывания кода, восстановления правильных разрешений (что-то, что git не очень хорошо отслеживает) и так далее.

Используя эти возможности, можно применять политики, обеспечивать согласованность, контролировать среду и даже выполнять задачи развертывания.

Определение категорий хуков

В книге Скотта Чакона Pro Git делается попытка разделить различные типы хуков на категории. Он классифицирует их следующим образом:

• Клиентские хуки: хуки, которые вызываются и выполняются на компьютере коммиттера. Они, в свою очередь, делятся на несколько отдельных категорий:
  • Перехватчики рабочего процесса фиксации. Перехватчики фиксации используются для указания действий, которые следует предпринять во время фиксации. Они используются для запуска проверок работоспособности, предварительного заполнения сообщений фиксации и проверки сведений о сообщениях. Вы также можете использовать это для предоставления уведомлений при фиксации.
  • Перехватчики рабочего процесса электронной почты. В эту категорию перехватчиков входят действия, предпринимаемые при работе с исправлениями, отправленными по электронной почте. Такие проекты, как ядро Linux, отправляют и проверяют исправления по электронной почте. Они аналогичны обработчикам коммитов, но могут использоваться сопровождающими, ответственными за применение отправленного кода.
  • Другое: к другим клиентским обработчикам относятся обработчики, которые выполняются при слиянии, извлечении кода, перебазировании, перезаписи и очистке репозиториев.
  • Предварительное и последующее получение: они выполняются на сервере, получающем запрос, чтобы выполнить такие действия, как проверка соответствия проекта и развертывание после отправки.
  • Обновление: похоже на предварительное получение, но работает по принципу ветвь за ветвью для выполнения кода до того, как каждая ветвь будет принята.

  Эти классификации полезны для получения общего представления о событиях, для которых вы можете дополнительно настроить ловушку. Но чтобы на самом деле понять, как работают эти элементы, лучше всего поэкспериментировать и выяснить, какие решения вы пытаетесь внедрить.

  Просмотр хуков по параметрам

  Некоторые хуки также принимают параметры. Это означает, что когда git вызывает скрипт для хука, он передает некоторые важные данные, которые затем скрипт может использовать для выполнения задач. В целом, крючки, которые доступны:

  Hook Name	Invoked By	Description	Parameters (Number and Description)
  applypatch-msg	git am	Can edit the commit message file and is often used to verify or actively format a patch’s message to a project’s standards. A non-zero exit status aborts the commit.	(1) name of the file containing the proposed commit message
  pre-applypatch	git am	This is actually called after the patch is applied, but before the changes are committed. Exiting with a non-zero status will leave the changes in an uncommitted state. Can be used to check the state of the tree before actually committing the changes.	(none)
  post-applypatch	git am	This hook is run after the patch is applied and committed. Because of this, it cannot abort the process, and is mainly used for creating notifications.	(none)
  pre-commit	git commit	This hook is called before obtaining the proposed commit message. Exiting with anything other than zero will abort the commit. It is used to check the commit itself (rather than the message).	(none)
  prepare-commit-msg	git commit	Called after receiving the default commit message, just prior to firing up the commit message editor. A non-zero exit aborts the commit. This is used to edit the message in a way that cannot be suppressed.	(1 to 3) Name of the file with the commit message, the source of the commit message (message, template, merge, squash, or commit), and the commit SHA-1 (when operating on an existing commit).
  commit-msg	git commit	Can be used to adjust the message after it has been edited in order to ensure conformity to a standard or to reject based on any criteria. It can abort the commit if it exits with a non-zero value.	(1) The file that holds the proposed message.
  post-commit	git commit	Called after the actual commit is made. Because of this, it cannot disrupt the commit. It is mainly used to allow notifications.	(none)
  pre-rebase	git rebase	Called when rebasing a branch. Mainly used to halt the rebase if it is not desirable.	(1 or 2) The upstream from where it was forked, the branch being rebased (not set when rebasing current)
  post-checkout	git checkout and git clone	Run when a checkout is called after updating the worktree or after git clone. It is mainly used to verify conditions, display differences, and configure the environment if necessary.	(3) Ref of the previous HEAD, ref of the new HEAD, flag indicating whether it was a branch checkout (1) or a file checkout (0)
  post-merge	git merge or git pull	Called after a merge. Because of this, it cannot abort a merge. Can be used to save or apply permissions or other kinds of data that git does not handle.	(1) Flag indicating whether the merge was a squash.
  pre-push	git push	Called prior to a push to a remote. In addition to the parameters, additional information, separated by a space is passed in through stdin in the form of “<local ref> <local sha1> <remote ref> <remote sha1>”. Parsing the input can get you additional information that you can use to check. For instance, if the local sha1 is 40 zeros long, the push is a delete and if the remote sha1 is 40 zeros, it is a new branch. This can be used to do many comparisons of the pushed ref to what is currently there. A non-zero exit status aborts the push.	(2) Name of the destination remote, location of the destination remote
  pre-receive	git-receive-pack on the remote repo	This is called on the remote repo just before updating the pushed refs. A non-zero status will abort the process. Although it receives no parameters, it is passed a string through stdin in the form of “<old-value> <new-value> <ref-name>” for each ref.	(none)
  update	git-receive-pack on the remote repo	This is run on the remote repo once for each ref being pushed instead of once for each push. A non-zero status will abort the process. This can be used to make sure all commits are only fast-forward, for instance.	(3) The name of the ref being updated, the old object name, the new object name
  post-receive	git-receive-pack on the remote repo	This is run on the remote when pushing after all refs have been updated. It does not take parameters, but receives info through stdin in the form of “<old-value> <new-value> <ref-name>”. Because it is called after the updates, it cannot abort the process.	(none)
  post-update	git-receive-pack on the remote repo	This is run only once after all of the refs have been pushed. It is similar to the post-receive hook in that regard, but does not receive the old or new values. It is used mostly to implement notifications for the pushed refs.	(?) A parameter for each of the pushed refs containing its name
  pre-auto-gc	git gc --auto	Is used to do some checks before automatically cleaning repos.	(none)
  post-rewrite	git commit --amend, git-rebase	This is called when git commands are rewriting already committed data. In addition to the parameters, it receives strings in stdin in the form of “<old-sha1> <new-sha1>”.	(1) Name of the command that invoked it (amend or rebase)

  Немного о переменных окружения с помощью Git Hooks

  Прежде чем вы сможете начать свой сценарий, вам нужно немного узнать о том, какие переменные среды git устанавливает при вызове хуков. Чтобы ваш скрипт заработал, вам в конечном итоге потребуется сбросить переменную окружения, которую git устанавливает при вызове хука post-commit.

  Это очень важный момент, который нужно усвоить, если вы надеетесь написать git-хуки, которые работают надежно. Git устанавливает разные переменные окружения в зависимости от того, какой хук вызывается. Это означает, что среда, из которой git извлекает информацию, будет различаться в зависимости от хука.

  Первая проблема заключается в том, что это может сделать вашу среду сценариев очень непредсказуемой, если вы не знаете, какие переменные устанавливаются автоматически. Вторая проблема заключается в том, что установленные переменные почти полностью отсутствуют в собственной документации git.

  К счастью, Марк Лонгэйр разработал метод тестирования каждой из переменных, которые git устанавливает при запуске этих хуков. Это включает в себя размещение следующего содержимого в различных скриптах git hook:

  #!/bin/bash
  echo Running $BASH_SOURCE
  set | egrep GIT
  echo PWD is $PWD
  

  Информация на его сайте относится к 2011 году, работающему с git версии 1.7.1, поэтому было несколько изменений. В этом руководстве используется Ubuntu 20.04 с git 2.25.1.

  Ниже приведены результаты тестов этой версии git (включая рабочий каталог, видимый git при запуске каждого хука). Локальный рабочий каталог для теста был /home/sammy/test_hooks, а голый удаленный (где необходимо) был /home/sammy/origin/test_hooks.git:

  • Хуки: applypatch-msg, pre-applypatch, post-applypatch
    • Переменные среды:
    • GIT_AUTHOR_DATE=Пн, 11 августа 2014 г., 11:25:16 -0400
    • GIT_AUTHOR_EMAIL=Сэмми@example.com
    • GIT_AUTHOR_NAME=Сэмми Пользователь
    • GIT_INTERNAL_GETTEXT_SH_SCHEME=gnu
    • GIT_REFLOG_ACTION=am
    • Рабочий каталог: /home/sammy/test_hooks
    • Переменные среды:
    • GIT_AUTHOR_DATE=@1407774159 -0400
    • GIT_AUTHOR_EMAIL=Сэмми@example.com
    • GIT_AUTHOR_NAME=Сэмми Пользователь
    • GIT_DIR=.git
    • GIT_EDITOR=:
    • GIT_INDEX_FILE=.git/index
    • GIT_PREFIX=
    • Рабочий каталог: /home/sammy/test_hooks
    • Переменные среды:
    • GIT_INTERNAL_GETTEXT_SH_SCHEME=gnu
    • GIT_REFLOG_ACTION=rebase
    • Рабочий каталог: /home/sammy/test_hooks
    • Переменные среды:
    • GIT_DIR=.git
    • GIT_PREFIX=
    • Рабочий каталог: /home/sammy/test_hooks
    • Переменные среды:
    • GITHEAD_4b407c...
    • GIT_DIR=.git
    • GIT_INTERNAL_GETTEXT_SH_SCHEME=gnu
    • GIT_PREFIX=
    • GIT_REFLOG_ACTION=вытащить другой мастер
    • Рабочий каталог: /home/sammy/test_hooks
    • Переменные среды:
    • GIT_PREFIX=
    • Рабочий каталог: /home/sammy/test_hooks
    • Переменные среды:
    • GIT_DIR=.
    • Рабочий каталог: /home/sammy/origin/test_hooks.git
    • (неизвестно, потому что это сложно надежно активировать)
    • Переменные среды:
    • GIT_AUTHOR_DATE=@1407773551 -0400
    • GIT_AUTHOR_EMAIL=Сэмми@example.com
    • GIT_AUTHOR_NAME=Сэмми Пользователь
    • GIT_DIR=.git
    • GIT_PREFIX=
    • Рабочий каталог: /home/sammy/test_hooks

    Эти переменные влияют на то, как git видит свою среду. Вы будете использовать приведенную выше информацию о переменных, чтобы убедиться, что ваш сценарий правильно учитывает свое окружение.

    Теперь, когда у вас есть вся эта общая информация, вы можете продемонстрировать, как реализовать ее в нескольких сценариях.

    Настройка репозитория

    Для начала вы создадите новый пустой репозиторий в своем домашнем каталоге. Вы можете назвать этот proj.

    mkdir ~/proj
    cd ~/proj
    git init
    
    

    Output
    Initialized empty Git repository in /home/sammy/proj/.git/
    

    В остальной части этого руководства замените sammy своим именем пользователя по мере необходимости.

    Теперь вы находитесь в пустом рабочем каталоге каталога, контролируемого git. Прежде чем делать что-либо еще, перейдите в репозиторий, который хранится в скрытом файле с именем .git в этом каталоге:

    cd .git
    ls -F
    
    

    Output
    branches/  config  description  HEAD  hooks/  info/  objects/  refs/
    

    Вы увидите несколько файлов и каталогов. Вас интересует каталог hooks:

    cd hooks
    ls -l
    
    

    Output
    total 40
    -rwxrwxr-x 1 sammy sammy  452 Aug  8 16:50 applypatch-msg.sample
    -rwxrwxr-x 1 sammy sammy  896 Aug  8 16:50 commit-msg.sample
    -rwxrwxr-x 1 sammy sammy  189 Aug  8 16:50 post-update.sample
    -rwxrwxr-x 1 sammy sammy  398 Aug  8 16:50 pre-applypatch.sample
    -rwxrwxr-x 1 sammy sammy 1642 Aug  8 16:50 pre-commit.sample
    -rwxrwxr-x 1 sammy sammy 1239 Aug  8 16:50 prepare-commit-msg.sample
    -rwxrwxr-x 1 sammy sammy 1352 Aug  8 16:50 pre-push.sample
    -rwxrwxr-x 1 sammy sammy 4898 Aug  8 16:50 pre-rebase.sample
    -rwxrwxr-x 1 sammy sammy 3611 Aug  8 16:50 update.sample
    

    Здесь вы можете увидеть несколько вещей. Во-первых, вы можете видеть, что каждый из этих файлов помечен как исполняемый. Поскольку эти сценарии вызываются только по имени, они должны быть исполняемыми, а их первая строка должна быть ссылкой на магическое число Шебанга для вызова правильного интерпретатора сценария. Чаще всего это языки сценариев, такие как bash, perl, python и т. д.

    Во-вторых, вы можете заметить, что все файлы заканчиваются на .sample. Это потому, что git просто смотрит на имя файла, пытаясь найти файлы ловушек для выполнения. Отклонение от имени скрипта, который ищет git, в основном отключает скрипт. Чтобы включить любой из сценариев в этом каталоге, вам нужно будет удалить суффикс .sample.

    Первый пример: развертывание на локальном веб-сервере с использованием хука Post-Commit

    В вашем первом примере будет использоваться хук post-commit, чтобы показать вам, как выполнять развертывание на локальном веб-сервере всякий раз, когда выполняется коммит. Это не тот хук, который вы бы использовали для производственной среды, но он позволяет нам продемонстрировать некоторые важные, едва документированные элементы, о которых вам следует знать при использовании хуков.

    Сначала вы установите веб-сервер Apache, чтобы продемонстрировать:

    sudo apt-get update
    sudo apt-get install apache2
    
    

    Чтобы ваш скрипт мог изменить корневую папку веб-сайта /var/www/html (это корень документа в Ubuntu 20.04. При необходимости измените), вам необходимо иметь разрешение на запись. Во-первых, предоставьте своему обычному пользователю право собственности на этот каталог. Вы можете сделать это, набрав:

    sudo chown -R `whoami`:`id -gn` /var/www/html
    
    

    Теперь в каталоге вашего проекта создайте файл index.html:

    cd ~/proj
    nano index.html
    
    

    Внутри вы можете добавить немного HTML, чтобы продемонстрировать идею. Это не должно быть сложно:

    <h1>Here is a title!</h1>
    
    <p>Please deploy me!</p>
    

    Добавьте новый файл, чтобы указать git отслеживать файл:

    git add .
    
    

    Теперь, перед фиксацией, вы собираетесь настроить хук post-commit для репозитория. Создайте этот файл в каталоге .git/hooks для проекта:

    nano .git/hooks/post-commit
    
    

    Поскольку git hooks — это стандартные скрипты, вам нужно указать git использовать bash, начав с shebang:

    #!/bin/bash
    unset GIT_INDEX_FILE
    git --work-tree=/var/www/html --git-dir=$HOME/proj/.git checkout -f
    

    В следующей строке вам нужно внимательно посмотреть на переменные среды, которые устанавливаются каждый раз, когда вызывается хук post-commit. В частности, для GIT_INDEX_FILE задано значение .git/index.

    Этот путь относится к рабочему каталогу, в данном случае это /var/www/html. Поскольку индекса git в этом месте не существует, сценарий не будет работать, если вы оставите его как есть. Чтобы избежать этой ситуации, вы можете вручную сбросить переменную.

    После этого вы просто будете использовать сам git для распаковки самой новой версии репозитория после коммита в свой веб-каталог. Вы захотите принудительно выполнить эту транзакцию, чтобы убедиться, что она проходит успешно каждый раз.

    Когда вы закончите с этими изменениями, сохраните и закройте файл.

    Поскольку это обычный файл скрипта, вам нужно сделать его исполняемым:

    chmod +x .git/hooks/post-commit
    
    

    Теперь вы, наконец, готовы зафиксировать изменения, внесенные в репозиторий git. Убедитесь, что вы вернулись в правильный каталог, а затем зафиксируйте изменения:

    cd ~/proj
    git commit -m "here we go..."
    
    

    Теперь, если вы посетите доменное имя или IP-адрес вашего сервера в своем браузере, вы должны увидеть созданный вами файл index.html:

    http://server_domain_or_IP
    

    

    Как видите, ваши самые последние изменения были автоматически помещены в корневой каталог документов вашего веб-сервера после фиксации. Вы можете внести некоторые дополнительные изменения, чтобы показать, что это работает для каждого коммита:

    echo "<p>Here is a change.</p>" >> index.html
    git add .
    git commit -m "First change"
    
    

    Когда вы обновите свой браузер, вы должны сразу увидеть новые изменения, которые вы применили:

    

    Как видите, этот тип настройки может упростить локальное тестирование изменений. Тем не менее, вы почти никогда не захотите публиковать при фиксации в производственной среде. Гораздо безопаснее пушить после того, как вы протестировали свой код и уверены, что он готов.

    Использование Git Hooks для развертывания на отдельном производственном сервере

    В следующем примере вы продемонстрируете лучший способ обновления рабочего сервера. Вы можете сделать это, используя модель push-to-deploy, чтобы обновлять свой веб-сервер всякий раз, когда вы нажимаете на голый репозиторий git. Вы можете использовать тот же сервер, который вы настроили, в качестве машины для разработки.

    На вашей рабочей машине вы будете настраивать еще один веб-сервер, голый репозиторий git, в который вы будете отправлять изменения, и git-хук, который будет выполняться всякий раз, когда будет получена отправка.

    Выполните приведенные ниже шаги как обычный пользователь с привилегиями sudo.

    Настройка хука пост-получения производственного сервера

    На рабочем сервере начните с установки веб-сервера:

    sudo apt-get update
    sudo apt-get install apache2
    
    

    Опять же, вы должны передать право собственности на корень документа пользователю, под которым вы работаете:

    sudo chown -R `whoami`:`id -gn` /var/www/html
    
    

    Вам также необходимо установить git на эту машину:

    sudo apt-get install git
    
    

    Теперь вы можете создать каталог в домашнем каталоге вашего пользователя для хранения репозитория. Затем вы можете перейти в этот каталог и инициализировать пустой репозиторий. Голый репозиторий не имеет рабочего каталога и лучше подходит для серверов, с которыми вы не будете работать напрямую:

    mkdir ~/proj
    cd ~/proj
    git init --bare
    
    

    Поскольку это голый репозиторий, в нем нет рабочего каталога, и все файлы, которые обычно находятся в .git, теперь находятся в самом основном каталоге.

    Далее вам нужно создать еще один git-хук. На этот раз вас интересует хук post-receive, который запускается на сервере, получающем git push. Откройте этот файл в вашем редакторе:

    nano hooks/post-receive
    
    

    Опять же, вам нужно начать с определения типа сценария, который вы пишете. После этого вы можете ввести ту же команду проверки, которую вы использовали в файле post-commit, измененную для использования путей на этом компьютере:

    #!/bin/bash
    while read oldrev newrev ref
    do
    if [[ $ref =~ .*/master$ ]];
    then
    echo "Master ref received.  Deploying master branch to production..."
    git --work-tree=/var/www/html --git-dir=$HOME/proj checkout -f
    else
    echo "Ref $ref successfully received.  Doing nothing: only the master branch may be deployed on this server."
    fi
    done
    

    Поскольку это голый репозиторий, --git-dir должен указывать на каталог верхнего уровня этого репозитория.

    Однако вам нужно добавить в этот скрипт дополнительную логику. Если вы случайно отправите ветку test-feature на этот сервер, вы не захотите, чтобы она была развернута. Вы хотите убедиться, что собираетесь развертывать только ветку master.

    Во-первых, вам нужно прочитать стандартный ввод. Для каждой загружаемой ссылки три части информации (старая версия, новая версия, ссылка) будут переданы в скрипт, разделенные пробелом, в качестве стандартного ввода. Вы можете прочитать это с помощью цикла while, окружающего команду git.

    Итак, теперь у вас будет три набора переменных в зависимости от того, что нажимается. Для отправки основной ветки объект ref будет содержать нечто похожее на refs/heads/master. Вы можете проверить, имеет ли ссылка, которую получает сервер, этот формат, используя конструкцию if.

    Наконец, добавьте текст, описывающий, какая ситуация была обнаружена и какое действие было предпринято. Вы должны добавить блок else, чтобы уведомить пользователя об успешном получении неглавной ветки, даже если это действие не приведет к развертыванию.

    Когда вы закончите, сохраните и закройте файл. Но помните, вы должны сделать скрипт исполняемым, чтобы хук работал:

    chmod +x hooks/post-receive
    
    

    Теперь вы можете настроить доступ к этому удаленному серверу на своем клиенте.

    Настройте удаленный сервер на клиентской машине.

    Вернитесь на свой клиентский (разрабатываемый) компьютер, вернитесь в рабочий каталог вашего проекта:

    cd ~/proj
    
    

    Внутри добавьте удаленный сервер как удаленный с именем production. Вводимая команда должна выглядеть примерно так:

    git remote add production sammy@remote_server_domain_or_IP:proj
    
    

    Теперь отправьте текущую ветку master на рабочий сервер:

    git push production master
    
    

    Если у вас не настроены SSH-ключи, возможно, вам придется ввести пароль пользователя вашего рабочего сервера. Вы должны увидеть что-то похожее на это:

    Output]
    Counting objects: 8, done.
    Delta compression using up to 2 threads.
    Compressing objects: 100% (3/3), done.
    Writing objects: 100% (4/4), 473 bytes | 0 bytes/s, done.
    Total 4 (delta 0), reused 0 (delta 0)
    remote: Master ref received.  Deploying master branch...
    To sammy@107.170.14.32:proj
       009183f..f1b9027  master -> master
    

    Как видите, текст из вашего хука post-receive находится в выводе команды. Если вы посещаете доменное имя или IP-адрес вашего рабочего сервера в своем веб-браузере, вы должны увидеть текущую версию вашего проекта:

    

    Похоже, что хук успешно отправил ваш код в производство, как только получил информацию.

    Теперь пришло время протестировать новый код. Вернувшись на машину разработки, вы создадите новую ветку для хранения ваших изменений. Создайте новую ветку с именем test_feature и проверьте новую ветку, набрав:

    git checkout -b test_feature
    
    

    Теперь вы работаете с веткой test_feature. Попробуйте внести изменения, которые вы возможно хотели бы перенести в рабочую среду. Вы зафиксируете его в этой ветке:

    echo "<h2>New Feature Here</h2>" >> index.html
    git add .
    git commit -m "Trying out new feature"
    
    

    На этом этапе, если вы перейдете к IP-адресу или доменному имени вашего компьютера для разработки, вы должны увидеть свои изменения:

    

    Это связано с тем, что ваша машина разработки все еще повторно развертывается при каждом коммите. Этот рабочий процесс отлично подходит для тестирования изменений перед их внедрением в производство.

    Вы можете отправить ветку test_feature на удаленный рабочий сервер:

    git push production test_feature
    
    

    Вы должны увидеть другое сообщение от вашего хука post-receive в выводе:

    Output
    Counting objects: 5, done.
    Delta compression using up to 2 threads.
    Compressing objects: 100% (2/2), done.
    Writing objects: 100% (3/3), 301 bytes | 0 bytes/s, done.
    Total 3 (delta 1), reused 0 (delta 0)
    remote: Ref refs/heads/test_feature successfully received.  Doing nothing: only the master branch may be deployed on this server
    To sammy@107.170.14.32:proj
       83e9dc4..5617b50  test_feature -> test_feature
    

    Если вы снова проверите рабочий сервер в своем браузере, вы увидите, что ничего не изменилось. Это то, что вы ожидаете, поскольку изменение, которое вы отправили, не было в главной ветке.

    Теперь, когда вы протестировали свои изменения на своем компьютере для разработки, вы уверены, что хотите включить эту функцию в свою основную ветку. Вы можете проверить свою ветку master и объединить ветку test_feature на своем компьютере для разработки:

    git checkout master
    git merge test_feature
    
    

    Теперь вы объединили новую функцию с основной веткой. При отправке на рабочий сервер ваши изменения будут развернуты:

    git push production master
    
    

    Если вы проверите доменное имя или IP-адрес вашего рабочего сервера, вы увидите свои изменения:

    

    Используя этот рабочий процесс, вы можете иметь машину для разработки, которая сразу же покажет все зафиксированные изменения. Рабочая машина будет обновляться всякий раз, когда вы нажимаете основную ветку.

    Заключение

    Если вы дочитали до этого места, вы должны увидеть различные способы, которыми git hooks может помочь автоматизировать некоторые из ваших задач. Они могут помочь вам развернуть код или поддерживать стандарты качества, отклоняя несоответствующие изменения или сообщения фиксации.

    В то время как полезность git hooks трудно оспорить, фактическая реализация может быть довольно сложной для понимания и разочаровывающей в устранении неполадок. Практика реализации различных конфигураций, эксперименты с парсингом аргументов и стандартным вводом, а также отслеживание того, как git строит среду хуков, помогут вам научиться писать эффективные хуки. В долгосрочной перспективе затраты времени обычно того стоят, поскольку они могут легко сэкономить вам и вашей команде массу ручной работы в течение всего срока службы вашего проекта.

    Чтобы начать использовать git для участия в проектах, ознакомьтесь с How To Use Git: A Reference Guide.