你不必硬重置（如果我理解正确的话）。
我的情况是类似的。我在一个正在运行的项目中添加了一个.gitattributes。我需要我拥有的文件和在线repo中的文件由gitattr来管理。

# This will force git to recheck and "reapply" gitattributes changes.
git rm --cached -r .
git add -A

你的提交将重新添加所有你提到的.ending文件，并且你不会丢失你可能已经做过的任何更改。当然，Bob将不得不拉取它。

irc://chat.freenode.net/#git上的osse为我提供了这个方法，它运行得相当好：

git rm -r :/ && git checkout HEAD -- :/

如果您的树中有未提交的更改，这将发出警告。
看来应该有更好的办法。

“would like this change to take effect”，你的意思是Alice希望她和Bob的工作副本都切换到Windows风格的行尾吗？那么第一个问题是，为什么Alice要对Bob的工作树中的内容负责？
如果新属性更好地描述了文件，那就这样吧; .gitattributes文件可以像任何其他文件一样进行编辑、测试和提交。
您建议的使新属性生效的过程没有多大意义，原因有二：
首先，为什么要擦除索引？文本属性会影响索引和工作副本之间的关系。在您的示例中，似乎需要更改的是工作副本，而不是索引。
第二，为什么要从索引中擦除 * 所有 * 内容？只有属性发生变化的路径需要处理。
因此，在您的示例中，如果Alice希望在本地反映新属性，最需要的是

rm myproj/src/file.ending
git checkout -- myproj/src/file.ending

因为这个过程不会覆盖.gitattributes文件，所以没有必要过早地提交它。
我不清楚Bob对您的原始过程不满意的确切原因，所以我不知道这个过程是否会让他更满意。虽然这不是不合理的期望，但我不确定这是否是git的工作方式。
问题是如何检测到更改。几乎在每一种情况下，如果git在合并或快进结束时更新工作树（例如完成一个pull），它只需要比较旧提交和新提交的索引对象的哈希值，就可以判断是否有更改要应用。
例外的情况是属性（或过滤器定义）发生了变化--如上所述，这并不会改变索引。但这些情况相对来说比较罕见，而且对它们的检查要比几乎每次都正确的哈希检查 * 昂贵得多 *，所以git允许当你知道你已经做了某些事情时，你必须采取额外的步骤，而不是用几乎毫无意义的成本来负担每一次比较。
因此，如果这种情况只会发生一次，那么就让团队进行沟通吧。“您可能需要刷新受影响文件的工作副本。”
如果这种情况会反复发生，我最好的建议是找出为什么这种情况不断发生并修复它。您可以尝试设置某种脚本自动化，甚至可以使用钩子来检测和处理属性更改;但它非常复杂，而且可能会造成比修复更多麻烦。

提交对.gitattributes的更改后，运行以下命令以应用更改

git rm --cached -r .
git reset --hard