I have not really thought about source control SQL Agent jobs with a VCS as such.
What we tend to do is to keep the SQL jobs very simple - a single step that calls a stored procedure in a database.
The jobs are prefixed with the database name so that one can easily see where they belong.
General jobs, like backups either don't have a prefix, but sometimes we do add something like 'General_' or 'Maintenance_'.
So most SQL job really lives in a stored procedure inside the database, which would by definition be the correct version.
Jobs are scripted to file for backup purposes with separate files for 'General' and database-specific jobs.
I am interested to see what other people are doing!
That would be the way that keeps logic out of the jobs if you can do it. If that's the case, then I think you're mostly OK from a VCS standpoint, except for scheduling. I'd consider that part of the job. Maybe include the code as a comment in the proc?