Unity의 팀워크

버전 제어가없는 Unity 프로젝트가 있으며 다른 개발자와 공유하여 두 사람 모두 프로젝트를 수행 할 수 있습니다.

Unity Assets와 잘 어울리는 전략은 무엇입니까?

Unity has a built in facility for supporting version control properly.

Just go into the File->Project Settings->Editor and enable external version control.

I recommend using Git, it's free and the best around.

A while ago I wrote about version control (using Git) on my blog

Long story short:

Enable external version control File->Project Settings->Editor and create the .gitignore file in order to avoid unnecessary stuff on the repo (this is not really necessary, but it will be priceless during development).

Here's how the file should look like:

[Oo]bj/
[Tt]emp/
[Ll]ibrary

#These are files in the root folder of the project
*.tmproj
*.csproj
*.unityproj
*.sln
*.suo
*.user
*.pidb
*.userprefs

Unity 3.0 is configured to play nicely with subversion. (At-least nicer than before) I don't know if this is only in the pro version or not, I'll have to check.

In general though, the most recommend version control system is the Unity Asset Server.

Unity specific - work on different scenes and different code files at all times, and merge in the other person's changes manually. If you both need to be working on the same scene, duplicate it and use the copy as a test. Otherwise, if you both modify the same scene, one person's changes will overwrite the other. You can still use source control for your source files, just don't move them around at all, in the file system or via Unity, once they're created.

Beginner advice - get yourself a decent diff/merge tool (I like WinMerge) and get used to using it to see what changes the other person made, and to manually merge changes in conflicted files. Set up a central documentation space, eg. a Google writing document or a wiki, and keep your documentation there - documentation should contain a basic feature list at a minimum so you know what you're aiming for, and ideally a task list derived from the feature list, along with a clear indication of who is working on the task. Talk to each other to get a rough idea of who needs to work on which task and cross them off the list as they get done. Keep revisiting and re-evaluating the list to see if everything is still valid and if you need to rework any priorities.

I work with a team that calls itself Defective Studios. We've struggled with the same issue for years, and just recently I finally gave in and started writing an extension to help me merge gameobjects.

Basically the approach is to create an inspector-like interface in a window that lines up each gameobject, component, and property side-by-side for comparison, and provides buttons to copy values (or whole objects) from one side to another. If you're familiar with the SerializedProperty class, that's what is doing the bulk of the work here. We basically create a GUI that synchronizes the foldout state between the right and left side, and creates vertical space wherever a GameObject or Component exists on only the right or left side. A comparison function checks equality at each level, and turns the background of each line to red or green depending on the state of the equality. Any line whose children contain a difference will also become red, and we also included a nifty button to recursively search the tree and expand all objects that are different or have differences in their children.

As well, there is a set of mask fields that let you filter certain component types out of the comparison. GameObject attributes like name, layer, and tag are also compared. We use SerializedObject and SerializedProperty to loop through the gameObject's properties, and draw them just like they're drawn in the inspector. This ensures consistency, and is a heck of a lot easier to code!

One last nifty detail is that the comparison process (triggered when the objects are loaded and whenever a change is made) is run in an ad-hoc coroutine that is updated by the EditorWindow.Update function, so that in case you are comparing a hugely complicated object, the window doesn't lock up the editor. This was a must when comparing objects with hundreds (or thousand!) of children. All in all, it was kind of a "lego project" as my friend likes to say, but definitely an invaluable tool which instantly became a part of our collaboration workflow.

The tool, Unity Merge is documented on the Unify wiki, which includes a roadmap and an e-mail address for feedback and issue reporting. If you're really struggling with a complicated merge, give it a shot and let us know what you think! Also, I didn't bother to build it into a DLL, so feel free to poke around at the source. The ad-hoc coroutine implementation and SerializedProperty manipulations, as well as a few GUI tricks that I ended up needing are a great part of your editor extension toolkit. I'm very interested in changes/improvements that users might have, so please get in touch!

If you have the funds for it, the Asset server with the pro version of Unity is pretty decent. I have used it on a large, multi-person project in the past and it did the job. For vanilla version control, it did what we expected it to do.

I've tried using an SVN repository with a Unity project and it was a bit of a hassle. We ended up scrapping the idea before getting it to work, however. Unity keeps a lot of backup files that I didn't want to take the time to find out what would happen if they weren't synced to the server. I think, with a little finesse, it could be doable but I haven't had experience with it working well.

I have done a small project using the free features of DropBox. It made me nervous but we never had any issues. And, I don't think we ended up needing any real version control stuff for that project so I can't speak much to how reverting or merging files would have gone.

Dropbox supports versioning per file (rather than per commit) and plays nicely with Unity. It is free initially (2 gigabytes) and quite cheap thereafter (about $10 for 50gig). You need the PackRat addon to have access to version history.

Just like with SVN, CVS, GIT etc., you will need to make sure you create tag folders when you get to each key stage in development (eg. end of week, end of milestone). Unlike the aforementioned, it will be much harder to revert to such a stage if you don't, because you would have to revert every single file individually. Bear that in mind while developing and you'll have an easy time without paying for the Asset Server.