If you need to run operations before completing a Git commit, you can rely on Git Hooks. Git hooks are scripts that run automatically whenever a particular event occurs in a Git repository. They let you customize Git’s internal behaviour and trigger customizable actions at key points in the development life cycle. Extending Git hooks allows you to plug in to the regular Git flow, such as Git , , etc. custom functionalities message validation code formatting I’ve already described how to use , but here I’m gonna use , the version of Husky created for .NET-based applications. Husky with NPM Husky.NET Git hooks: a way to extend Git operations As we said, Git hooks are actions that run during specific phases of Git operations. Git hooks fall into : 4 categories : they execute when you run on your local repository; client-side hooks related to the committing workflow git commit : they are executed when running , which is a command that allows you to integrate mails and Git repositories (I’ve never used it. If you are interested in this functionality, ); client-side hooks related to the email workflow git am here’s the official documentation : these hooks run on your local repository when performing operations like ; client-side hooks related to other operations git rebase : they run after a commit is received on the remote repository, and they can reject a operation. server-side hooks git push Let’s focus on the client-side hooks that run when you commit changes using . git commit How to install Husky.NET and its dependencies in a .NET Application Husky.NET must be installed in the of the solution. root folder You first have to by running: create a file in the root folder tool-manifest dotnet new tool-manifest This command creates a file named under the folder: here, you can see the list of external tools used by dotnet. dotnet-tools.json .config After running the command, you will see that the file contains this element: dotnet-tools.json {
  "version": 1,
  "isRoot": true,
  "tools": {}
} Now you can by running: add Husky as a dotnet tool dotnet tool install Husky After running the command, the file will contain something like this: {
  "version": 1,
  "isRoot": true,
  "tools": {
    "husky": {
      "version": "0.6.2",
      "commands": ["husky"]
    }
  }
} Now that we have added it to our dependencies, we can by running: add Husky to an existing .NET application dotnet husky install If you open the root folder, you should be able to see these 3 folders: , which contains the info about the Git repository; .git that contains the description of the tools, such as ; .config dotnet-tools that contains the files we are going to use to define our Git hooks. .husky Finally, you can by running, for example, add a new hook dotnet husky add pre-commit -c "echo 'Hello world!'"
git add .husky/pre-commit This command creates a new file, (without file extension), under the folder. By default, it appears like this: pre-commit .husky #!/bin/sh
. "$(dirname "$0")/_/husky.sh"

## husky task runner examples -------------------
## Note : for local installation use 'dotnet' prefix. e.g. 'dotnet husky'

## run all tasks
#husky run

### run all tasks with group: 'group-name'
#husky run --group group-name

## run task with name: 'task-name'
#husky run --name task-name

## pass hook arguments to task
#husky run --args "$1" "$2"

## or put your custom commands -------------------
#echo 'Husky.Net is awesome!'

echo 'Hello world!' The default content is pretty useless; it’s time to customize that hook. Notice that the latest command has also generated a file; we will use it later. task-runner.json Your first pre-commit hook To customize the script, . open the file located at .husky/pre-commit Here, you can add whatever you want. In the example below, I run commands that compile the code, format the text (using with the rules defined in the .editorconfig file), and then run all the tests. dotnet format #!/bin/sh
. "$(dirname "$0")/_/husky.sh"

echo 'Building code'
dotnet build

echo 'Formatting code'
dotnet format

echo 'Running tests'
dotnet test Then, add it to Git, and you are ready to go. 🚀 But wait… 3 ways to manage dotnet format with Husky.NET There is a problem with the approach in the example above. Let’s simulate a usage flow: you modify a C# class; you run ; git commit -m "message" the pre-commit hook runs ; dotnet build the pre-commit hook runs ; dotnet format the pre-commit hook runs ; dotnet test after the hooks, the commit is created. What is the final result? Since modifies the source files, and given that the snapshot has already been created before executing the hook, all ! dotnet format the modified files will not be part of the final commit Also, executes linting on every file in the solution, not only those that are part of the current snapshot. The operation might then take a lot of time, depending on the size of the repository, and most of the time, it will not update any file (because you’ve already formatted everything in a previous run). dotnet format We have to work out a way to fix this issue. I’ll suggest three approaches. Include all the changes using Git add The first approach is quite simple: after . run git add . dotnet format So, the flow becomes: you modify a C# class; you run ; git commit -m "message" the pre-commit hook runs ; dotnet build the pre-commit hook runs ; dotnet format the pre-commit hook runs ; git add . the pre-commit hook runs ; dotnet test Git creates the commit. This is the most straightforward approach, but it has some downsides: is executed on every file in the solution. The more your project grows, the slower your commits become; dotnet format adds to the current snapshot all the files modified, even those you did not add to this commit on purpose (maybe because you have updated many files and want to create two distinct commits). git add . So, it works, but we can do better. Execute a dry run of dotnet-format You can to the command: this flag returns an error if at least one file needs to be updated because of a formatting rule. add the --verify-no-changes dotnet format Let’s see how the flow changes if one file needs to be formatted. you modify a C# class; you run ; git commit -m "message" the pre-commit hook runs ; dotnet build the pre-commit hook runs ; dotnet format --verify-no-changes the pre-commit hook returns an error and aborts the operation; run on the whole solution to fix all the formatting issues; you dotnet format you run ; git add . you run ; git commit -m "message" the pre-commit hook runs ; dotnet build the pre-commit hook runs . Now, there is nothing to format, and we can proceed; dotnet format --verify-no-changes the pre-commit hook runs ; dotnet test Git creates the commit. Notice that, this way, if there is something to format, the whole commit is aborted. You will then have to run on the entire solution, fix the errors, add the changes to the snapshot, and restart the flow. dotnet format It’s a longer process, but it allows you to have complete control over the formatted files. Also, you won’t risk including in the snapshot the files you want to keep staged in order to add them to a subsequent commit. Run dotnet-format only on the staged files using Husky.NET Task Runner The third approach is the most complex but with the best result. If you recall, during the initialization, Husky added two files in the folder: and . .husky pre-commit task-runner.json The key to this solution is the file. This file allows you to . task-runner.json create custom scripts with a name, a group, the command to be executed, and its related parameters By default, you will see this content: {
  "tasks": [
    {
      "name": "welcome-message-example",
      "command": "bash",
      "args": ["-c", "echo Husky.Net is awesome!"],
      "windows": {
        "command": "cmd",
        "args": ["/c", "echo Husky.Net is awesome!"]
      }
    }
  ]
} To make sure that runs only on the staged files, you must like this: dotnet format create a new task {
  "name": "dotnet-format-staged-files",
  "group": "pre-commit-operations",
  "command": "dotnet",
  "args": ["format", "--include", "${staged}"],
  "include": ["**/*.cs"]
} Here, we have specified a name, , the command to run, , with some parameters listed in the array. Notice that parameter, which is populated by Husky.NET. dotnet-format-staged-files dotnet args we can filter the list of files to be formatted by using the ${staged} We have also added this task to a named that we can use to reference a list of tasks to be executed together. group pre-commit-operations If you want to run a specific task, you can use . In our example, the command would be . dotnet husky run --name taskname dotnet husky run --name dotnet-format-staged-files If you want to run a set of tasks belonging to the same group, you can run . In our example, the command would be . dotnet husky run --group groupname dotnet husky run --group pre-commit-operations The last step is to call these tasks from within our file. So, replace the old command with one of the above commands. pre-commit dotnet format Final result and optimizations of the pre-commit hook Now that everything is in place, we can improve the script to make it faster. Let’s see which parts we can optimize. The first step is the . For sure, we have to run to see if the project builds correctly. You can consider adding the flag to skip the step before building. build phase dotnet build --no-restore restore Then we have the : we can avoid formatting every file using one of the steps defined before. I’ll replace the plain with the execution of the script defined in the Task Runner (it’s the third approach we saw). format phase dotnet format Then, we have the . We can add both the and the flag to the command since we have already built everything before. ! The format phase updated the content of our files, so we still have to build the whole solution. Unless we swap the and the phases. test phase --no-restore --no-build But wait build format So, here we have the final file: pre-commit #!/bin/sh
. "$(dirname "$0")/_/husky.sh"

echo 'Ready to commit changes!'

echo 'Format'

dotnet husky run --name dotnet-format-staged-files

echo 'Build'

dotnet build --no-restore

echo 'Test'

dotnet test --no-restore

echo 'Completed pre-commit changes' Yes, I know that when you run the command, you also build the solution, but I prefer having two separate steps just for clarity! dotnet test Ah, and at the beginning of the script! don’t remove the #!/bin/sh How to skip Git hooks To trigger the hook, just run . completing the commit, the hook will run all the commands. . git commit -m "message" Before If one of them fails, the whole commit operation is aborted There are cases when you have to . For example, if you have integration tests that rely on an external source currently offline. In that case, some tests will fail, and you will be able to commit your code only once the external system gets working again. skip the validation You can skip the commit validation by adding the flag: --no-verify git commit -m "my message" --no-verify Further readings Husky.NET is a porting of the Husky tool we already used in a previous article, using it as an NPM dependency. In that article, we also learned how to customize Conventional Commits using Git hooks. 🔗 How to customize Conventional Commits in a .NET application using GitHooks | Code4IT As we learned, there are many more Git hooks that we can use. You can see the complete list on the Git documentation: 🔗 Customizing Git - Git Hooks | Git docs Of course, if you want to get the best out of Husky.NET, I suggest you have a look at the official documentation: 🔗 Husky.Net documentation One last thing: we installed Husky.NET using dotnet tools. If you want to learn more about this topic, I found an excellent article online that you might want to read: 🔗 Using dotnet tools | Gustav Ehrenborg Wrapping up In this article, we learned how to create a Git hook and validate all our changes before committing them to our Git repository. pre-commit We also focused on the formatting of our code: how can we format only the files we have changed without impacting the whole solution? I hope you enjoyed this article! Let’s keep in touch on or ! 🤜🤛 Twitter LinkedIn Happy coding! 🐧 Also published . here

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

Optimizing .NET Development Workflow with Git Hooks and Husky.NET

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

A Beginner's Guide to Public Speaking: My Experience With My First Speech

3 Excel Libraries Every .NET Developer Must Know

The Noonification: Will You Be My GPT-Valentine? (2/13/2023)

5 Performance Tips For .Net Developers

5 Ways to Add Security to Excel & PDF with .NET Document APIs

A Guide to Kubernetes Autoscaling Tools with Linode Kubernetes Engine

A Beginner's Guide to Public Speaking: My Experience With My First Speech

3 Excel Libraries Every .NET Developer Must Know

The Noonification: Will You Be My GPT-Valentine? (2/13/2023)

5 Performance Tips For .Net Developers

5 Ways to Add Security to Excel & PDF with .NET Document APIs

A Guide to Kubernetes Autoscaling Tools with Linode Kubernetes Engine

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps