Hooks, Aliases, Templates, Attributes, and Local Automation: Configuration, Design Choices, and Tradeoffs

1. Configuration design starts with “who must receive this?”

Git's customization surfaces look similar when typed as commands, but they distribute differently. A local alias is workstation state. A tracked .gitattributes file is project history. A template is copied at repository creation. A hook script may be tracked, but activation is normally configuration. Server-side hooks/policies belong to the authoritative receive environment.

2. Inspect scope and origin before changing configuration

git config --list --show-origin --show-scope
git config --show-origin --show-scope --get core.hooksPath
git config --show-origin --show-scope --get init.templateDir
git config --show-origin --show-scope --get core.attributesFile
git config --show-origin --show-scope --get-regexp '^alias\.'

System and global values can affect many repositories. Local values live with one repository's metadata. Worktree-scoped values can apply when worktree configuration is enabled. For training and incident reproduction, prefer explicit local or command-scoped settings over silently mutating a learner's global configuration.

3. core.hooksPath centralizes hook lookup—but adds a runtime dependency

When set, Git looks for hook names in the configured path instead of the default $GIT_DIR/hooks. The path may be absolute or relative; a relative path is interpreted relative to the directory where hooks execute.

git config --local core.hooksPath .githooks
git config --path --get core.hooksPath

A tracked relative path is convenient because the hook files can travel with project history. Its activation still depends on configuration and the required interpreter/runtime.

4. Compare hook distribution strategies

5. Template source selection has explicit precedence

When initializing a repository, Git checks the explicit --template argument first, then GIT_TEMPLATE_DIR, then init.templateDir, then Git's default template directory. Under current documented behavior, entries whose names begin with a dot are not copied from the template directory.

Because templates can include hook files, treat an organization template directory as executable-code distribution and review it accordingly.

6. alias.* should make intent shorter, not less visible

git config --local alias.st 'status --short --branch'
git config --local alias.graph 'log --graph --decorate --oneline --all'
git config --get-regexp '^alias\.'

Git ignores aliases that attempt to hide existing Git commands. A !-prefixed alias executes through a shell and receives extra command-line arguments, so it should be reviewed like a script. For CI, prefer the canonical command in the repository's automation source.

7. Attribute precedence is a policy stack

Highest precedence comes from $GIT_DIR/info/attributes. Then Git considers per-directory tracked .gitattributes, with files closer to the target path taking precedence over more distant parent directories. User/global and system attributes have lower precedence.

git check-attr --all -- path/to/file
git check-attr --source=HEAD --all -- path/to/file

The second form can evaluate attributes from a committed tree, which is valuable when you need to separate current working-tree rules from release-tag policy.

8. Attribute patterns resemble ignore patterns but are not identical

Two differences often cause mistakes: negative patterns are forbidden in .gitattributes, and a directory pattern such as docs/ does not recursively match every path under that directory. Use docs/** when recursive attribute assignment is intended.

9. Choose a repository normalization policy before changing old content

* text=auto
*.sh text eol=lf
*.bat text eol=crlf
*.png binary

This keeps text blobs normalized in the repository and makes working-tree endings explicit for formats that need them. Existing history is not retroactively rewritten. If you introduce normalization to already-tracked files, git add --renormalize . can stage normalization changes for review.

10. Explicit binary classification prevents inappropriate text transformations

*.png binary
*.zip binary
*.pdf -text -diff

The built-in binary macro unsets text, diff, and merge. That prevents line-ending normalization and ordinary textual diff/merge behavior for those paths.

11. Custom diff drivers trade richer review for command-execution complexity

*.policy diff=policytext

[diff "policytext"]
    command = trusted-policy-diff

The attribute name can be shared in history, but the configured command is external executable behavior. This can improve review of opaque formats, but every workstation/CI environment needs a compatible trusted command. Do not enable a driver command merely because an untrusted repository requests its name.

12. Custom merge drivers carry even higher operational risk

*.lock merge=lockfile

[merge "lockfile"]
    name = Trusted lockfile merger
    driver = trusted-lock-merge %O %A %B %L %P

The driver receives temporary files and is expected to write the result and return a success/conflict status. A defective driver can silently create semantically wrong merges, so production use requires deterministic tests and clear ownership. Built-in text/binary handling is the safer portable default when domain-specific merge semantics are not mature.

13. Decide what belongs locally, in CI, and on the server

14. Portable hook distribution means declaring runtime prerequisites

A POSIX sh hook is convenient on Linux/macOS and commonly available inside Git for Windows environments, but not every Git client or GUI launches through the same shell/runtime assumptions. Python, Node.js, PowerShell, or compiled hook tools have their own installation/version dependencies.

A robust team policy states the supported operating systems, interpreter/runtime version, failure behavior when dependencies are missing, and the equivalent centralized check that prevents local-runtime gaps from becoming policy gaps.

15. Worked decision — cross-platform monorepo

Suppose a Windows/Linux/macOS team needs LF shell scripts, binary design assets, commit-message feedback, and mandatory tests before trunk changes. A maintainable design is:

• tracked .gitattributes for LF/binary path semantics;
• tracked, reviewed hook scripts for optional fast feedback;
• documented bootstrap to activate core.hooksPath locally;
• CI that repeats all mandatory checks in a defined runtime;
• server/hosting protection that refuses unauthorized trunk updates.

This costs more than one clever local hook, but it separates convenience from enforcement and reduces platform drift.

16. Knowledge check

17. Summary

Configuration architecture should make distribution and trust explicit. Use local hooks/aliases for ergonomics, tracked attributes for shared path semantics, templates for init-time seeding, CI for repeatable shared checks, and server/hosting controls for authoritative ref policy. External diff/merge drivers are executable dependencies and should be treated accordingly.

Authoritative references

• git-config
• git-init
• gitattributes
• githooks