Articles
Published · July 1, 2026

How to Edit Config Files and Dotfiles Quickly on Mac and iOS

Config files and dotfiles are just plain text, so any fast editor can open them. Learn to reveal hidden files, edit .gitignore, set a global ignore, and stay consistent with .editorconfig on Mac and iOS.

Quick answer

Config files and dotfiles are plain text, so you don't need a full IDE to change them — any fast text editor opens them. On a Mac, reveal hidden dot-prefixed files in Finder with Command-Shift-Period. On iPhone and iPad, open them from the Files app in an editor that has a document picker.

The files you'll meet most often are just different plain-text formats: INI, JSON, YAML, TOML, and macOS Property Lists (`.plist`). They differ mainly in whether they allow comments and typed values. But they share one thing — you edit them as text, character by character, so exact syntax matters.

This guide walks the everyday cases: revealing hidden dotfiles, editing a .gitignore, setting one global ignore file, understanding where Git reads its config, and keeping formatting consistent with .editorconfig. Then a short problems-and-fixes list, and how Carets fits on Mac and iOS.

Step-by-step

See the file first

Most dotfiles are hidden because their names begin with a dot. In Finder, press Command-Shift-Period to toggle them on and off. On iPhone and iPad, the Files app shows dot-prefixed names inside folders you can reach, so an editor with a document picker can open them directly.

One rule holds everywhere: edit config files in a plain-text editor, not a rich-text one. Apple notes that these files are plain text, and a rich-text editor can quietly add smart quotes or formatting that stops a service from starting.

Edit a .gitignore

A .gitignore tells Git which files to leave untracked. Git reads ignore rules from three places: a committed .gitignore in the repository (shared with everyone who clones it), a per-repository .git/info/exclude (private to your copy), and a machine-wide file set through core.excludesFile.

The pattern syntax is small and worth knowing:

# a comment
build/          # trailing slash matches directories only
/secret.txt     # leading slash anchors to this folder
*.log           # * matches anything except a slash
!keep.log       # ! re-includes a previously ignored file
**/tmp          # ** matches across directories

Here's the common surprise: ignore rules don't affect files Git already tracks. If a file is already committed, run git rm --cached <file>, then add it to .gitignore and commit both changes.

Set one global ignore file

Some junk shows up in every project — .DS_Store on macOS, editor swap files like *.swp. Rather than repeat those in every .gitignore, set them once. GitHub documents the global ignore file: create ~/.gitignore_global, then register it.

git config --global core.excludesfile ~/.gitignore_global

Now those patterns apply to every repository on your machine, and no project has to carry OS-specific noise.

Understand the Git config hierarchy

When an edit doesn't seem to take, it usually helps to know where Git is reading from. Git layers three config files: /etc/gitconfig (system-wide), ~/.gitconfig or ~/.config/git/config (your user), and .git/config (the current repository). Each level overrides the one before it, so a repository setting wins over your global one.

All three are plain text. You can run git config --global user.name "Your Name" one key at a time, or open ~/.gitconfig in an editor and change several settings at once.

Keep formatting consistent with .editorconfig

Edit the same files across a Mac, an iPad, and a few different tools, and indentation and line endings start to drift. EditorConfig is an open spec that fixes this: a .editorconfig file in INI format, with glob sections, sets rules like indent_style, indent_size, end_of_line, charset, and insert_final_newline. Mark the top-level file with root = true so the search stops there.

root = true

[*]
indent_style = space
indent_size = 2
end_of_line = lf
insert_final_newline = true

Many editors read it, including Xcode 16, so your config and code stay consistent no matter which one you open.

Common problems and fixes

  • "My `.gitignore` is not working." The file is already tracked. Run git rm --cached <file>, then add it to .gitignore and commit.
  • "I cannot find the file." It's hidden. Reveal dotfiles with Command-Shift-Period on a Mac, or open it from your editor's document picker on iOS.
  • "A tiny edit broke the file." You probably mixed tabs and spaces, or misjudged the format — YAML in particular is indentation-sensitive. A .editorconfig keeps whitespace consistent so this stops happening.
  • "My change didn't take effect." Many services read their config only at startup, so reload or restart the service. Apple notes some files also require administrator privileges to change.

Be honest about the edges: for deep work inside a binary .plist, you may still want a dedicated tool. For the plain-text 90% — dotfiles, .gitignore, .editorconfig, YAML, JSON — a fast text editor is all you need.

Doing this with Carets

Config files and dotfiles are exactly what Carets is built to edit: plain text and code, on iPhone, iPad, and Mac. Because it's native and fast rather than a web wrapper, opening a dotfile to change one line doesn't mean waiting on a heavy IDE.

Three things help most here. Syntax highlighting for config and code files makes a stray brace or a broken indent easy to spot before you save. Plain text and code live in one editor, so a .gitignore, a YAML file, and a shell snippet all open the same way. And files, projects, and tags keep your dotfiles and snippets organized instead of scattered. Your files stay plain text the whole time — portable, and readable by any other tool later.

If your editing goes beyond config, the same habits carry over. The approach that helps you keep long Markdown documents navigable and the one behind a durable plain-text note-taking system both rely on the same fast, plain-text editing Carets is designed for.

Carets is available on the App Store for iPhone, iPad, and Mac.

Frequently Asked Questions

Why can't I see dotfiles like .gitignore in Finder?

macOS hides files whose names begin with a dot by default. Press Command-Shift-Period in a Finder window to toggle hidden files on, or open the file directly from a text editor that can browse hidden files. On iPhone and iPad the Files app shows dot-prefixed names inside folders you can reach, so an editor with a document picker can open them too.

What's the difference between .gitignore and the global ignore file?

A committed .gitignore lives in the repository and is shared with everyone who clones it — use it for build output and project artifacts. The global ignore file, registered with git config --global core.excludesfile, applies to every repository on your machine and is the right home for OS and editor cruft like .DS_Store or *.swp that no project should have to repeat.

Do I need to restart anything after editing a config file?

It depends on the program. Git re-reads its config on the next command, so changes to ~/.gitconfig take effect immediately. Many system services read their config only at startup, so you restart or reload the service after editing. Apple notes that some configuration files also require administrator privileges to change.

Will adding a file to .gitignore untrack a file Git already knows about?

No. Ignore rules only affect untracked files. If Git is already tracking the file, run git rm --cached <file> to stop tracking it, then add it to .gitignore and commit both changes.