Introduction

The fastest way to count lines in a git repository is git ls-files | xargs wc -l. For a language-aware breakdown that separates code from comments and blanks, use cloc $(git ls-files). This article covers both approaches along with advanced filtering, per-author attribution, historical tracking, and CI integration.

Basic Line Count with git ls-files and wc

The simplest approach pipes the list of tracked files into wc -l:

git ls-files | xargs wc -l

This produces a per-file count followed by a total:

1      42 src/main.py
2     156 src/utils.py
3      88 tests/test_main.py
4     286 total

git ls-files only lists files tracked by git, so anything in .gitignore is automatically excluded. This is an advantage over find . -type f, which would include build artifacts, node_modules, and other ignored content.

Handle Filenames with Spaces

If your repository contains files with spaces or special characters in their names, the basic pipe breaks. Use null-terminated output instead:

git ls-files -z | xargs -0 wc -l

The -z flag makes git ls-files output null-separated paths, and -0 tells xargs to split on null bytes instead of whitespace.

Filter by File Type

Counting every file is rarely what you want. A repository typically contains source code, configuration, documentation, images, and vendor dependencies. Filter by extension to get meaningful numbers:

1# Count only Python files
2git ls-files '*.py' | xargs wc -l
3
4# Count only JavaScript and TypeScript files
5git ls-files '*.js' '*.ts' '*.tsx' | xargs wc -l
6
7# Count only Java files
8git ls-files '*.java' | xargs wc -l
9
10# Exclude test files
11git ls-files '*.py' | grep -v test | xargs wc -l

You can also exclude entire directories:

git ls-files | grep -v -E '^(vendor/|node_modules/|third_party/)' | xargs wc -l

Language-Aware Counting with cloc

cloc (Count Lines of Code) is a dedicated tool that recognizes programming languages, separates code from comments and blank lines, and produces a structured report.

cloc $(git ls-files)

Sample output:

1-------------------------------------------------------------------------------
2Language                     files          blank        comment           code
3-------------------------------------------------------------------------------
4Python                          12            145             89            823
5JavaScript                       8             67             34            456
6YAML                             3             12              4             87
7Markdown                         2             34              0            112
8-------------------------------------------------------------------------------
9SUM:                            25            258            127           1478
10-------------------------------------------------------------------------------

Install cloc with your system package manager:

1# macOS
2brew install cloc
3
4# Ubuntu/Debian
5sudo apt install cloc
6
7# Windows (via Chocolatey)
8choco install cloc

cloc vs wc Comparison

For CI reporting or dashboards, cloc can output JSON:

cloc $(git ls-files) --json --out=line-counts.json

Count Lines by Author

To see how many lines each developer currently has in the repository:

git ls-files | xargs -n1 git blame --line-porcelain | grep "^author " | sort | uniq -c | sort -rn

This runs git blame on every file and counts lines per author. The output looks like:

   1523 author Alice Chen
    892 author Bob Smith
    456 author Carol Davis

Be aware that this takes significant time on large repositories because it runs git blame on every tracked file.

For a faster approximation, git shortlog counts commits rather than lines, but it gives a useful sense of contribution distribution:

git shortlog -sn --no-merges

Track Line Count Over Time

To see how the codebase size has changed, you can script git to check out historical commits and count lines:

1#!/bin/bash
2for commit in $(git log --oneline --reverse --format='%H' | head -20); do
3    count=$(git show "$commit":. 2>/dev/null | wc -l 2>/dev/null || echo 0)
4    date=$(git show -s --format='%ci' "$commit")
5    echo "$date $count"
6done

A more practical approach uses git diff --stat between two references:

1# Lines changed between two tags
2git diff --stat v1.0..v2.0
3
4# Summary of additions and deletions
5git diff --shortstat v1.0..v2.0

Sample output:

 45 files changed, 2340 insertions(+), 891 deletions(-)

Count Lines Changed in a Time Period

To measure recent development activity:

# Lines added and removed in the last 30 days
git log --since="30 days ago" --numstat --format="" | \
  awk '{added+=$1; removed+=$2} END {print "Added:", added, "Removed:", removed}'

This counts the net lines added and removed across all commits in the time window.

Integration with CI/CD

Adding line count tracking to a CI pipeline creates a historical record. Here is a GitHub Actions example:

1- name: Count lines of code
2  run: |
3    cloc $(git ls-files) --json --out=cloc-report.json
4    echo "### Lines of Code" >> $GITHUB_STEP_SUMMARY
5    cloc $(git ls-files) --md >> $GITHUB_STEP_SUMMARY
6
7- name: Upload report
8  uses: actions/upload-artifact@v4
9  with:
10    name: cloc-report
11    path: cloc-report.json

This adds a formatted table to the GitHub Actions summary page and saves the JSON report as a build artifact.

Alternative Tools

tokei and scc are notably faster than cloc on large repositories. scc also estimates code complexity (COCOMO model) alongside line counts:

scc .

Common Pitfalls

Using find . -type f | xargs wc -l instead of git ls-files counts untracked files like build outputs, dependencies, and editor temp files. Always use git ls-files to respect the repository's tracking rules.

Not handling filenames with spaces causes xargs to split paths incorrectly and produce wrong counts or errors. Always use the -z and -0 flags for robustness.

Counting lines without filtering by file type inflates the number with auto-generated code, lockfiles, and vendor dependencies. A 50,000-line repository might actually contain 8,000 lines of application code and 42,000 lines of package-lock.json.

Confusing total lines with lines of code is misleading. A file with 100 lines might contain 60 lines of code, 25 lines of comments, and 15 blank lines. Use cloc or similar tools when the distinction matters.

Running git blame across the entire repository for author attribution is slow on large codebases. It scales linearly with repository size and history depth. For rough estimates, git shortlog -sn is much faster.

Summary

• Use git ls-files | xargs wc -l for a quick total line count of tracked files.
• Use git ls-files -z | xargs -0 wc -l when filenames may contain spaces.
• Filter by extension (git ls-files '*.py') to count only relevant source files.
• Use cloc $(git ls-files) for language-aware breakdown of code, comments, and blanks.
• Use git diff --shortstat to measure changes between two points in history.
• Consider tokei or scc as faster alternatives to cloc for large repositories.