I’ll speak only for Pharo because that’s the Smalltalk I am most familiar with (and the one I most highly recommend)…
Yes, the only way to run a Smalltalk program is to execute the image. Smalltalk is not suitable for creating shrinkwrapped retail applications. Like most programming languages, Smalltalk is not suitable for all conceivable purposes.
In most typical scenarios, this isn’t an issue. For proprietary in-house enterprise business applications, for example, this is totally a non-issue. For web server applications, this is totally a non-issue. For most research programs such as data science and machine learning, this is a non-issue. Even for web browser applications (using Amber or PharoJS), this is a non-issue.
Also, it is standard practice to deploy a Smalltalk program as a minimal image. You can do this either by pruning all unused classes, or build a production application starting with a minimal base image.
Code can be saved to disk: you “file out” your program. (The reverse is to “file in” the program.) This Smalltalk source code file can be saved to GitHub just like any other programming language. Your GitHub workflow shouldn’t change much.
Pharo has released Iceberg, a GitHub integration tool that makes this more convenient.
If you really want to use your own editor, you can. Pharo now makes it convenient. GNU Smalltalk has always been command line-based, if you really, truly wish to pass up on the tremendous productivity benefits of Smalltalk’s live coding IDE. That seems foolish to me, though.
You can write “native” Smalltalk applications in the same way you write native Java applications using JavaFX. You just don’t get the host platform’s normal look and feel. For the record, Dolphin Smalltalk gives you Windows’ look and feel but it’s a Windows-specific Smalltalk.
Your existing knowledge and skills should be in your ability to write software applications for any platform, for any problem domain, for any purpose…not in your use of specific editors, command line tools, programming languages, library APIs, etc. That’s how I managed my 20-year career in IT between 1980 and 2000.
Everytime I changed employers, I was exposed to a new software stack, and new tooling. I had to pick up knowledge on a new application domain. Adaptability is key to a software developer’s long-term career.