Gitフックを使用してチームの開発ワークフローを容易にする方法

公開: 2022-03-10
簡単な要約↬開発ワークフローは簡単に手に負えなくなり、チーム内で混乱や摩擦を引き起こし始める可能性があります。特に、チームのサイズが大きくなるとそうなります。 コードレビューで、コンマの欠落や、リモートリポジトリにプッシュする前に実行されなかったテストの失敗に気付くことが何度もありました。 ありがたいことに、この摩擦を取り除き、開発者のワークフローをより単純にし、実際に最も重要なことに集中するのに役立つツールがあります。 gitとそれが提供するフックのおかげで、開発ワークフローを設定し、私たちの生活を楽にすることができる多種多様な自動化があります。

チームまたはオープンソースプロジェクトで機能する主要な要件の1つは、バージョン管理システム(VCS)を使用することです。 Gitは、ソフトウェア開発中のソースコードの変更を追跡するための無料のオープンソース分散バージョン管理システムです。 Linuxカーネルの開発のために2005年にLinusTorvaldsによって作成されました。 習得が容易で、フットプリントが小さく、パフォーマンスが非常に高速です。

すでにGitを使用している可能性が高く(開発コミュニティで利用できる最も人気があり、よく採用されているVCSツールの1つであるため)、プッシュとプルによるコードのステージングとコミットについての知識をすでに持っている可能性があります。リモートリポジトリから。 この記事では、gitワークフローの基本については説明しませんが、主にgitフックと、チームでより良いコラボレーションを実現するためにそれらを利用する方法に焦点を当てます。 チームの規模が大きくなるにつれ、貢献者を一列に並べ、コードに関するさまざまなルールを維持することがさらに重要になっています。

Gitフックとは何ですか?

Gitフックは、特定のアクションまたはイベントがgitリポジトリで実行されたときにトリガーされるスクリプトです。 これらのアクションは、コミットやプッシュなどのバージョン管理ワークフローの一部に関するものです。 フックは、gitワークフローのタスクを自動化することで非常に役立ちます。 たとえば、特定のルールに基づいてコードベースの構文を検証したり、変更をコミットする前にいくつかのテストを実行したりするのに役立ちます。

ジャンプした後もっと! 以下を読み続けてください↓

それらを設定する方法は?

Gitフックは組み込みの機能です。つまり、gitリポジトリが初期化されている限り、Gitフックにアクセスして使用を開始できます。 それらを設定することによって、それが何を意味するのかをより詳細に見てみましょう。

お気に入りのターミナルを使用して、新しいgitリポジトリを作成します。

 mkdir my-new-repository && cd my-new-repository git init ls -la

新しい隠しディレクトリが作成されたことがわかります。 このフォルダー.gitは、バージョン管理ハッシュ、コミットに関する情報、リモートリポジトリアドレスなどのリポジトリ関連情報を格納するためにgitから使用されます。 これは、フックが実際にgit .git/hooks用に存在するフォルダーでもあります。 初期化中に自動的に作成された、事前に入力されたサンプルスクリプトがいくつかあります。 これらは実際には、特定のアクションの後にトリガーされるスクリプトです。

 ls .git/hooks

あなたが見つけることができるサンプルのいくつかは次のとおりです。

  • pre-commit.sample :コミットを行う直前に呼び出されます。
  • commit-msg.sample :メッセージファイルを所定の場所で編集します。
  • post-receive.sample :リモートリポジトリが更新された後に呼び出されます。

フードの下

フックがどこにあるかがわかったので、実際にどのように機能するかを理解するために、一歩下がってみましょう。

Gitフックはイベントベースであるため、開発フローでgitコマンドを実行する限り、gitはフックフォルダーをチェックして、実行する関連スクリプトがあるかどうかを確認します。 これらのスクリプトの一部は、これらの開発フローアクションの前または後に実行されます。

フックがトリガーされるフローを確認し、より具体的に理解するための良い例は、非常によく知られているユースケースであるコミットワークフローです。

コードベースに変更を加えるたびに、これらの関連するフックの一部が次の順序でトリガーされます。

  1. pre-commit :コミットしようとしているスナップショットを検査し、何をコミットするかを確認します。
  2. prepare-commit-msg :コミット作成者が表示する前にデフォルトのメッセージを編集できます。
  3. commit-msg :コミットメッセージをテンプレートに設定します。
  4. post-commit :コミットが完了した直後にアクションを実行し、たとえば通知を送信します。
コミット作成プロセス中に実行されるフック
コミット作成プロセス中に実行されるフック(画像クレジット:Atlassian Bitbucket)(大プレビュー)

上記のリポジトリで、gitフックが実際にどのように機能するかをさらに視覚化するために、いくつかのカスタムのコミット前およびコミット後のスクリプトを追加してみましょう。

 nano .git/hooks/pre-commit

次のスニペットを追加します。

 #!/bin/sh echo Changes are about to be committed

スクリプトが実行可能であることを確認してください。

 chmod +x .git/hooks/pre-commit

post-commitスクリプトに対して上記のプロセスを繰り返します。

 nano .git/hooks/post-commit
 #!/bin/sh echo Changes have been committed
 chmod +x .git/hooks/post-commit

これで、デモンストレーションの目的で、小さなHTMLスニペットを含む新しいファイルnano index.htmlを追加できます(HTMLバリデーターにこれを知らせる必要はありません)。

 <h1>Hello world from our new repository!</h1>

ステージングしてからこれをコミットすることで、コードベースに変更を追加します。

 git add . git commit

コミットが正常に処理されると、上記で追加した2つのスクリプトの次の出力が表示されます。

 Changes are about to be committed Changes have been committed

予想どおり、gitはコミットフローでフックをトリガーしました。 追加されたpre-commitおよびpost-commitスクリプトは実行されており、正しい順序で実行されます(前述の順序に基づいています)。

これは、コミットワークフロースクリプトがどのように機能し、どのように実行されるかを理解するための簡単なデモンストレーションでした。 このワークフローの詳細については、ドキュメントを参照してください。

上記の例では、これら2つのスクリプトをbashで記述することを選択しましたが、実際には、gitは任意のスクリプト言語で記述できるフックをサポートしています。 実行可能スクリプトの最初の行に正しいシバンを設定する限り、Ruby、Python、またはJavaScriptが優れた代替手段です。

たとえば、 pre-commitフックを次のようにNode.jsスクリプトとして書き直すことができます。

 #!/usr/bin/env node console.log("Changes are about to be commited")

ローカルフックとリモートフック

フックはローカルとリモート(またはクライアントとサーバー)に分離されています。 ローカルフックはローカルリポジトリでの特定のアクションの前または後に実行されますが、リモートフックはサーバーへのプッシュの前または後に実行されます。 ローカルポリシーは、その性質上、開発者がポリシーを簡単に変更できるため、ポリシーの適用に使用することはできません。 これらは主に、チーム内で適用したい特定のガイドラインに準拠するために使用されます。 より厳密にし、リポジトリにいくつかのポリシーを適用したい場合は、リモートフックに常駐します。

ローカルフック

  • pre-commit
  • prepare-commit-msg
  • commit-msg
  • post-commit
  • applypatch-msg
  • pre-applypatch
  • post-applypatch
  • pre-rebase
  • post-rewrite
  • post-checkout
  • post-merge
  • pre-push

リモートフック

  • pre-receive
  • update
  • post-receive

フックの共有

Gitフックは、チーム内で共有することです。 これが彼らが存在する主な理由です。より良いチームコラボレーションを促進し、有害なプロセスを自動化し、コードベースの重要な部分だけに集中できるようにします。

前に述べたように、 .git/hooksはカスタマイズされたフックをホストするフォルダーですが、このフォルダーはgitによって追跡されないため、チーム内でこれらのスクリプトを共有する必要がある場合はあまり役に立ちません。

これを解決するための良いアプローチは、リポジトリ内の別のフォルダーにすべてのカスタムフックを追加することです。 たとえば、 .githooksフォルダーを追加して、そこに実行可能スクリプトを保存できます。 次に、プロジェクトの初期化時に、フック.git/hooksを保持するために、これらのスクリプトを元のフォルダーに明示的にコピーまたはシンボリックリンクできます。

 find .git/hooks -type l -exec rm {} \\; find .githooks -type f -exec ln -sf ../../{} .git/hooks/ \\;

または、最新のgitバージョン( 2.9以降と言えば)を使用している場合は、カスタムフォルダーへのgitフックパスを直接構成できます。

 git config core.hooksPath .githooks

Gitフックを簡単に(JavaScriptコードベースのユースケース)

コードベースのニーズにgitフックをさらに統合するのに役立つツールがあります。 特にJavaScriptコードベースの場合、構成を通じてgitイベントのアクションを簡単にカスタマイズできるHuskyがあります。

たとえば、コードをリントするか、 pre-commitイベントでいくつかのテストを実行し、リンティング、テスト、またはその両方が成功したかどうかに基づいてコミットに進むことができます。

これは、 package.json構成を次のように拡張することで実現できます。

 { "scripts": { "test": "echo Running tests" }, "devDependencies": { "eslint": "5.16.0", }, "husky": { "hooks": { "pre-commit": "eslint . && npm test", } } }

結論

この記事では、gitリポジトリで実行されるさまざまなアクションにより、オプションでカスタムスクリプトの実行をトリガーできることがわかりました。 これらのスクリプトは、ローカルで開発者の管理下に置くことも、リモートのチームまたはプロジェクトに対してより集中的に管理することもできます。 また、スクリプトはbashのようなシェルスクリプトで記述されることが多いことも学びましたが、実際には、JavaScriptを含め、ほとんどすべてのスクリプト言語を使用できます。

Gitフックは、適切に設計されたワークフローの非常に強力な部分になる可能性があります。ぜひ試してみて、自分のプロジェクトで何ができるかを確認することをお勧めします。