Configure Git Repository

Set up a Git repository with appropriate configuration for the project type.

When to Use

• Initializing version control for a new project
• Adding

  .gitignore

  for a specific language/framework
• Setting up branch protection and conventions
• Configuring commit hooks

Inputs

• Required: Project directory
• Required: Project type (R package, Node.js, Python, general)
• Optional: Remote repository URL
• Optional: Branch strategy (trunk-based, Git Flow)
• Optional: Commit message convention

Procedure

Step 1: Initialize Repository

cd /path/to/project
git init
git branch -M main

Got:

.git/

directory created. Default branch is named

main

.

If fail: If

git init

fails, ensure Git is installed (

git --version

). If the directory already has a

.git/

, the repository is already initialized — skip this step.

Step 2: Create .gitignore

R Package:

# R artifacts
.Rhistory
.RData
.Rproj.user/
*.Rproj

# Environment (sensitive)
.Renviron

# renv library (machine-specific)
renv/library/
renv/staging/
renv/cache/

# Build artifacts
*.tar.gz
src/*.o
src/*.so
src/*.dll

# Documentation build
docs/
inst/doc/

# IDE
.vscode/
.idea/

# OS
.DS_Store
Thumbs.db

Node.js/TypeScript:

node_modules/
dist/
build/
.next/
.env
.env.local
.env.*.local
*.log
npm-debug.log*
.DS_Store
Thumbs.db
.vscode/
.idea/
coverage/

Python:

__pycache__/
*.py[cod]
*.egg-info/
dist/
build/
.eggs/
.venv/
venv/
.env
*.log
.mypy_cache/
.pytest_cache/
htmlcov/
.coverage
.DS_Store
.idea/
.vscode/

Got:

.gitignore

file created with entries appropriate for the project type. Sensitive files (

.Renviron

,

.env

) and generated artifacts are excluded.

If fail: If unsure which entries to include, use

gitignore.io

or GitHub's

.gitignore

templates as a starting point and customize for the project.

Step 3: Create Initial Commit

git add .gitignore
git add .  # Review what's being added first with git status
git commit -m "Initial project setup"

Got: First commit created containing

.gitignore

and initial project files.

git log

shows one commit.

If fail: If

git commit

fails with "nothing to commit," ensure files were staged with

git add

. If it fails with an author identity error, set

git config user.name

and

git config user.email

.

Step 4: Connect Remote

# Add remote
git remote add origin git@github.com:username/repo.git

# Push
git push -u origin main

Got: Remote

origin

is configured.

git remote -v

shows fetch and push URLs. Initial commit is pushed to the remote.

If fail: If push fails with "Permission denied (publickey)," configure SSH keys (see

setup-wsl-dev-environment

). If the remote already exists, update it with

git remote set-url origin <url>

.

Step 5: Set Up Branch Conventions

Trunk-based (recommended for small teams):

• main

  : production-ready code
• Feature branches:

  feature/description

• Bug fixes:

  fix/description

# Create feature branch
git checkout -b feature/add-authentication

# After work is done, merge or create PR
git checkout main
git merge feature/add-authentication

Got: Branch naming convention is established and documented. Team members know which prefix to use for each type of work.

If fail: If branches are already named inconsistently, rename them with

git branch -m old-name new-name

and update any open PRs.

Step 6: Configure Commit Conventions

Conventional Commits format:

type(scope): description

feat: add user authentication
fix: correct calculation in weighted_mean
docs: update README installation section
test: add edge case tests for parser
refactor: extract helper function
chore: update dependencies

Got: Commit message convention is documented and agreed upon by the team. Future commits follow the

type: description

format.

If fail: If team members are not following the convention, enforce it with a commit-msg hook that validates the format (see Step 7).

Step 7: Set Up Pre-Commit Hooks (Optional)

Create

.githooks/pre-commit

:

#!/bin/bash
# Run linter before commit

# For R packages
if [ -f "DESCRIPTION" ]; then
  Rscript -e "lintr::lint_package()" || exit 1
fi

# For Node.js
if [ -f "package.json" ]; then
  npm run lint || exit 1
fi

chmod +x .githooks/pre-commit
git config core.hooksPath .githooks

Got: Pre-commit hook runs automatically on each

git commit

. Linting errors block the commit until fixed.

If fail: If the hook does not run, verify

core.hooksPath

is set (

git config core.hooksPath

) and the hook file is executable (

chmod +x

).

Step 8: Create README

# Minimal README
echo "# Project Name" > README.md
echo "" >> README.md
echo "Brief description of the project." >> README.md
git add README.md
git commit -m "Add README"

Got:

README.md

committed to the repository. The project has a minimal but informative landing page on GitHub.

If fail: If

README.md

already exists, update it rather than overwriting. Use

usethis::use_readme_md()

in R projects for a template with badges.

Validation

• .gitignore

  excludes sensitive and generated files
• No sensitive data (tokens, passwords) in tracked files
• Remote repository connected and accessible
• Branch naming conventions documented
• Initial commit created cleanly

Pitfalls

• Committing before .gitignore: Add

  .gitignore

  first. Files already tracked aren't affected by later

  .gitignore

  entries.
• Sensitive data in history: If secrets are committed, they remain in history even after deletion. Use

  git filter-repo

  or BFG to clean.
• Large binary files: Don't commit large binaries. Use Git LFS for files > 1MB.
• Line endings: Set

  core.autocrlf=input

  on Windows/WSL to prevent CRLF/LF issues.

Related Skills

• commit-changes

  - staging and committing workflow

• manage-git-branches

  - branch creation and conventions

• create-r-package

  - Git setup as part of R package creation

• setup-wsl-dev-environment

  - Git installation and SSH keys

• create-github-release

  - creating releases from the repository

• security-audit-codebase

  - check for committed secrets