如果你有一些不应该提交的文件，那你只能靠自己了，就像你为本地开发环境修改的变量已经是源代码管理的一部分。
如果您有一些文件不应该提交到存储库中，那么您需要将它们添加到.gitignore文件中。

• https://git-scm.com/docs/gitignore
• https://www.atlassian.com/git/tutorials/saving-changes/gitignore
• 示例：https://github.com/github/gitignore

在存储库的根目录下，创建一个名为.gitignore的文件，并添加要忽略的文件或文件夹模式。您的编辑器、VS代码或CLI应该显示这些文件不再更改。

# Logs
logs
*.log
npm-debug.log*
yarn-debug.log*
yarn-error.log*
lerna-debug.log*
.pnpm-debug.log*

# Dependency directories
node_modules/
jspm_packages/

提交这一个文件，对这些文件的更改将被 checkout repo的其他人忽略，当然，他们根本不会有这些文件，所以如果你有.env文件，每个人都需要控制environment variables，你应该包括一个像.env.EXAMPLE这样的文件，它带有占位符变量，让他们作为本地.env文件填充。

我有一些修改，但我不想提交，只是保持它在工作目录中，因为它是...有没有办法告诉Git这些修改是不提交，但让我知道，如果有任何其他的变化？

你需要拥抱暂时的承诺！

当你在分支上工作时，你绝对应该签入那些 * 临时的 * 修改，作为单独的，* 临时的 * 提交（并且提交消息要清楚地表明它们是临时的）。然而，当分支上的工作完成后，那些临时的提交可以被移除。
假设您所关心的更改是各种调试打印语句（使用printf、_logger.info、console.log或任何适当的日志记录机制），分布在多个文件中的各个位置。

• axios 1：在处理某个特性时添加这样的临时print语句是完全正常的。
• axios 2：不想用那些临时的打印语句来污染你的项目历史是好的。

但是不为这些临时更改创建提交是错误的，因为

• axios 3：处理这种 * 临时更改 * 的唯一明智方法是将它们作为 * 临时提交 * 签入git！

举个例子，假设你正在添加一些 foo 功能，修改了一些 bar，现在准备完成这项工作。你已经创建了几个临时提交（所有的开始和结束字符都是“====“1），所以要删除这些临时提交，你需要启动一个交互式的rebase，然后会看到下面的列表：

pick 10001 Started implementing foo
pick 10002 ==== debug foo ====
pick 10003 Finished implementing foo
pick 10004 Improved bar
pick 10005 ==== debug bar ====
pick 10006 ==== more foo debug ====
pick 10007 Removed unused baz
pick 10008 ==== more bar and foo debug ====

这是微不足道的削减到以下：

pick 10001 Started implementing foo
pick 10003 Finished implementing foo
pick 10004 Improved bar
pick 10007 Removed unused baz

其满足 axios 2。

如果你不经常重写git中的（本地）历史记录，那你就做错了。

如果你认为提交和分支是不可变的，那么你就错过了git的绝大多数好处。
将临时变更作为临时提交签入的好处有很多：

• 不存在阻止您切换到其他分支的未完成更改。
• 他们可以是精心挑选的。
• 它们可以重定基础。
• 它们可以通过git revert快速地暂时禁用。
• 它们可以通过交互式变基快速删除（例如，您不再需要foo调试消息，但希望保持bar调试）。
• 它们最终可以与其他人共享（他们只需要知道您的命名约定）。
• 没有git repo特定的配置。
• 例如，稍后运行git bisect时，您可以使用debug print语句。
• 它们与git log和gitk中的其他提交具有相同的可见性。

因此，你不需要“另一种索引”，事实上临时提交是并且应该被当作普通提交来对待。唯一的“特殊”处理是使提交消息足够不同，以使它们作为临时提交脱颖而出，并在最后通过交互式变基将它们过滤掉。

但是交互式变基过程中的冲突怎么办？

使用我的脚本git-resolve-conflict-using-kdiff3。KDiff3会自动解决在上面/下面的更改行旁边删除的行（如果需要手动解决冲突，KDiff 3也是一个很棒的工具）。
1你可以使用任何你想要的指示符，“====”只是一个建议，它只需要在交互式变基时在提交列表中清晰地显示出来。

该命令

git diff --cached --name-only

将列出您已暂存更改的文件的名称。如果使用$(...)（命令替换语法） Package ，则可以将名称列表扩展到shell命令行中。
如果您对这些文件进行了更多更改，并希望暂存这些更改，而无需担心其他文件是否已修改，则只需引用：

git add --patch $(git diff --cached --name-only)

由于这是一个拗口的词，可以为它定义一个函数：

staged()
{
  git diff --cached --name-only
}

git add --patch $(staged)

为了利用这个想法，你必须处理一次不想要的更改列表。你暂存将要提交的文件。在那之后，$(staged)只引用那些文件。例如，git status $(staged)只给你那些暂存文件的状态，git diff $(staged)只列出那些文件中未提交的差异。
不过，您必须一次将这些文件挑选出来;没有工具能读懂你的思想。
如果你的git仓库有一个问题，即构建系统不断修改受版本控制的文件，那么这可能是一个需要解决的问题;这些文件也许应该从版本控制中取出。
有时候，生成的文件需要签入版本控制。然而，大多数情况下，只有当有一种从头开始构建软件的方法时，才有意义，这样生成的文件才能被使用（不发生生成）。如果一个干净的构建总是生成文件，那么签入这些文件就没有意义了;他们只会是个讨厌鬼。

不，这是不可能的。
你可以使用git update-index --assume-unchanged [path]来忽略对文件的所有修改，但是如果你只想忽略一些修改而不想忽略其他的，Git不能这样做。