Try `git add --patch` (or just `-p`). git will go through each change and you can decide if you want to stage it. You can even stage individual changes in a file.

This doesn't cover new files though. For those you can use `git add $filename` or even globs with `git add src/some/dir/*.$extension`.

For new files I use `git add -N` (if memory serves right; I am on mobile) to mark them as "I want this file to be included in `git add -p`"

Edit: The flag is -N or --intent-to-add

You can use `git add -i` to pick files to add interactivelly

This is cool, wasn't aware of it.

I use `git add -p` regularly, and it's one of my major pet peeves that it doesn't include new files. I constantly forget to include those in commits because of that.

came here to say this, git add -p is such a brilliant thing.

alias ga="clear ; git add -p" is an alias i always seem to keep

What type of workflow do you use where you regularly want to commit only some of your changes to a file? I honestly don't think I've ever had that need.

It's an extremely common and useful way to use git if you are making small and directed commits. This allows you to write code for some feature which includes multiple changes to a file, then make a few different commits with useful commit messages which describe and explain the changes - e.g. the first to include the definition of a new function and why/how it works, a second to modify some constant variable, and a final one to add calls to your new function at some callsite.

Working in this way creates more commits, but with them comes the context of the change, written in the commit message body as prose. This sadly isn't a common way to use git at lots of companies unfortunately, but it unlocks a ton of gits power and makes the commit log and tools like `git blame` and `git bisect` actually useful.

If you're making single commits that affect lots of files and descriptions like "Updated foo.py", you're missing out on a lot of the benefits that git provides.

While some might be more rigorous about working on a commit at a time, a couple other helpful bits are:

- Cleaning up print() calls and similar debug - It's a first-pass review of your own changes; re-read docstrings/comments, and easily go right back to them and update them etc. The diff view is different from the coding view and you gain insights, etc.

This might apply moreso to my often script-oriented coding that does 20 new things, rather than e.g. unit-test backed "formal" coding that does a few specific things.

My own workflow isn't quite at the "commit often" level of frequency, but instead I'm simultaneously crafting several related but separately-reviewable commits in one branch for one PR.

`git add -u` for changes to existing files, and manually `git add` new files. `git diff --staged` to review what's staged. You can use `git gui` to do all this using a GUI.

Yes, the moment you construct a commit by 'git add' is the moment you review the changes you made. Very often you will find results or configuration files get added without you realising it; or you added a breakpoint() that you shouldn't commit, etc. Second, for meaningful commit messages, the commit should include changes that are related to each other. In summary `git add --all` or `git add .` should be used only after a careful inspection of `git status` or `git diff` showed you indeed need all changes, and that they belong to the same commit message.

Logical changes aren't necessarily partitioned by file. Very often I find they are not. I might make a feature or fix or cleanup that is say 10 related changes that each affect some subset of say half a dozen files, often even the same code multiple times.

Adding individual files can help partition out some changes, but it's very rare for me, it's much more often I have to go back and manually shuffle sub-file changes around if I didn't get the splits right the first time.

You could use `git add -p`

It lets you stage individual changes inside files instead of the whole file.

Right, I can do those things and sometimes do. Similarly to per-file I generally don't need to because I try to write and commit a logical change at a time.

I have no problem with people who do it some other way, it just seems odd to hear people proclaim a particular way to work with git is wrong, because it does not match how they work. Not sure if it's because they can't imagine any other way of working, or they just think all other ways are also wrong.

Just use git-gui

Even if you don't want to go the whole "git add -p" route, at the very least:

1. Use "git add <filename>" manually for the files you want to add.

2. Do a "git status" and "git diff --cached" to review what you are about to commit before committing it.

I quite like my habit of adding stuff with `git add --patch` since it forces me to re-read stuff before I commit it. Graphical git clients like Fork or Sourcetree also allow to commit stuff in chunks.

Agreed. This is the only way I ever add anything.

What's also useful is to set "commit.verbose" to true; then you get the diff in your editor when composing the commit message. This allows reviewing the diff and you can abort the commit if it's wrong.

To add to sibling comments which describe various uses of `git add`, I'll also recommend `git commit -a`, which adds all changes from tracked files (but unlike `git add .`, not untracked files) before committing.

I use fzf in multi-select mode

    fza = "!git ls-files -m -o --exclude-standard | fzf -m --print0 | xargs -0 git add"

That lets you interactively choose which files to stage.

I've started using lazygit and/or tig, these present a UI in the terminal and easily allow staging files. Lazygit also easily allows staging parts of a file; not quite sure about tig.

git gui

Add hunks, write the message, add more hunks, write more message. Once you are happy commit it, close the window. Don't try to use the CLI only because you are a power user who only uses the command line.

If you really can't use the gui (like your on a remote SSH session or something), the non-gui equivalent is git add -p, write your message in another editor, then git commit -F message.txt

Magit also makes this easy. One of the main features of magit, I think.