**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. *Version* = everything you need from one point in time 1. History of versions are often drawn like beads on a string 1. Important that versions be *complete* 1. Also important that they not include *auto-generated* files * Introduces false changes, and potential conflicts 1. *Repository* = (central) copy of entire version history 1. *Clone* = get a local copy of a repository 1. *Check out* = get a copy of one version 1. *Tag / Release* = Permenently label a specific version 1. *Check in / commit (verb)* = submit your changes (with log message!) 1. *Commit (noun) / Change List / CL* = set of changes in a version 1. *Revert* = go back to version you checked out 1. *Ignore file / list* = Files never to check in 1. *Branch* = sequence of private versions of some feature * *Trunk / master / main* = primary branch 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 the common change 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. Some allow *locking* art assets so only one person can edit 1. If not, should coordinate 1. *Rebase* = Pretend you came from a different (usually newer) ancestor * Primarily used in *git* Version control I've used ==== 1. RCS 1. Each file has its own version history 1. No connection between file histories 1. You will never see this 1. CVS 1. Bundled file checkins, but still per-file versions * Can get confusing if people check in at the same time 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. You just have files for a specific version 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 with history 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. git large file storage (LFS) & lock extensions 1. Github does support this, but mostly not git integration in Unity or UE5 1. Checkin process * git: fetch, merge, push * pull is shorthand for fetch/merge 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 Github === 1. Online site for hosting github repositories (see also bitbucket) * Github size limits 1. 100 MB single file limit, 5 GB repo limit 1. LFS: 1 GB size / 1 GB/month bandwidth (w/o paid plan) 1. New github terms (not part of git) 1. *Fork* = clone within github of someone else's repo * Can only have *one* fork of any repo per account 1. *Pull Request (PR)* 1. You can't push changes from your fork to the parent 1. You ask the parent repo's owner to pull those changes 1. Packaged up with file differences and way for them to annotate those & negotiate changes. Recommendations ==== 1. Use git like a central repository, avoid branches 1. Avoids lots of conflicting changes to un-mergable files 1. Per artist development repo (artdev) 1. Avoids majority of art merges 1. Avoids main repo size limits 1. *But everyone should have access to all of these* 1. Only game assets checked in with game 1. Track who is editing binary files (e.g. in a Google spreadsheet) 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 1. *Possible* to remove large unintended files from history retroactively 1. Dangerous repo operations if you get them wrong 1. Everyone else has to re-clone