Every modification carries some risk. The more you modify = the more time you should spend validating and verifying your modifications. In this respect, ERPNext is no different than any other application.
It does not matter whether you modify the code:
- directly (i.e. forking and editing preexisting code files)
- indirectly (Customize, Client/Server Scripts, hooks.py, guerilla patching, etc).
Either way, some code is added/modified/deleted/skipped. To be safe, those changes should be reconciled with the new version’s code. Do they still work with the new version, or are errors now thrown? Even if there aren’t errors, are the modifications still doing whatever they were supposed to?
As always, Unit Tests and Integration Tests are a fantastic idea.
Here’s a post I made, somewhat related to this topic.
To my knowledge, the Bench commands work fine with private repositories. You just have to authenticate (e.g. Personal Access Token, SSH keys, etc)
I don’t use Frappe Docker, so cannot offer any advice there. Setting that aside, for a regular deployment, there is exactly one git repository per App:
- The ‘frappe’ App (
../apps/frappe/...) - The ‘erpnext’ App (
.../apps/frappe/...) - Apps you download or create yourself (
.../apps/foo/...)
When making file modifications, you can perform git ‘add’ and ‘commit’ commands. Just like you would for any other application using git.
Note however, some changes will not be written to files on disk. Certain changes made with the “Customize” button, and Client/Server scripts, are actually saved inside the MySQL database, inside columns. For those changes, git won’t see anything, because the code files haven’t changed.
Check out this post for more information about what 'bench update' does.
For VSCode, I create a single workspace file under ‘apps’. Then I configure the workspace to ignore certain files and directories (e.g. .git, node-modules, __pycache__, python virtual environment, etc.)