Version control in OrCAD
So, Orcad files are, to my knowledge¹ not text files, but binaries. That makes it harder for typical source versioning software to track changes.
However, having a version history of your files is still better than having to manually make copies – as long as you know which files need tracking.
Git does all that – I'd recommend looking through section 1.3 (Basic Idea) and Chapter 2 (basic usage) of the Git Pro book (which is free). It applies to text files (e.g. source code) as much binary files, but of course, things like &quot;text diff&quot; doesn't make much sense in the latter case.
But just checking in the right files in git and committing every time you're done with a specific change will give you the ability to say &quot;hey, git, give me the state from last Monday&quot; or &quot;when did I add that feature?&quot;. The git commit log (i.e. the messages you enter when committing a state for saving in the index &quot;archive&quot;) is super handy (new users vastly underestimate that), just because it tells you what you did if you take the time to actually write descriptive messages.
Oh, and you should really track any specifications, and notes, and documentation along with your design files. You might change e.g. the pinout of a connector, and document that – and you want to make sure that you can get the version of documentation that matches your design. It'll make live infinitely easier once you've confused yourself (I'm an expert in that), and it costs nearly no time at all to do that.
Then, Orcad does have the concept of Signed-off Versions, which software engineers would call a &quot;Release&quot;. It's actually, especially for things that go into production, then get refined, a good idea to have some simple rules² around how to do that. I'd recommend something roughly equivalent to what  semantic versioning is for software:

Your versions have three components: X.Y.Z
Versions starting with 0 aren't meant to already be a &quot;useful&quot; state: 0.0.1 would be some version that you could e.g. send to your peers to discuss the basic idea
Whenever you have another Release (e.g. something sent to fab or to a commercial board review), you'd increase X, Y or Z.

Z is a patch change, like rotating a resistor for better assembly, fixing trace spacing etc, that doesn't affect the functionality of the board (i.e. how it works as seen from the user / devices it plugs into)
Y is a minor change, like swapping two pins on a connector; it changes the interface to the user or other devices and isn't a drop-in replacement for the prior version
Z is a major revision. Something changed fundamentally – that's often a subjective thing, but for example, adding a display might be a major change




¹ don't have orcad, sorry
² put them in a text file somewhere for your own reference in 2 years