So you write something like
class Calculator
getSum(v1, v2) getProduct(v1, v2)
You don't have a use case for subtracting numbers. You expect this to be consumed by other teams, and it's plausible they will need to subtract.
Do you add getDifference() or do you view that as bad practice?
1. Does this add additional complexity? How much more time/effort would it take to implement the feature? And most importantly, how much added effort would it take to maintain the feature? (Would adding this feature become a burden later?)
2. Can we be sure that the feature, as we would implement it now with our limited information, will meet future requirements, or would we perhaps be implementing something one way only for it to turn out that it would have been better implemented another way once there's an actual, defined usecase for it? (Remember that once you add something to an API, it can be hard to change or remove it later.)
Most of my commits nowadays are very simple and small, and I try to stick to the immediate specifications because they may expanded in the future. In your example, what happens in the future if your boss says "the calculator may NEVER compute the difference of 2 numbers"? You will have useless code and/or harmful code that people will feel free to use but you may have to remove in the future. That's additional work for you.
Last but not least, putting too much unneeded new code may cause problems for others with merge conflicts if you use GitLab or GitHub. It happens all the time. Think about what you need, what you must do, and the problems you may cause later.