Git Configuration, Ignore Rules, and Hooks

Configure Git, create effective .gitignore rules, use aliases, and understand client-side hooks.

Git Configuration

Git configuration exists at multiple levels: system, global, and local repository configuration. Local repository configuration has higher precedence than global configuration.

Common configuration includes user identity, default branch name, editor, aliases, and pull behavior.

Configure Git Identity

git config --global user.name "Suriya"
git config --global user.email "developer@example.com"
git config --global init.defaultBranch main
git config --list --show-origin

💡 Global configuration applies to repositories for the current user. Repository-local configuration can override global settings.

Key Takeaways

Git configuration can exist at multiple scopes.
Local repository configuration can override global settings.
Use --show-origin to understand where a configuration value came from.

Knowledge Check

Which configuration generally has higher precedence: local repository configuration or global configuration?

.gitignore

The .gitignore file defines patterns for files Git should normally leave untracked. Common examples include build output, dependency directories, local environment files, editor metadata, and logs.

Ignoring a file does not remove it from history if it is already tracked. In that case, you need to remove it from the index while optionally keeping it on disk.

Useful Ignore Rules

# .gitignore
node_modules/
dist/
.env
*.log
.vscode/

# Stop tracking an already committed environment file
git rm --cached .env

💡 The patterns ignore common generated or local files. git rm --cached removes a tracked file from Git's index while leaving the local file on disk.

Key Takeaways

Ignore rules affect untracked files.
Adding a tracked file to .gitignore does not automatically untrack it.
Never commit secrets such as production credentials.

Knowledge Check

What happens if a file is already tracked and you add it to `.gitignore`?

Git Aliases

Git aliases create shorter commands for frequently used operations. They can improve productivity when used for commands that are stable and easy to remember.

Create Useful Aliases

git config --global alias.co checkout
git config --global alias.st status
git config --global alias.lg "log --oneline --graph --decorate --all"

git st
git lg

💡 Aliases are stored in Git configuration. Shell commands and complex aliases can be created, but keep aliases understandable for team environments.

Key Takeaways

Aliases are configuration conveniences.
Keep important team instructions independent of personal aliases.
Aliases can wrap complex Git commands.

Knowledge Check

Where are Git aliases commonly stored when created with `git config --global`?

Git Hooks

Git hooks are scripts triggered by Git lifecycle events. Client-side hooks can run before commits, after commits, before pushes, and during other operations. Teams often use hooks to run formatting, linting, tests, or validation.

Hooks are local by default and are not automatically versioned simply because they exist in .git/hooks.

Simple Pre-Commit Hook

# .git/hooks/pre-commit
#!/bin/sh
npm test
if [ $? -ne 0 ]; then
  echo "Tests failed. Commit aborted."
  exit 1
fi

💡 A non-zero exit code from the pre-commit hook prevents the commit. Teams often use hook-management tools when hooks need to be shared consistently.

Key Takeaways

Hooks can enforce local development checks.
Client-side hooks can be bypassed or may not exist on every developer machine.
Critical validation should also run in CI.

Knowledge Check

Which hook commonly runs before a commit is created?