You’re forgetting something – standard workflow with VSS is:

• checkout working copy
• (optionally complain others have some files locked)
• do work on files
• (optionally deal with complaints that you have files locked)
• checkin files.

What you need to understand is that while you can get a read-only copy, you cannot change files or commit changes unless you have a checkout which locks files so no-one else can modify them. So while your concept of working independently by migrating a working copy to git regularly is laudable, I doubt it’ll work in practice. You will have to perform a checkout (that locks files) at the last moment, merge these latest files from VSS into your git repo, and then checkin the resulting merge into VSS.If someone else is working on these files when you decide you want to merge, you’ll have to wait for them to finish. Also you’ll have to lock all the files, as you won’t (easily) know which have been changed since you took your last read-only copy.

Its better to organize the work you’re doing, or the files you’re working on, with your colleagues and just use the tool as it was intended. The important part of that is to communicate and organize the team’s development work rather than work independently like you want to do using git.

I’m going to answer, “don’t do this.” The workflows are quite different, and you’ll not have considered one and end up causing yourself, or worse your team, a lot of grief. Learn VSS, if nothing more than to make you appreciate other VCS more.

–UPDATE–

I have been using this bash script with a lot of success 🙂

Also I would now recommend 2 directories instead of 2 branches. It’s a lot cleaner 🙂

If you have the support of your VSS admin, then you can follow something like below.

Otherwise you can use git for your own branches and general workflow and use VSS as intended, but in that case I would recommend a clean separation, not the interop solution I have gone for. My solution is more suitable as a migration step but even then I would use with caution.

• Get working copy from VSS
• git init
• create a “vss_branch” branch
• branch a “dev” branch from master
• branch dev for each individual feature/bug
• on feature completion, rebase to clean up comments (if I have been naughty)
• merge into dev when features/bugs are ready
• test dev
• if all good merge dev into master
• Synchronize my master branch with VSS
  • switch to vss_branch
  • get working copy from Visual Source Safe
  • commit into vss_branch with “ss history” as comment
  • pull vss_branch onto master
  • test master
    Synchronise VSS with master
  • “ss checkout” files I have changed (don’t overwrite working copy)
  • “ss checkin” files I have changed (adding git comment as label)
• pull master into dev

I have attempted to stick to our VSS workflow but be a little more robust with the separate VSS git branch which I never push to.