Introduction

Git cannot ignore only selected lines inside a tracked file in any built-in, durable way. Git tracks whole-file content snapshots, not line-level ignore regions. So when people ask to "ignore local changes to part of a file," the real answer is usually to change the file layout or workflow rather than to look for a hidden partial-ignore feature.

Why .gitignore Does Not Solve This

.gitignore only affects untracked files. Once a file is already tracked, changes anywhere inside it still appear in git status.

echo "config.local.json" >> .gitignore
git status

That will stop Git from tracking a new untracked file named config.local.json, but it will not ignore changed lines inside a tracked config.json.

That distinction is the first thing to get clear.

The Best Fix: Split Shared and Local Configuration

The most maintainable solution is to keep committed defaults in one file and local overrides in another file that is ignored.

Tracked file:

1{
2  "apiBaseUrl": "https://api.example.com",
3  "featureFlag": false
4}

Local override file:

{
  "featureFlag": true
}

Then ignore the local file:

echo "settings.local.json" >> .gitignore

This removes the partial-ignore problem by moving local-only data into a separate untracked file.

Template Files Work Well Too

Another common pattern is to commit a template and let each developer copy it locally.

cp .env.example .env
echo ".env" >> .gitignore

This is a strong fit for:

• secrets
• machine-specific ports
• local service endpoints
• developer-only flags

Instead of trying to ignore part of .env, you stop tracking the real environment file entirely.

What About skip-worktree and assume-unchanged

Git has index flags that can suppress change noise for a tracked file, but they still work at file granularity, not line granularity.

git update-index --skip-worktree appsettings.json

These flags are local-only and easy to misuse. They can be cleared by later operations, they are invisible to teammates, and they often cause confusion when a file stops behaving normally.

So while they may be acceptable as a temporary local hack, they are not a clean team workflow for partial file changes.

Interactive Staging Solves a Different Problem

If your real need is only "do not commit these debug edits right now," git add -p is often enough.

git add -p

This does not ignore the lines permanently. It simply lets you stage only the hunks you want.

That is a good fit for:

• temporary logging
• one-off experiments
• leaving local edits unstaged while committing other work

It is not a replacement for proper config separation, but it is often the right day-to-day tool.

Advanced Filters Exist, but They Are Rarely Worth It

You can use clean and smudge filters in .gitattributes to transform files on checkout and check-in. That can emulate local-only regions, but it adds hidden complexity to the repository.

Once you do that, every contributor depends on:

• the same filter configuration
• the same helper scripts
• the same understanding of what is transformed when

For most teams, that is too fragile compared with simply splitting the file.

Common Pitfalls

• Expecting .gitignore to hide edits inside an already tracked file.
• Using skip-worktree as if it were a collaborative policy rather than a local index flag.
• Keeping secrets in tracked files and hoping partial ignoring will make that safe.
• Building complicated Git filters when a separate local config file would be clearer.
• Solving a one-off staging problem with a permanent ignore strategy instead of using git add -p.

Summary

• Git does not natively ignore only selected portions of a tracked file.
• '.gitignore works only for untracked paths, not tracked file regions.'
• The best fix is usually to separate committed config from ignored local overrides.
• 'skip-worktree and related flags are whole-file local hacks, not true partial-ignore support.'
• For temporary local edits, interactive staging is often simpler than trying to hide specific lines permanently.