5 ms·

This is what I do. Is there a "better" habit?

Hamuko 4y ago
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.
- kilroy123 4y ago
  Agreed. This is the only way I ever add anything.
muhbaasu 4y ago
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`.
- sgammon 4y ago
  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
- fgeiger 4y ago
  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
  - thefilmore 4y ago
    This is cool, wasn't aware of it.
  - j16sdiz 4y ago
    You can use `git add -i` to pick files to add interactivelly
- nyuszika7h 4y ago
  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.
- Merad 4y ago
  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.
  - gertlex 4y ago
    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.
  - mdtusz 4y ago
    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.
martopix 4y ago
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.
- formerly_proven 4y ago
  Just use git-gui
- throwawaylinux 4y ago
  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.
  - naavis 4y ago
    You could use `git add -p` It lets you stage individual changes inside files instead of the whole file.
    - throwawaylinux 4y ago
      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.
alex_smart 4y ago
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.
thefilmore 4y ago
`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.
rjmunro 4y ago
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
- zelphirkalt 4y ago
  Magit also makes this easy. One of the main features of magit, I think.
ekimekim 4y ago
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.
bloopernova 4y ago
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.
hibbelig 4y ago
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.
hibbelig 4y ago
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.

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.

kilroy123 4y ago
Agreed. This is the only way I ever add anything.

muhbaasu 4y ago

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`.

sgammon 4y ago
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
fgeiger 4y ago
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
- thefilmore 4y ago
  This is cool, wasn't aware of it.
- j16sdiz 4y ago
  You can use `git add -i` to pick files to add interactivelly
nyuszika7h 4y ago
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.
Merad 4y ago
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.
- gertlex 4y ago
  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.
- mdtusz 4y ago
  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.

martopix 4y ago

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.

formerly_proven 4y ago
Just use git-gui
throwawaylinux 4y ago
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.
- naavis 4y ago
  You could use `git add -p` It lets you stage individual changes inside files instead of the whole file.
  - throwawaylinux 4y ago
    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.

alex_smart 4y ago

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.

thefilmore 4y ago

`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.

rjmunro 4y ago

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

zelphirkalt 4y ago
Magit also makes this easy. One of the main features of magit, I think.

ekimekim 4y ago

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.

bloopernova 4y ago

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.

hibbelig 4y ago

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.

hibbelig 4y ago

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.