问题描述
所以很多时候在使用 git 时我都遵循这个过程：
- 克隆一个项目并执行它的设置。
- 设置/安装过程会创建新文件，这些新文件可能是特定于我的环境的配置文件（未被 gitignored）或在项目设置过程中修改现有的“核心”文件。这些更改/文件对于运行项目至关重要，但不应签入存储库，并且以这种方式进行了专门编码，因此不应签入这些更改/文件，因为它们可能很敏感。
- 我创建了一个名为 feature-newfeaturename 的分支，然后开始了我的功能开发。此时，步骤 2 中有几个未暂存的更改/文件，我会在此基础上进行工作。
现在，当我完成该功能的开发时，我只想签入我所做的更改，不包括文件。通常我会在第 2 步结束时执行 git diff > setup-changes.txt，然后在最后使用该文件作为参考。
当我完成我的功能开发时，我实际上是先执行 git checkout each-file-name-in-the-list，然后是 git add . 和 git commit，然后进行 PR——这样它只是 PRs in仅我更改。
这目前工作正常，但效率不高，我觉得可能有更好的方法吗？
另一个问题是，有时我的更改包括对核心文件的更改，这些更改与步骤 2 中所做的更改相冲突。因此，当我最后执行 git checkout 时，我的更改将被删除，因此我必须手动比较删除我所做的更改，使用原始核心（不包括设置更改）检查文件，然后手动使用差异查找并单独添加我的更改。
这又是违反直觉的，希望有一个更好的过程。有没有？如果是这样怎么办？
为了简化这个问题，让我举个例子：
- 有一个文件 main.txt，它只包含“apples”这个词，是主分支中“第一次提交”的一部分。
- 然后我执行
git checkout -b setup并添加 bananas，这是配置更改并执行提交。 - 然后我从 setup 分支执行
git checkout -b feature并添加 oranges 使文件包含苹果、香蕉和橙子。所以新功能是添加橙子。
现在我想要做的只是获取第一个和最后一个之间的差异，即我希望能够在我的最后一次提交中只有苹果和橙子，然后将其作为第二次提交推送到我的主分支。
解决方法
我支持@root 的建议（可能应该写成答案）。
话虽如此：
另一种方法是在第 2 步之后实际提交文件，作为您的功能分支的第一次提交，然后：
- 在开发分支的末尾使用
git revert <that commit>（这会在分支的历史记录中留下初始提交和还原） - 在推送您的分支之前使用
git rebase -i来“擦除”这个初始提交