**Version Control**
Developed for managing software ==== 1. Track all *versions* of a project 1. You have one version 1. *Repository* has all versions 1. Use instead of numbered/dated files 1. Games: Used for code and art assets 1. Real game developers *DO* use version control 1. Even artists 1. You want to be able to say you know how to use it 1. *Help* manage multiple developers (*help*, not solve) Terminology ==== 1. *Repository* = (central) copy of entire version history 1. *Version* = everything you need from one point in time 1. Important that versions be *complete* 1. Also important that they not include *auto-generated* files * Introduces false changes, and potential conflicts 1. *Check out* = get a copy of a version 1. *Check in / commit* = submit your changes (with log message!) 1. *Ignore file / list* = Files never to check in 1. *Revert* = go back to version you checked out 1. *Branch* = several private versions of some feature 1. *Trunk / master* = main version 1. *Merge* = combine branches or combine yours with the repository version 1. Can handle non-overlapping changes to text files (e.g. code) 1. Tracks *3* versions: yours, theirs, and the common ancestor 1. Theirs isn't changed, yours is: take yours 1. Yours isn't changed, theirs is, take theirs 1. Both are changed, but the same, take either 1. Both are changed, but different....... 1. *Conflict* = differences the version control system cannot figure out on its own. 1. Can let you manually resolve overlapping changes 1. Barf on art assets (best you can do is pick one) 1. *Rebase* = Pretend you came from a different (usually newer) ancestor * Primarily used in *git* Version control I've used ==== 1. RCS 1. Individual file versions 1. You will never see this
1. CVS 1. Bundled file checkins, but still per-file versions 1. About a 1% chance you'll ever see this 1. Subversion/svn, TeamWare (sun/HP), ptools (SGI), Perforce/p4 1. Central repository, *atomic* checkins 1. Checkin process = update, merge, commit 1. Option to *lock* files: mostly used for art assets 1. Most game studios use perforce 1. git, Mercurial/hg 1. Distributed Version Control (DVCS) 1. Everyone has a local repository 1. Branching is supposed to be "easy" 1. Can check in changes locally (temporary branch) 1. Eventually have to merge with central repository 1. You do not want to merge art assets: 1. DVCS does not (yet?) handle art well 1. hg largefiles & lock extensions 1. Bitbucket does not support hg lock extension 1. Checkin process 1. git: fetch, merge, push * pull is shorthand for fetch/merge 1. hg: pull, merge, push * fetch is shorthand for pull/merge 1. Yes, fetch/pull swap is stupid and confusing 1. What I've learned 1. Your employer will define your VCS, deal with it 1. If you know how to check out, merge, and check in, they're all pretty similar Recommendations ==== 1. Use git/hg like a central repository, avoid branches 1. Avoids lots of conflicting changes to un-mergable files 1. Per artist development area (artdev) 1. Avoids majority of art merges 1. Could even be separate repository per artist 1. *But everyone should have access to all of these* 1. Only game assets checked in with game 1. Create a Google spreadsheet to track binary file use 1. Only let one person work on any non-code file at a time 1. Asset imports 1. Scene files 1. Per developer scenes 1. All per-artist or per-developer assets 1. OK to open 1. Don't save if you don't have the "lock" 1. Keep your ignore list up to date! 1. Open and run should not show any changes 1. If it does, remove the file from version control and add to ignore