docs: suggests instead of prescribes source control strategy

Prescribing source control strategies based on potentialities which themselves aren't best practice is offensive to competent developers.  Further, forcing each dev to create a file locally which can be committed wholly or as a template is massively inefficient. Consider Spring's application.properties file which also "may" contain secrets. It is common practice to commit such files to source control with placeholders for sensitive values instead of forcing the entire file to be created locally by each reviewer/contributor.

Author: JasonAndrewWakeman

articles/azure-functions/functions-develop-local.md

@@ -44,7 +44,7 @@ Other files in the project depend on your language and specific functions. For m
 The local.settings.json file stores app settings and settings used by local development tools. Settings in the local.settings.json file are used only when you're running your project locally. When you publish your project to Azure, be sure to also add any required settings to the app settings for the function app.
 
 > [!IMPORTANT]  
-> Because the local.settings.json may contain secrets, such as connection strings, you should never store it in a remote repository. Tools that support Functions provide ways to synchronize settings in the local.settings.json file with the [app settings](functions-how-to-use-azure-function-app-settings.md#settings) in the function app to which your project is deployed.
+> Because the local.settings.json may contain secrets, such as connection strings, you should take care if committing to source control. Tools that support Functions provide ways to synchronize settings in the local.settings.json file with the [app settings](functions-how-to-use-azure-function-app-settings.md#settings) in the function app to which your project is deployed.
 
 The local settings file has this structure: