How to format the code on Git Push and Pull

Question

I am currently working on development projects with different languages (TS, TSX) with different developers. Moreover we use Prettier/ESLint, but it's a detail.

And some developers are used to develop with 2 indentation, and the use of spaces. And some use 4 indentation, and prefer tabs.

The problem is that when we get the code from github, the indentation may be that of another developer and therefore not the one that corresponds to us. When a developer retrieves this code indented to 2, is working with 4 indentation, the entire files are detected as being modified by git.

Is it possible to perform at the time of a clone/pull/fetch, a formatting of the code to match our preferences? And at the time of the creation of a pull request/push/commit, to format the code so that it corresponds to that present on the repository?

We have tried several things to solve this problem but without success:

• We tried using clean and smudge, but it never worked:
  Can git automatically switch between spaces and tabs?

• We tried github actions, the problem is that to find a specific modification, it is not practical at all.

Answer 1

Pushing and fetching are not points at which code can be formatted, because Git simply pushes or fetches the data that's already there. Other than deltifying and compressing it, it really doesn't change the data sent in any way.

However, the way most organizations do this is to set up a set of code standards and a lint tool to enforce them. For example, in Rust, you're likely going to use 4 spaces and rustfmt to format the code. Then, you set up your CI to run the linter or style checked and fail if it's not correct. Thus, code cannot be merged if it doesn't meet code style.

While everyone is welcome to have their own preferences about how to format code, when you're working together on a project, it's completely normal and reasonable to require everyone to agree on a set of standards. Not everyone has to like it: the Go team explicitly agrees that the standard Go style is not anyone's favourite, but it's a fixed standard and everyone adheres to it. I myself have rigorously enforced code style changes which differed from my preferred style simply because it was more important that everyone use the same style.

This becomes much easier if you have a tool to auto-format the code because then everyone just runs that tool and it can be automatically checked without needing to consider it at all in code review. It either passes CI or it doesn't.

Note that you can provide pre-commit hooks if you want to, but you shouldn't require them, since it can be useful for users to create improperly formatted temporary commits in advanced workflows. Since the Git FAQ mentions that hooks on the developer machine are not an effective control , you need to set CI up anyway.

Answer 2

You may find this article helpful; the author shows how to enforce code style using clang-format with a local pre-commit workflow (or hook), as well as PR actions.

As a bare minimum, an .editorconfig file is a good idea, and as long as the team members are judicious about running a simple auto-format after making changes, the indention style and spaces can become a non-issue. For me, running the auto-format shortcut quickly became as habitual as CTRL+S.