As mentioned above, the Recommended way of making changes is to create a custom App. This App’s code exists in its own directory. You can use Bench commands to download and install new Apps, remove them, etc. An App is essentially a bunch of files, in a directory that Frappe Framework knows about.
TL;DR - Stick with custom Apps unless you really know what you’re doing.
With that said, I will share more information with you…
Yes, ERPNext uses git for versioning. For the 2 main apps (Frappe, ERPNext), the .git files are located here:
- Frappe Framework: …/frappe-bench/apps/frappe/
- ERPNext: …/frappe-bench/apps/erp/
You can run
$ git status
in each directory, and view the repository info.
Because git is used for version control? Sure, you can certainly create your own Branches. Make changes. Push your code to your own fork on GitHub. Pull changes from that into a Production environment, etc. All the usual things.
Likewise, you could export certain SQL rows, the ones that contain scripts and reports. And later import those rows into another database, like your Production one.
That being said, most people won’t recommend you go down this road. Why not? Because maintaining ERPNext in this way requires a ton of work, experience, and skill. Yet ERPNext is meant to install and work for Everyone.
That is why there are tools like Bench. Bench provides a Command Line Interface (CLI) to tasks you commonly need to perform: git commands, backup commands, editing config files, starting services from a Procfile, applying patches, etc. Yet almost everything that Bench does could be done manually, from a normal shell. If you knew what to type.
So. If you’re already an experienced admin of Linux/Unix. If you have worked with other Python web frameworks, and are comfortable doing things manually? Then yes, you can deploy changes to Production like you would any other web application. Manage your own git branches. Take your own backups.
But…you’ll discover you are usually “on your own” when it comes to support. It’s very time consuming to troubleshoot and debug other people’s environments. If everyone on the forum did this?? We’d spent 24 hours/day troubleshooting other people’s stuff.
Which is why folks will recommend you stick to custom Apps, stick to Bench commands, and try not to break your ERPNext environment with custom code/data changes.