What is the relationship between continuous integration and git hooks?

Question

I'm trying to get into the habit of making sure that each master commit to a repository I work on does not break any existent tests. In my current flawed workflow, there are some intermediate commits on master that do not pass all tests, and I'm trying to adopt a solution to this.

From About Continuous Integration

Building and testing your code requires a server. You can build and test updates locally before pushing code to a repository, or you can use a CI server that checks for new code commits in a repository.

What I've been unable to figure out is whether continuous integration is built on git hooks, an exclusive alternative to git hooks, or a complementary solution.

What is the relationship between Continuous Integration and git hooks?

I've seen the question CI platforms versus simple git hooks but I understand the answer to be posing them as alternatives, where git hooks are practical for solo/smaller projects, and CI is able to scale more appropriately with larger projects. At the same time, I see articles like 3 Git hooks for continuous integration, which makes the relationship seem more than them just being alternatives.

Bringing up CI's different relationship with server-side vs. local git hooks specifically would help clear things up too.

Answer 1

There is no relationship between Continuous Integration and Git Hooks.

Or, to put it more precisely: the relationship between CI and Git Hooks is the same as the relationship between CI and your keyboard: CI needs to run code, and your keyboard can be used to run code by typing it into a shell, therefore your keyboard can be used to run CI.

Git Hooks run code, and CI is code, therefore Git Hooks can run CI.

Note: when I say "CI is code", that is obviously not true. CI is an engineering practice, in other words, it is a social construct, not code.

However, Continuous Integration works best when it is automated through code, so when I write "CI is code", I mean "ideally, you should have some sort of automated thingamajig that integrates your code and runs your tests", and that "automated thingamajig" is code. That automated thingamajig could be a two-line shell script that you wrote, or it could be a 100000 line cloud-based CI framework.

It could be triggered by a pigeon that pecks a certain button whenever a new commit arrives in the repository, it could be time-based and run every night at midnight, or it could be triggered by every commit or every push. And this "triggering" could be done with a Git Hook.

That is the only relationship between Git Hooks and CI: CI needs to run some code, Git Hooks can run some code, so Git Hooks can be used to run some CI code. However, Git Hooks can be used for lots of other stuff, and lots of other stuff can be used to run CI code.

For example, I run my CI using GitHub Actions – no Git Hooks involved.

Answer 2

First, lets make definition of Continuous Integration clear, originally, CI meant

Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible.

Martin Fowler

It explicitly calls CI a software developmpent practice. The confusion might come, when people use slithgly different definition, where they only mean the concept of running automated builds and tests against those builds against commits in source control. Which is what is meant by "CI Platforms" in the article. Those are just pieces of software you could use to enable your own CI practice. Not something that is necessary to run your CI.

Going by the first definition, Git hooks would be just a single tool you could use to make your CI work. They are not necessary for CI and there are alternatives. But you can use them to make your CI work better.