웹사이트 검색

Git Hooks를 사용하여 개발 및 배포 작업을 자동화하는 방법

소개

버전 제어는 최신 소프트웨어 개발의 핵심 요구 사항이 되었습니다. 이를 통해 프로젝트는 변경 사항을 안전하게 추적하고 되돌리기, 무결성 검사 및 협업을 가능하게 합니다.

깃은 "후크\ 시스템을 사용하여 개발자와 관리자가 다양한 이벤트 및 작업을 기반으로 깃이 호출할 스크립트를 지정하여 기능을 확장할 수 있도록 합니다.

이 가이드에서는 git hooks의 아이디어를 살펴보고 고유한 환경에서 작업을 자동화하는 데 도움이 되는 코드를 구현하는 방법을 보여줍니다. 이 가이드에서는 Ubuntu 20.04 서버를 사용하지만 git을 실행할 수 있는 모든 시스템은 비슷한 방식으로 작동해야 합니다.

전제 조건

  • 시작하기 전에 서버에 git이 설치되어 있어야 합니다. Ubuntu 20.04를 따라하는 경우 Ubuntu 20.04에 git을 설치하는 방법에 대한 가이드를 확인할 수 있습니다.\n
  • 일반적인 의미에서 git을 사용하는 방법에 익숙해야 합니다. 소개가 필요한 경우 Git 소개: 설치, 사용 및 분기라는 설치가 포함된 시리즈에서 시작하는 것이 좋습니다.\n

참고: 이미 git 및 git hook 개념에 익숙하고 실용적인 예를 살펴보고 싶다면 "저장소 설정\으로 건너뛸 수 있습니다.

위의 요구 사항을 완료했으면 계속 진행합니다.

Git Hooks를 사용한 기본 아이디어

Git 후크는 요구 사항을 해결하기 위해 구현된 다소 단순한 개념입니다. 공유 프로젝트에서 소프트웨어를 개발하거나 스타일 가이드 표준을 유지 관리하거나 소프트웨어를 배포할 때 작업을 수행할 때마다 반복적인 작업을 수행해야 하는 경우가 많습니다.

Git 후크는 이벤트 기반입니다. 특정 git 명령을 실행할 때 소프트웨어는 git 저장소 내의 hooks 디렉토리를 확인하여 실행할 관련 스크립트가 있는지 확인합니다.

일부 스크립트는 행동이 일어나기 전에 실행되며, 표준에 대한 코드 준수를 보장하거나 온전성 검사를 위해 또는 환경을 설정하는 데 사용할 수 있습니다. 다른 스크립트는 코드를 배포하고 올바른 권한을 다시 설정하기 위해 이벤트 후에 실행됩니다(git가 잘 추적할 수 없는 작업).

이러한 기능을 사용하여 정책을 시행하고, 일관성을 유지하고, 환경을 제어하고, 배포 작업을 처리할 수도 있습니다.

후크의 범주 정의

Scott Chacon의 책 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이 설정하는 환경 변수에 대해 조금 배워야 합니다. 스크립트가 작동하도록 하려면 결국 post-commit 후크를 호출할 때 git이 설정하는 환경 변수를 설정 해제해야 합니다.

    신뢰할 수 있는 방식으로 작동하는 git hook을 작성하려는 경우 이는 내부화해야 할 매우 중요한 사항입니다. Git은 호출되는 후크에 따라 다른 환경 변수를 설정합니다. 즉, git이 정보를 가져오는 환경은 후크에 따라 달라집니다.

    이것의 첫 번째 문제는 어떤 변수가 자동으로 설정되는지 알지 못하는 경우 스크립팅 환경을 매우 예측할 수 없게 만들 수 있다는 것입니다. 두 번째 문제는 설정된 변수가 git 자체 문서에는 거의 없다는 것입니다.

    다행스럽게도 Mark Longair는 이러한 후크를 실행할 때 git이 설정하는 각 변수를 테스트하는 방법을 개발했습니다. 다양한 git hook 스크립트에 다음 내용을 넣는 작업이 포함됩니다.

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

    그의 사이트에 있는 정보는 2011년 git 버전 1.7.1에서 작업한 것이므로 몇 가지 변경 사항이 있습니다. 이 가이드는 git 2.25.1과 함께 Ubuntu 20.04를 사용하고 있습니다.

    이 버전의 git에 대한 테스트 결과는 다음과 같습니다(각 후크를 실행할 때 git에서 볼 수 있는 작업 디렉토리 포함). 테스트를 위한 로컬 작업 디렉토리는 /home/sammy/test_hooks이고 베어 원격(필요한 경우)은 /home/sammy/origin/test_hooks.git:

    • 훅: applypatch-msg, pre-applypatch, post-applypatch\n
      • 환경 변수:
      • GIT_AUTHOR_DATE=2014년 8월 11일 월요일 11:25:16 -0400
      • GIT_AUTHOR_EMAIL=sammy@example.com
      • GIT_AUTHOR_NAME=Sammy 사용자
      • GIT_INTERNAL_GETTEXT_SH_SCHEME=gnu
      • GIT_REFLOG_ACTION=오전
      • 작업 디렉토리: /home/sammy/test_hooks

      • 환경 변수:
      • GIT_AUTHOR_DATE=@1407774159 -0400
      • GIT_AUTHOR_EMAIL=sammy@example.com
      • GIT_AUTHOR_NAME=Sammy 사용자
      • 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=sammy@example.com
      • GIT_AUTHOR_NAME=Sammy 사용자
      • GIT_DIR=.git
      • GIT_PREFIX=
      • 작업 디렉토리: /home/sammy/test_hooks

      이러한 변수는 git이 환경을 보는 방식에 영향을 미칩니다. 변수에 대한 위의 정보를 사용하여 스크립트가 해당 환경을 올바르게 고려하도록 합니다.

      이제 이 일반 정보를 모두 얻었으므로 몇 가지 시나리오에서 이를 구현하는 방법을 시연할 수 있습니다.

      리포지토리 설정

      시작하려면 홈 디렉터리에 비어 있는 새 리포지토리를 만듭니다. 이 proj를 호출할 수 있습니다.

      1. mkdir ~/proj

      2. cd ~/proj

      3. git init

      

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

      이 안내서의 나머지 부분에서는 필요에 따라 sammy를 사용자 이름으로 바꾸십시오.

      이제 git 제어 디렉토리의 빈 작업 디렉토리에 있습니다. 다른 작업을 수행하기 전에 이 디렉터리 내의 .git라는 숨겨진 파일에 저장된 저장소로 이동하십시오.

      1. cd .git

      2. ls -F

      

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

      여러 파일과 디렉토리가 표시됩니다. 관심 있는 것은 hooks 디렉토리입니다.

      1. cd hooks

      2. 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

      여기서 몇 가지를 볼 수 있습니다. 먼저 이러한 각 파일이 실행 가능한 것으로 표시되어 있음을 알 수 있습니다. 이러한 스크립트는 이름으로만 호출되기 때문에 실행 가능해야 하며 첫 번째 줄은 올바른 스크립트 해석기를 호출하기 위한 shebang 매직 넘버 참조여야 합니다. 가장 일반적으로 이들은 bash, perl, python 등과 같은 스크립팅 언어입니다.

      두 번째로 알 수 있는 것은 모든 파일이 .sample로 끝난다는 것입니다. git은 실행할 후크 파일을 찾으려고 할 때 단순히 파일 이름을 보기 때문입니다. git이 찾는 스크립트 이름에서 벗어나면 기본적으로 스크립트가 비활성화됩니다. 이 디렉토리에서 스크립트를 활성화하려면 .sample 접미사를 제거해야 합니다.

      첫 번째 예: 커밋 후 후크를 사용하여 로컬 웹 서버에 배포

      첫 번째 예제는 커밋이 이루어질 때마다 로컬 웹 서버에 배포하는 방법을 보여주기 위해 post-commit 후크를 사용합니다. 이것은 프로덕션 환경에서 사용하는 후크는 아니지만 후크를 사용할 때 알아야 하는 중요하고 거의 문서화되지 않은 항목을 보여줍니다.

      먼저 다음을 시연하기 위해 Apache 웹 서버를 설치합니다.

      1. sudo apt-get update

      2. sudo apt-get install apache2

      스크립트가 /var/www/html에서 웹 루트(Ubuntu 20.04의 문서 루트입니다. 필요에 따라 수정)를 수정하려면 쓰기 권한이 있어야 합니다. 먼저 이 디렉토리의 일반 사용자 소유권을 부여하십시오. 다음을 입력하면 됩니다.

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

      이제 프로젝트 디렉터리에서 index.html 파일을 만듭니다.

      1. cd ~/proj

      2. nano index.html

      내부에는 아이디어를 보여주기 위해 약간의 HTML을 추가할 수 있습니다. 복잡할 필요는 없습니다.

      <h1>Here is a title!</h1>

<p>Please deploy me!</p>

      새 파일을 추가하여 git에게 파일을 추적하도록 지시합니다.

      1. git add .

      이제 커밋 전에 저장소에 대한 커밋 후 후크를 설정할 것입니다. 프로젝트의 .git/hooks 디렉터리 내에 이 파일을 만듭니다.

      1. nano .git/hooks/post-commit

      git hook은 표준 스크립트이므로 shebang으로 시작하여 bash를 사용하도록 git에 지시해야 합니다.

      #!/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 자체를 사용하여 커밋 후 최신 버전의 리포지토리를 웹 디렉토리에 압축 해제합니다. 이 거래가 매번 성공하도록 강제하고 싶을 것입니다.

      이러한 변경을 마치면 파일을 저장하고 닫습니다.

      이것은 일반 스크립트 파일이므로 실행 가능하게 만들어야 합니다.

      1. chmod +x .git/hooks/post-commit

      이제 마침내 git repo에서 변경한 사항을 커밋할 준비가 되었습니다. 올바른 디렉터리로 돌아왔는지 확인한 다음 변경 사항을 커밋합니다.

      1. cd ~/proj

      2. git commit -m "here we go..."

      이제 브라우저에서 서버의 도메인 이름 또는 IP 주소를 방문하면 생성한 index.html 파일이 표시됩니다.

      http://server_domain_or_IP

      보시다시피 가장 최근 변경 사항은 커밋 시 자동으로 웹 서버의 문서 루트로 푸시되었습니다. 각 커밋에서 작동한다는 것을 보여주기 위해 몇 가지 추가 변경을 할 수 있습니다.

      1. echo "<p>Here is a change.</p>" >> index.html

      2. git add .

      3. git commit -m "First change"

      브라우저를 새로 고치면 적용한 새 변경 사항이 즉시 표시됩니다.

      보시다시피 이러한 유형의 설정을 통해 로컬에서 변경 사항을 더 쉽게 테스트할 수 있습니다. 그러나 프로덕션 환경에서는 커밋 시 게시하고 싶지 않을 것입니다. 코드를 테스트하고 준비가 되었는지 확인한 후에 푸시하는 것이 훨씬 더 안전합니다.

      Git Hooks를 사용하여 별도의 프로덕션 서버에 배포

      다음 예에서는 프로덕션 서버를 업데이트하는 더 나은 방법을 시연합니다. 베어 git 리포지토리로 푸시할 때마다 웹 서버를 업데이트하기 위해 푸시 배포 모델을 사용하여 이 작업을 수행할 수 있습니다. 설정한 동일한 서버를 개발 시스템으로 사용할 수 있습니다.

      프로덕션 시스템에서 다른 웹 서버, 변경 사항을 푸시할 베어 git 리포지토리 및 푸시가 수신될 때마다 실행할 git hook을 설정하게 됩니다.

      sudo 권한이 있는 일반 사용자로 아래 단계를 완료하십시오.

      프로덕션 서버 수신 후 후크 설정

      프로덕션 서버에서 웹 서버를 설치하여 시작합니다.

      1. sudo apt-get update

      2. sudo apt-get install apache2

      다시 말하지만, 다음과 같이 운영 중인 사용자에게 문서 루트의 소유권을 부여해야 합니다.

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

      이 컴퓨터에도 git을 설치해야 합니다.

      1. sudo apt-get install git

      이제 사용자의 홈 디렉토리 내에 저장소를 보관할 디렉토리를 만들 수 있습니다. 그런 다음 해당 디렉토리로 이동하여 기본 저장소를 초기화할 수 있습니다. 베어 리포지토리에는 작업 디렉터리가 없으며 직접 작업하지 않는 서버에 더 적합합니다.

      1. mkdir ~/proj

      2. cd ~/proj

      3. git init --bare

      베어 리포지토리이기 때문에 작업 디렉터리가 없으며 일반적으로 .git에 있는 모든 파일이 이제 기본 디렉터리 자체에 있습니다.

      다음으로 다른 git hook을 만들어야 합니다. 이번에는 git push를 수신하는 서버에서 실행되는 post-receive 후크에 관심이 있습니다. 편집기에서 이 파일을 엽니다.

      1. 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 브랜치만 배포하는지 확인하려고 합니다.

      먼저 표준 입력을 읽어야 합니다. 푸시되는 각 ref에 대해 세 가지 정보(old rev, new rev, ref)가 표준 입력으로 공백으로 구분된 스크립트에 제공됩니다. git 명령을 둘러싸는 while 루프로 이것을 읽을 수 있습니다.

      이제 푸시되는 항목에 따라 세 가지 변수가 설정됩니다. 마스터 분기 푸시의 경우 ref 개체에는 refs/heads/master와 같은 항목이 포함됩니다. if 구성을 사용하여 서버가 수신하는 ref가 이 형식인지 확인할 수 있습니다.

      마지막으로 어떤 상황이 감지되었고 어떤 조치가 취해졌는지 설명하는 텍스트를 추가합니다. 작업이 배포를 트리거하지 않더라도 마스터가 아닌 분기가 성공적으로 수신된 경우 사용자에게 알리려면 else 블록을 추가해야 합니다.

      완료되면 파일을 저장하고 닫습니다. 그러나 후크가 작동하려면 스크립트를 실행 가능하게 만들어야 합니다.

      1. chmod +x hooks/post-receive

      이제 클라이언트에서 이 원격 서버에 대한 액세스를 설정할 수 있습니다.

      클라이언트 시스템에서 원격 서버 구성

      클라이언트(개발) 컴퓨터로 돌아가서 프로젝트의 작업 디렉터리로 돌아갑니다.

      1. cd ~/proj

      내부에서 원격 서버를 production이라는 원격 서버로 추가합니다. 입력하는 명령은 다음과 같아야 합니다.

      1. git remote add production sammy@remote_server_domain_or_IP:proj

      이제 현재 마스터 브랜치를 프로덕션 서버로 푸시합니다.

      1. 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라는 새 분기를 만들고 다음을 입력하여 새 분기를 확인합니다.

      1. git checkout -b test_feature

      이제 test_feature 브랜치에서 작업하고 있습니다. 프로덕션으로 이동하고 싶을 있을 수 있는 변경을 시도하십시오. 이 브랜치에 커밋합니다.

      1. echo "<h2>New Feature Here</h2>" >> index.html

      2. git add .

      3. git commit -m "Trying out new feature"

      이 시점에서 개발 머신의 IP 주소 또는 도메인 이름으로 이동하면 변경 사항이 표시되어야 합니다.

      개발 머신이 각 커밋에서 여전히 재배포되고 있기 때문입니다. 이 작업 흐름은 변경 사항을 프로덕션으로 옮기기 전에 테스트하는 데 유용합니다.

      test_feature 분기를 원격 프로덕션 서버로 푸시할 수 있습니다.

      1. 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 브랜치에서 병합할 수 있습니다.

      1. git checkout master

      2. git merge test_feature

      이제 새 기능을 마스터 분기에 병합했습니다. 프로덕션 서버로 푸시하면 변경 사항이 배포됩니다.

      1. git push production master

      프로덕션 서버의 도메인 이름 또는 IP 주소를 확인하면 변경 사항이 표시됩니다.

      이 워크플로를 사용하면 커밋된 변경 사항을 즉시 표시하는 개발 시스템을 가질 수 있습니다. 마스터 브랜치를 푸시할 때마다 생산 머신이 업데이트됩니다.

      결론

      여기까지 따라했다면 git hook이 일부 작업을 자동화하는 데 도움이 되는 다양한 방법을 볼 수 있을 것입니다. 코드를 배포하는 데 도움이 되거나 비준수 변경 또는 커밋 메시지를 거부하여 품질 표준을 유지하는 데 도움이 될 수 있습니다.

      git hooks의 유용성은 논쟁하기 어렵지만 실제 구현은 이해하기 어렵고 문제를 해결하기가 어려울 수 있습니다. 다양한 구성 구현 연습, 구문 분석 인수 및 표준 입력 실험, git이 후크의 환경을 구성하는 방법 추적은 효과적인 후크 작성 방법을 가르치는 데 큰 도움이 될 것입니다. 장기적으로 볼 때 시간 투자는 일반적으로 그만한 가치가 있습니다. 프로젝트 수명 동안 당신과 당신 팀의 수작업 부하를 쉽게 절약할 수 있기 때문입니다.

      Git을 사용하여 프로젝트에 기여하려면 How To Use Git: A Reference Guide를 확인하십시오.