E Exporting APEX should be done often if you are APEX developer. The more often you do it, the better position you will have. I export APEX every morning to see what other team mates changes (and forgot to commit). I also export it after each change. I modify the page, I export it. With this approach you need to export it fast. This is part of multiple ADT articles: Introduction & workflow Setup connections, config, folder structure Recompile invalid objects Searching APEX and searching repo for objects Export APEX & live upload (this article) Export database objects and data Patching & deployment Export APEX The full export is not always suitable. At least exporting just full export is something not version control friendly. And exporting just the pages is also not a great idea. That is usually done manually by teams who put everything on page, which goes against the Blueprint . You should not have logic (and queries) hardcoded on page
D Did you ever wondered which database objects are used in your application, in the whole application or just on a specific page? Or to find out where is the specific database object used? Or to find out at which commit was you database object dropped (or created, changed)? This is part of multiple ADT articles: Introduction & workflow Setup connections, config, folder structure Recompile invalid objects Searching APEX and searching repo for objects (this article) Export APEX & live upload Export database objects and data Patching & deployment Searching APEX The solution for searching APEX is based on parsing the Embedded code report export. So when you have this in your repo (and this is part of the next article on export_apex action), the searching is also faster then searching in APEX, it is also more accurate and the result list is much shorter, because it show just list of objects and pages as a table without all the clutter around.