So let us begin with the obvious: Back up your msdb database. Get a maintenance plan going, back it up regularly, and let us never lose our jobs or job history again.
This also leads to the second part of my answer which is: jobs and their steps are just rows in a table. They have steps which invoke subsystem commands using arguments provided in the job step row. The only way ultimately to "manage" the jobs is by managing the SQL that creates / modifies / deletes them. And because there's surprisingly little customization for a given job step, most people have just stuck to static SQL scripts for deployment.
Build your job in dev, test it, script it out to SQL, store it as a post-deployment file in your database project (your databases are in source control ... right?) and you've got the path of least resistance to SQL Agent job management.
Maybe someday in the future there will be ways to "compare" jobs in a project to a target server job a la Schema Compare - again, it's just SQL, shouldn't be too hard to reconcile - and then publish changes (even bidirectionally!) but for now you're just stuck with scripting.