githooks

by Daniel Deutsch

由Daniel Deutsch

使用Githooks改善團隊的開發工作流程 (Improve your team’s development workflow with Githooks)

Every product that is developed by more than one programmer needs to have some guidelines to harmonize the workflow.

由多個程序員開發的每個產品都需要有一些準則來協調工作流程。

A standardized software development workflow between programmers allows, for example:

程序員之間的標準化軟件開發工作流程允許例如：

• faster engineering, since each developer can rely on a habitual activity
  更快的工程設計，因為每個開發人員都可以依靠習慣性活動
• fewer errors, as the workflow itself shall be structured in a way to avoid some mistakes
  錯誤更少，因為工作流本身的結構應避免某些錯誤
• easy integration of new members
  輕松整合新成員
• improved log of history
  改進的歷史記錄

One very easy to use feature are “Githooks”(if you are using Git for version control).

一個非常易于使用的功能是“ Githooks ”(如果您使用Git進行版本控制)。

In this article I want to show how easy it actually is to set up a few workflow guidelines with Githooks. This will allow your team to be on one page when developing software.

在本文中，我想展示使用Githooks設置一些工作流程指南實際上是多么容易。 這樣一來，您的團隊就可以在開發軟件時集中在一頁上。

目錄 (Table of Contents)

• Why Githooks?

  為什么選擇Githooks？

• GitFlow and Checkout, Commit, Push

  GitFlow和簽出，提交，推送

• Post-checkout

  結帳后

• Commit-msg

  提交消息

• Pre-push

  預推

• “Enforce” the hooks

  “執行”掛鉤

• Fix one common problem

  解決一個常見問題

• Thanks

  謝謝

為什么選擇Githooks？ (Why Githooks?)

Githooks are, as the word suggests, a hook for Git commands. Intuitively this makes sense. With Git you are essentially managing the workflow of a piece of software. Every Branch is a part of the whole piece. Every Commit is a building block of a Branch.

顧名思義，Githooks是Git命令的鉤子。 直觀上講，這是有道理的。 使用Git，您實際上是在管理軟件的工作流程。 每個分支都是整體的一部分。 每個提交都是分支的構建塊。

So in order to standardize quality in software development, one must standardize actions in the building process of the product.

因此，為了標準化軟件開發的質量，必須標準化產品構建過程中的動作。

There are many Git commands that can be hooked for setting standards. Remember, there are quite a few:

可以掛鉤許多Git命令來設置標準。 請記住，有很多：

• applypatch-msg
  Applypatch-msg
• pre-applypatch
  預先貼布
• post-applypatch
  申請后
• pre-commit
  預先提交
• prepare-commit-msg
  準備提交消息
• commit-msg
  提交消息
• post-commit
  提交后
• pre-rebase
  變基前
• post-checkout
  結帳后
• post-merge
  合并后
• pre-receive
  預先接收
• pre-push
  預推
• update
  更新
• post-update
  更新后
• pre-auto-gc
  前自動gc
• post-rewrite
  重寫后

To establish an improved workflow you don’t have to use all of them. Focus on the few important ones. In my experience so far, those are:

要建立改進的工作流程，您不必全部使用。 專注于幾個重要的方面。 根據我到目前為止的經驗，這些是：

• commit-msg/pre-commit
  提交消息/預提交
• post-checkout
  結帳后
• pre-push
  預推

Let me explain why.

讓我解釋一下原因。

GitFlow和簽出，提交，推送 (GitFlow and Checkout, Commit, Push)

Using Git as version control system allows to set a workflow. I do this using the GitFlow method.

使用Git作為版本控制系統可以設置工作流程。 我使用GitFlow方法執行此操作。

It is basically to develop a piece of software where each feature is represented by a branch.

基本上是要開發一種軟??件，其中每個功能都由一個分支表示。

In the following examples I will always check naming with Regex tests or execute another script.

在以下示例中，我將始終使用Regex測試檢查命名或執行其他腳本。

結帳后 (Post-checkout)

The increased importance of a branch allows for the first hook on “post-checkout”. It is triggered after a new branch is created with Git.

分支機構重要性的提高使您可以在“結帳后”上進行第一個掛鉤。 使用Git創建新分支后，將觸發該事件。

Often a naming convention is applied to make branches comparable and understand their use for the whole product.

通常使用命名約定來使分支具有可比性，并了解分支在整個產品中的用途。

You can create a simple shell script like this to ensure naming:

您可以創建一個簡單的shell腳本，以確保命名：

提交消息 (Commit-msg)

In web development there are multiple libraries that help with setting up a hook for committing. Often they are not necessary, as simple scripts can be written by yourself as well.

在Web開發中，有多個庫可幫助設置提交鉤子。 通常它們不是必需的，因為您也可以自己編寫簡單的腳本。

See validation of a git message for example:

例如，請參見驗證git消息：

預推 (Pre-push)

“Git push” is the process of “sharing” your branch with the team. It is often the last step before opening a pull-request for a merge with the main branch.

“推擠”是與團隊“共享”分支的過程。 這通常是打開與主分支合并的拉取請求之前的最后一步。

This is a good time to check other guidelines like “linting” of the code, or if all tests are passing.

現在是檢查其他準則(如代碼的“ lint”)或所有測試是否通過的好時機。

An example for executing another script could be:

執行另一個腳本的示例可能是：

“執行”掛鉤 (“Enforce” the hooks)

Another step is to actually enforce those hooks.

另一個步驟是實際執行這些掛鉤。

In JavaScript and NPM/Yarn package managers there is a “postinstall” script already built in. It allows for the execution of a script after the installing process. But what exactly should be executed?

在JavaScript和NPM / Yarn程序包管理器中，已經內置了一個“后安裝”腳本。它允許在安裝過程之后執行腳本。 但是到底應該執行什么呢？

Create your own install script! Like:

創建您自己的安裝腳本！ 喜歡：

解決一個常見問題 (Fix one common problem)

One issue that kept me guessing for a while was that Git hooks are NOT executable by default. This means that they need to be made executable with

一個讓我猜了一段時間的問題是，默認情況下，Git掛鉤不可執行。 這意味著需要通過以下方式使它們成為可執行文件：

chmod +x <pathToHook>

chmod +x <pathToHo ok>

See StackOverflow discussion here.

請參閱此處的 StackOverflow討論。

謝謝 (Thanks)

I hope that this will help some of you to align the workflow of your development team and make everyone’s lives much easier. :-)

我希望這將有助于你們中的一些人調整開發團隊的工作流程，并使每個人的生活變得更加輕松。 :-)

Thanks for reading my article! Feel free to leave any feedback!

感謝您閱讀我的文章！ 隨時留下任何反饋！

Daniel is a software developer, a LL.M. student in business law, and organizer of tech-related events in Vienna. His current personal learning efforts focus on machine learning.

Daniel是LL.M.的軟件開發人員。 商法專業學生，維也納技術相關活動的組織者。 他目前的個人學習重點是機器學習。

Connect on:

連接：

• LinkedIn

  領英

• Github

  Github

• Medium

  中

• Twitter

  推特

• Steemit

  Steemit

• Hashnode

  哈希節點

翻譯自: https://www.freecodecamp.org/news/improve-development-workflow-of-your-team-with-githooks-9cda15377c3b/

githooks