版本控制:从Gamedev角度有效使用,问题和想法（译文）

原文地址：https://www.codeproject.com/Articles/1137565/Version-control-Effective-use-issues-and-thoughts

原文作者：Ashley Davis

译文由本站 robot-v1.0 翻译

前言

In this article I’ll look at version control from the game developers perspective. I’ll help you understand the problems it solves and I’ll show you how to use version control more effectively. I expose the problems it can cause and discuss the unresolved problems for the games industry.

在本文中,我将从游戏开发人员的角度来看版本控制.我将帮助您了解其解决的问题,并向您展示如何更有效地使用版本控制.我揭露了它可能引起的问题,并讨论了游戏行业尚未解决的问题. 首次发表在<可能出错的地方>上.(First published at What Could Possibly Go Wrong.) 您应该使用版本控制吗？(Should you be using version control?) 我喜欢这张完美总结出来的图片:(I love this graphic that sums it up perfectly:)

图片来源(Image source) 因此,让我们谈谈版本控制.这是您必须使用的东西,对吗？当您使用代码时,尤其是在团队中,这是必需的.在大多数情况下,作为专业开发人员,当您加入软件公司时,您甚至别无选择,必须使用他们选择的版本控制系统才能为团队做出贡献.但是,我想说的是,即使对于业余或业余爱好者的开发人员来说,版本控制也是无价的.(So let’s talk about version control. It’s something you have to use, right? When you work with code, especially on a team, it’s a necessity. As a professional developer in most cases when you join a software company you won’t even have a choice, you must use their choice of version control system in order to contribute to the team. However I would say that even for an amateur or hobbyist developer that version control is invaluable.) 在本文中,我将讨论版本控制的好处.我将帮助您了解其解决的问题,并向您展示如何更有效地使用版本控制.我还将介绍它可能引起的问题.我将介绍游戏行业版本控制中尚未解决的问题.(In this article I’ll argue the benefits of version control. I’ll help you understand the problems it solves and I’ll show you how to use version control more effectively. I’ll also expose the problems it can cause. I’ll lay bare the unresolved problems with version control for the games industry.) 我将介绍我所使用的特定软件包.我自己的经验可以追溯到(I’ll cover the particular software packages that I have used. My own experience goes way back to) Microsoft Visual SourceSafe(Microsoft Visual SourceSafe) 在我的第一份编程工作中.推迟一个版本控制就足够了!但是从那时起,我就对两个(at my first programming job. It was almost enough to put one off version control! However since then I’ve battle-tested a number of other packages from both the)**传统模式(traditional model)**和更新的(and the newer)分布式模型(distributed model).他们都有自己的优点和缺点,没有一个是完美的.(. They all have their strengths and weaknesses and none are perfect.) 除了最简单的项目外,版本控制对于保持理智很重要.但是,还有很多痛苦和问题在等待着新手.(Version control is important for your sanity on anything more than the most simple projects. However there’s a world of pain and problems waiting for the uninitiated.) 此外,您还必须做出一个重要选择.我应该使用哪个版本控制系统？这个问题没有简单的答案,实际上没有正确的答案.您将不得不根据自己的需要接受某些东西.然后,您必须学会解决所采用系统的不足之处(或选择其他系统并接受其不足之处).(In addition there’s an important choice you have to make. Which version control system should I use? There’s no easy answer to that question, indeed there is no correct answer. You will have to accept something based on your needs. You must then learn to workaround the inadequacies of the system you have adopted (or choose a different system and accept its inadequacies instead).) 我可以帮助您了解您为什么(I can help you understand why you)**应该(should)**使用版本控制以及如何制作(use version control and how you can make)**更好(better)**使用它.您所使用的软件远不如您所使用的软件重要(use of it. Which software you use is far less important than the fact that you)**做(do)**使用版本控制!(use version control!)

内容(Contents)

目录(Table of Contents)

• 什么是版本控制？(What is version control?)
• 我是开发的新手,应该使用版本控制吗？(I’m new to development, should I use version control?)
• 我是一个人工作还是在一个小项目上,值得使用版本控制吗？(I’m working alone or on a small project, is it worth using version control?)
• 我应该说服队友使用吗？(Should I convince my team mates to use it?)
• 如果我不喜欢使用版本控制怎么办？(What if I don’t like using version control?)
• 我不是开发人员,应该使用版本控制吗？(I’m not a developer, should I use version control?)
• 为什么要使用版本控制？(Why use version control?)
• 传统还是分布式？(Traditional or distributed?)
• 版本控制和游戏开发(Version control and game development)
• 版本控制和Unity(Version control and Unity)
• 发布管理技术(Techniques for managing releases)
• 有效使用版本控制(Using version control effectively)
• 版本控制软件(Version Control Software)
• 观看软件(Software to watch)
• 版本控制的替代方法(Alternatives to version control)
• 我们在真实严肃游戏中使用的(What we use at Real Serious Games)
• 结论(Conclusion)
• 资源资源(Resources)

什么是版本控制？(What is version control?)

我需要解释什么是版本控制吗？也许不会.许多其他人已经对此进行了广泛的写作.(Do I need to explain what version control is? Maybe not. Many others have already written extensively on this.) 这是一个(Here’s a) 出色的视觉指南(great visual guide) 这将帮助您准确了解什么是版本控制.这是视觉指导(that will help you understand exactly what version control is. Here’s the visual guide to) 分布式版本控制(distributed version control) .(.) 这是(Here’s) 另一个很好的介绍(another good introduction) 解释了版本控制的概念.(that explains version control concepts.) 简而言之…版本控制可让您管理随着时间的变化.它最常用于跟踪对源代码的修订.对于游戏开发,我们还跟踪项目(例如Unity项目)和资产修订.这就像类固醇的撤消系统.犯了个错误？没问题,(Put briefly… version control allows you to manage changes over time. It is most commonly used to track revisions to source code. For game development we also track projects (eg Unity projects) and revisions to assets. It is like an undo system on steroids. Made a mistake? No problem,)**回滚(roll back)**到以前的版本或(to a previous revision or)**退出(backout)**令人讨厌的变化.(the offending change.) 更改有助于版本控制(Changes are contributed to a version control)**资料库(repository)**由一组开发人员.您随时可以获取整个存储库的当前状态,即所有更改的总和.这就是您用来构建当前游戏版本的方法.(by a team of developers. At any point you can get the current state of the entire repository, that’s the sum of all changes. That’s what you use to build the current version of your game.)

我是开发的新手,应该使用版本控制吗？(I’m new to development, should I use version control?)

也许.考虑到您最终需要学习它.(Maybe. Consider that you’ll need to learn it eventually.) 但是请注意,不要对学习过程感到不知所措.在学习版本控制之前,您应该集中精力于编写代码和制作游戏.(However be careful that you don’t get overwhelmed with the learning process. Before learning version control you should focus on being comfortable with writing code and making games.) 但是,如果您在团队中工作,那么他们可能会强制使用版本控制.或者您可能都认为值得一起学习版本控制,因为这仅仅是协调开发团队的最佳方法.(If you are working on a team however… then they might mandate the use of version control. Or you might all decide it’s worth learning version control together because it is simply the best way to coordinate a development team.)

我是一个人工作还是在一个小项目上,值得使用版本控制吗？(I’m working alone or on a small project, is it worth using version control?)

当然是.(Yes, definitely.) 我什至在小型实验或业余项目中也使用它.如果我在任何项目上花费的时间超过一个小时.我对它进行版本控制.只需几分钟即可在现有代码上建立存储库.如果项目很重要,或者我想与团队共享,那么我将其克隆并放在服务器上.这又需要几分钟.(I use it even on small experimental or hobby projects. If I spend more than, say, an hour on any project. I version control it. It only takes a few minutes to set up a repository on your existing code. If the project becomes important or I want to share with the team, then I clone it and put it on the server. This takes another few minutes.) 当然,项目和团队越大,您从版本控制中获得的收益就越多.小型项目非常适合学习新技术,例如版本控制.小型项目更易于管理,压力也较小.任何使用新技术的做法都不可避免地会导致错误,您必须为此计划并准备支付费用.当项目规模较小时,我们可以犯错,因为在这种情况下,更容易纠正.(Of course the bigger the project and the team the more you will get out of version control. Small projects are great for learning new technologies like version control. Small projects are easier to manage and there is less pressure. Any use of new tech will inevitably lead to mistakes and you must plan for that and be ready to pay the cost. When the project is small we can afford to make mistakes because in this situation they are easier to rectify.) 现代版本控制很容易开始使用.没有理由不使用它.(Modern version control is easy to start using. There’s no excuse not to use it.)

我应该说服队友使用吗？(Should I convince my team mates to use it?)

是.(Yes.) 也许会.如果您的团队反对使用版本控制,那么可能就不值得一战,在这种情况下,可以节省精力做更好的事情.更换团队甚至比改变团队更容易(Well, maybe. If your team is against using version control it might not be worth the battle, in that case save your energy for better things. It might even be easier to change your team than) 说服他们使用版本控制(to convince them to use version control) .(.) 如果您的队友不愿意,可能只是他们只需要经历协作发展的痛苦(If your team mates are reluctant it could be simply that they just need to experience the pain of collaborative development)**没有(without)**版本控制,然后才愿意尝试.(version control before they are willing to give it a go.) 教育是一个答案.如果您的团队成员了解版本控制的需求,他们将希望使用它.内化本文中提出的论点,并开始将它们转变为您的观点!(Education is one answer. If your team mates understand the need for version control they will want to use it. Internalize the arguments presented in this article and get to work swaying them to your point of view!)

如果我不喜欢使用版本控制怎么办？(What if I don’t like using version control?)

这很简单.只是不要使用它.(That’s an easy one. Just don’t use it.) 尽管也许您只是不喜欢尝试的第一个版本控制系统？好吧,尝试使用其他软件包,看看是否更喜欢您.您有选择的好处.(Although maybe you just don’t like the first version control system you tried? Well, try a different software package and see if that is more to you liking. You have the benefit of choice.) 也许您尝试了传统的版本控制系统,但是使用分布式系统会更好呢？或相反亦然.(Maybe you tried a traditional version control system, but you’d be better off with a distributed system? Or vice-versa.) 也许您还没有准备好使用版本控制.没关系.尝试使用Dropbox或USB记忆棒与队友共享代码.您很快就会了解为什么版本控制很有用.(Maybe you just aren’t ready to use version control. That’s ok. Trying using Dropbox or a USB stick to share your code with team mates. You’ll soon understand why version control is useful.)

我不是开发人员,应该使用版本控制吗？(I’m not a developer, should I use version control?)

是.也许会.(Yes. Well, maybe.) 您可以使用版本控制对各种事物进行版本控制.文本文件最有效,因为版本控制系统通常是为处理源代码而构建的.您也可以版本(You can version all sorts of things with version control. It’s most effective with text files, that’s because version control systems are usually built for working with source code. You can also version) 二进制文件(binary files) 例如艺术品资产,电子表格和文档,尽管这在某些系统中比其他系统更有效.这意味着您可以版本控制几乎可以想象的任何文件.(such as art assets, spreadsheets and documents, although this works better in some systems than others. This mean you can version control almost any file you can imagine.) 如果您需要跟踪和维护文件的版本,则版本控制非常适合您,您无需成为开发人员即可利用它.(If you need to track and maintain versions of files, version control is for you and you don’t need to be a developer to take advantage of it.) 作家肯定可以使用版本控制来跟踪其书籍的修订版本.整个业务模型都基于此,例如(Writers can definitely use version control to track revisions of their books. Whole business models are being based on this, for example) GitBook(GitBook) .(.) 数据分析人员还可以使用版本控制.看看(Data analysts can also make use of version control. Take a look at the) DAT包(DAT package) 用于表格数据.(for tabular data.)

为什么要使用版本控制？(Why use version control?)

每个人都有话要说(Everyone has something to say) 关于这个话题.这是我的版本控制可以为您做的清单…(on this topic. Here’s my list of what version control can do for you…) 启用安全的工作流程(Enables a safe workflow) 以较小且易于测试的增量提交代码.如果有任何提交导致问题…可以很容易地将其撤消.(Commit code in small and easily testable increments. If any commit causes a problem… it can easily be backed out.) 无需担心即可进行实验(Enables experimentation without fear) 实验或(Experiment or) 重构(refactor) 不工作了吗？只需将进行中的工作还原为干净副本即可.(not working for out? Simply revert your work in progress back to a clean copy.) 严重弄乱了本地存储库？只需将其删除,然后从主存储库中克隆一个新副本即可.(Messed up your local repository badly? Just delete it and clone a fresh copy from your master repository.) 回滚到以前的版本(Rollback to a previous version) 版本控制允许回滚.那就是恢复代码的旧版本.这就是为什么我称它为(Version control allows rollback. That is the recovery of old versions of your code. That’s why I call it an)类固醇的撤消系统(undo system on steroids).(.) 当前版本是否有讨厌的错误？恢复该代码的以前的工作版本.(Does the current version have a nasty bug? Recover a previously working version of the code.) 您是否删除了一些现在需要的代码？恢复已删除代码的副本.(Did you delete some code that you now need? Recover a copy of the deleted code.) 表现地狱？查找性能良好的先前版本,这将帮助您了解导致问题的原因.(Performance gone to hell? Find a previous version with good performance and that will help you understand what caused the problem.) 需要重建以前的工作版本吗？假设您要更改和重建2个月前制作的PAX演示.使用版本控制及时退后,进行所需的更改并重新构建演示.(Need to reconstruct a previous working version? Say you want to change and rebuild the PAX demo that you made 2 months ago. Step back in time using version control, make the changes you need and rebuild the demo.) 隔离有问题的修订(Isolate a problematic revision) 使用版本控制,您可以(Using version control you can)**搜索(search)**通过以前的修订来查找引入问题的要点.这很有帮助,因为查找问题的根源通常占工作量的90%.(through previous revision to find the point where an issue was introduced. This is helpful as finding the source of the problem is often 90% of the work.) 管理多个版本(Manage multiple versions) 使用分支,分支或标记来维护产品的多个版本.当您需要并行进行多个开发流且彼此不干扰时,此功能很有用.例如,许多开发人员至少保持了良好的测试(Use branches, forks or tagging to maintain multiple versions of a product. Useful when you need to have multiple streams of development progressing in parallel and not interfering with each other. For example many developers maintain at least a well tested)**生产版本(production version)**和正在进行的工作(and a work in progress)**开发版本(development version)**他们的代码.(of their code.) 协调团队合作(Coordinate teamwork) 在开发团队中工作时,版本控制可防止出现绝对混乱.它使协作工作成为可能.手动共享和合并代码既耗时又容易出错.如果您要通过Dropbox或类似的替代方法共享协作项目,那么您将面临灾难.(Version control prevents absolute chaos when working in a development team. It enables collaborative work. Manually sharing and merging code is time-consuming and error-prone. If you are sharing a collaborative project via Dropbox or an similar alternative then you are flirting with disaster.) 了解项目的历史(Understand a project’s history) 版本控制使您能够了解项目的历史记录以及发生了什么.您可以查看谁创建了文件以及谁最后编辑了文件.实际上,您可以看到完整的编辑历史记录,以及自时间开始以来每个文件发生了什么(至少就存储库而言).(Version control allows you to understand the history of a project and what has happened. You can see who created a file and who last edited it. In fact you can see the complete history of edits, what has happened to each file since the beginning of time (as far as the repository is concerned, at least).) 版本控制允许审核代码库的历史记录.(Version control allows the history of a code-base to be audited.) 后备(Backup) 所有PC都不可避免地死掉.当您的PC死机时,它会带走您惊人的项目吗？(All PCs inevitably die. When your PC dies will it take your amazing project with it?) 使用版本控制意味着(Using version control means that)**至少(at minimum)**您应该在服务器上拥有项目的主版本.如果您的PC死了,那么您只会丢失尚未集成到服务器的最新工作.(you should have a master version of your project on the server. If your PC dies then you’ll only lose your most recent work that hasn’t yet been integrated to the server.) 如果服务器死了怎么办？那么,您要么需要服务器的自动备份.或者您应该考虑使用(What if your server dies? Well you either need an automated backup of your server. Or you should consider using a)分布式版本控制系统(distributed version control system)(DVCS)在哪里((DVCS) where)**克隆(cloning)**备份驱动器的存储库很简单.(the repository to a backup drive is trivial.) 实现持续集成和持续交付(Enables continuous-integration and continuous-delivery) 虽然不是本文的重点,(Whilst not a focus of this article,) 持续集成(continuous-integration) (CI)和((CI) and) 连续交付(continuous-delivery) (CD)是扩大开发团队并自动进行构建,测试和部署的非常重要的技术.版本控制是这些高级技术的关键推动因素.((CD) are very important techniques for scaling up a development team and automating builds, testing and deployment. Version control is a crucial enabler for these advanced techniques.)

传统还是分布式？(Traditional or distributed?)

在本节中,我将介绍两种不同的版本控制模型.这是对概念的介绍,后面列出了每个优点/缺点的简明清单.(In this section I introduce the two different models of version control. This is an introduction to the concepts followed by a concise list of the pros/cons of each as I see it.) 有关更多信息,Atlassian有一个(For more on this, Atlassian have a) 模型的不错比较(nice comparison of the models) 具有大量的视觉效果和图表.(with lots of visuals and diagrams.)

传统版本控制(Traditional version control)

传统的版本控制系统依赖中央服务器.在此模型中,多个客户端与共享服务器通信以提交更改并使用修订历史记录.客户拥有所谓的(Traditional version control systems rely upon a centralized server. In this model multiple clients talk to a shared server to commit changes and work with the revision history. Clients have what is known as a)工作副本(working copy),这是所有文件的副本,其中累积了最新的更改.对工作副本的更改将直接提交到共享服务器.每当客户提交更改时,该更改将立即对所有其他客户可用.(, that’s a copy of all the files with the accumulation of changes to date. Changes to the working copy are committed directly to the shared server. Whenever a client commits a change, that change is immediately available to all other clients.)

优点(Pros)

• 客户端-服务器模型很容易理解,因为诸如FTP之类的客户端-服务器程序已经存在很长时间了.(The client-server model is easy for people to understand as client-server programs, such as FTP, have been around for a long time.)
• 它在传统的办公环境中效果很好.在专用LAN上一起工作的人们都可以方便地访问服务器.(It works well in a traditional office environment. People working together on a private LAN where all have convenient access to a server.)
• 该软件是成熟且强大的.(The software is mature and robust.)
• 只有一台服务器,因此很容易记住代码的时间,尽管如果使用很多分支仍然会失控.(There’s only a single server, so it’s easy to remember when your code is, although it can still get out of hand if you use a lot of branches.)
• 在大多数软件中,可以锁定文件进行编辑.这有助于防止多个人编辑二进制文件.(In most software it is possible to lock files for editing. This helps to prevents multiple people from editing binary files.)
• 存储库可以部分同步.当您需要获取存储库的一部分而不是整个存储库时,这很有用.(Repositories can be partially synchronized. This is useful when you need to get a part of a repository, instead of the entire respository.)

缺点(Cons)

• 传统模型不适用于分布式团队,远程工作者和外包团队.这是因为您必须依赖对服务器的访问才能使用它.良好的互联网可以缓解此问题.(The traditional model less adequate for distributed teams, remote workers and outsourced teams. This is because you are dependent on access to the server in order to be able to use it. Good internet mitigates this problem.)
• 这是不灵活的.很难复制存储库.确保您可以创建尽可能多的(It is inflexible. It is difficult to make copies of the repository. Sure you can create as many)**工作副本(working copies)**根据您的需要,但是很难对存储库进行完整的复制,包括历史记录.从存储库到存储库的合并也是不可能的(至少不容易或没有其他工具).(as you need, but making a complete copy of the repository including the history is difficult. It’s also not possible to merge from repository to repository (at least not easily or without additional tools).)
• 如果您使用传统的存储库来容纳多个项目,它将随着时间的流逝而增长.最终,它将变得肿且笨拙.您可能必须存档旧项目,因此与管理传统版本控制相关的维护成本更高.(If you use a traditional repository to house multiple projects it will grow and grow as time goes on. Eventually it will become bloated and unwieldy. You may have to archive old projects, so there is a larger maintenance cost associated with administering traditional version control.)

分布式模型(The distributed model)

版本控制的分布式模型是点对点系统,而不是传统模型的客户端-服务器方法.分布式网络中的每个节点不是完整的服务器,而是完整的存储库.用户对其进行更改(The distributed model of version control is a peer-to-peer system instead of the client-server approach of the traditional model. Rather than a centralized server, each node in the distributed network is a full repository. Users make changes in their)**工作副本(working copy)**然后将这些更改提交给他们(and then commit those changes to their)本地仓库(local repository).然后可以交换更改((. Changes can then be exchanged ()**推(pushed)**要么(or)拉(pulled))与其他存储库.() with other repositories.) 分布式版本控制绝对适合使用代码,但是目前所有分布式系统都存在二进制资产和大型项目的问题(尽管(Distributed version control is absolutely fantastic for working with code, however all distributed systems currently have problems with binary assets and very large projects (although) Facebook正在为Mercurial开展这项工作(Facebook are working on this for Mercurial) ).().) 有一些东西(There has been something of a) Mercurial和Git之间的竞争(competition between Mercurial and Git) .就个人而言,我更喜欢Mercurial,但我也通常使用Git进行开源工作.(. Personally I prefer Mercurial, but I also commonly use Git for open-source work.)

优点(Pros)

• 对于分布式团队,远程工作者和外包团队非常有效.(Very effective for distributed teams, remote workers and outsourced teams.)
• 分布式系统可脱机工作,非常适合旅行时使用.喜欢在咖啡厅工作吗？做到这一点,在离线状态下增加提交,与您的同步(Distributed systems are built to work offline and great for when you are travelling. Like working in a cafe? Do it, bank up commits while you are offline, synchronize with your)**主(master)**回到办公室后回购.(repo when you are back in the office.)
• 这很容易(It is very easy to)叉子(fork)(要么((or)克隆(clone))回购.这使备份和归档变得容易.它使您可以轻松地处理代码库的多个并行副本.() a repo. This makes backup and archiving easy. It makes it easy to work with multiple side-by-side copies of your code-base.)
• 如果发生灾难(例如服务器崩溃),丢失回购的风险要小得多.在团队成员之间可能会分布有许多存储库克隆,因此丢失存储库要困难得多.使用传统的集中式系统,如果丢失了中央存储库,则会丢失所有项目的历史记录.(There is much less risk of losing a repo in the event of a disaster such as server melt-down. There will likely be many clones of a repository distributed among team members so it’s much more difficult to lose your repository. With a traditional centralized system, if you lose your central repository you lose the history of all your projects.)
• 从技术上讲,不需要服务器,尽管为方便起见,您很可能将特定PC上的特定存储库指定为(Technically no server is necessary, although for convenience you will most-likely designate a particular repository on a particular PC as the)**主(master)**回购.(repo.)
• 使工作流程变得非常灵活.您可以轻松地模仿传统结构(Makes for a very flexible workflow. You can easily emulate the traditional structure with a)**主(master)**回购和多重(repo and multiple)**客户(client)**仓库,但是您不限于此布局.(repos, however you aren’t limited to this layout.)
• 主要的分布式系统是开源和免费的.(The main distributed systems are open source and free.)
• 无需在编辑前检出,它就能为您解决(实际上SVN也可以这样做,尽管烦人的Perforce却没有).(No need to check out before editing, it figures it out for you (actually SVN does this as well, although annoyingly Perforce doesn’t).)
• 很容易(Very easy to)**忽视(ignore)**文件(公平地说,SVN也允许这样做,但是在Git和Mercurial中,(files (to be fair SVN also allows this, however in both Git and Mercurial the)**忽视(ignore)**设置存储在一个简单的版本控制的文本文件中).(setup is stored in a simple version controlled text file).)

缺点(Cons)

• 该模型很难让人理解,也很难解释.甚至有些编码人员也难以理解该概念,请尝试向技术水平较低的人解释!(The model is difficult for people to understand and it is hard to explain. Even some coders have trouble understanding the concept, try explaining it to someone less technical!)
• 对二进制文件的支持很糟糕!他们不擅长处理二进制资产,尤其是大型二进制资产.我注意到有(The support for binary files is woeful! They are not great at dealing with binary assets, especially large binary assets. I’ve noticed there are)**大文件扩展名(large file extensions)**但我还没有尝试过(but I haven’t tried these.)
• 在处理大型项目时不太好(我说的是千兆字节的项目大小).(Not so great at dealing with large projects (I’m talking about gigabyte project sizes).)
• 随着项目规模的增加,性能往往会下降.(Performance tends to degrade as project size increases.)
• 您可能最终会有许多存储库,尤其是如果您快速浏览项目时(就像我们在Real Heavy Games中所做的那样).这可能变得难以管理.记住哪些项目包含哪些内容可能很棘手.好的流程和文档可以在某种程度上解决这一问题.(You might end up with many repositories, especially if you churn through projects quickly (as we do at Real Serious Games). This can become difficult to manage. It can be tricky to remember which projects contains what. This can be handled somewhat with good process and documentation.)
• 分布式版本控制不允许部分同步.您不能仅同步项目的一部分,而必须同步整个项目.当您了解分布式系统的本质时,这很有意义,但是如果您来自传统模型,则可能会失去仅同步非常大型存储库的一部分的功能.这是使您的分布式存储库小巧轻便的一个很好的理由.(Distributed version control doesn’t allow partial syncing. You can’t sync just part of a project, you must sync the whole project. This makes a lot of sense when you understand the nature of the distributed system, but if you come from the traditional model you might miss the ability to sync only a portion of a very large repository. This is a good reason to keep your distributed repos small and lightweight.)

版本控制和游戏开发(Version control and game development)

游戏具有独特的问题,可以解决普通软件开发项目不必处理的问题.作为游戏开发人员,您对版本控制工具集有一些不同的要求.(Games have unique problems to solve that normal software development projects don’t have to deal with. As a game developer you have some different requirements from your version control toolset.)

学科与团队(Disciplines and teams)

首先,除编码人员外,其他人也从事游戏.根据需要,游戏团队可以将构建游戏所需的各个学科的人员结合在一起.编码人员在使用版本控制时通常会遇到一些麻烦(经过一些经验).但是其他学科(艺术家,设计师,生产者,质量保证等)可能会发现这些工具非常复杂且不堪重负,尤其是在涉及(To start… people other than coders also work on games. By necessity game teams combine individuals from the disciplines that are required to construct a game. Coders often have little trouble using version control (after some experience). However the other disciplines (artists, designers, producers, QA, etc) can find these tools complicated and overwhelming, especially when it comes to) 合并(merging) (有些编码员甚至觉得有些困难).((something many coders even find difficult).) 良好的培训,教育和对持续改进的承诺可以帮助更广泛的团队成功进行版本控制.如果您是编码人员,则可以通过创建脚本和工具来帮助您,这些脚本和工具可以使版本控制更易于其他团队成员使用,尽管资源很少的小型工作室可能很难做到这一点.至少应始终提供编码人员以帮助团队成员解决版本控制问题.(Good training, education and a commitment to continuous improvement can help the wider team be successful with version control. If you are a coder you can help by creating scripts and tools that make version control easier to use for the other team members, although small studios with precious little resource may struggle to achieve this. At a minimum coders should always be available to help team members through version control issues.) 游戏团队的规模和结构多种多样.最小的团队只有1或2人.最大的团队可以有数百人协作.版本控制系统通常可以很好地扩展到大型团队.有许多(Game teams come in many sizes and structures. The smallest teams have 1 or 2 people. The largest teams can have 100s of people collaborating. Version control systems generally scale well to large teams. There are many)**巨大(huge)**软件开发公司使用数以千计的编码器使用版本控制.大型团队至少是解决版本控制的问题.(software development companies with 1000s of coders using version control. Large teams are at least a solved problem for version control.)

二元资产(Binary assets)

普通的软件开发项目主要是版本控制代码(例如,文本文件).游戏通常同时包含文本和二进制资产.这里有代码,配置文件和其他各种文本资产.然后是二进制资源,例如网格,纹理和级别/场景.(Normal software development projects mostly version control code (eg text files). Games usually have a mix of both text and binary assets. There’s code, configuration files and various other text assets. Then there are binary assets such as meshes, textures and levels/scenes.) 大多数版本控制系统旨在处理源代码,并真正与游戏开发中常见的大量二进制资产作斗争.特别是,分布式版本控制系统确实在二进制资产和大型项目中遇到困难.事情正在发生变化,例如(Most version control systems were designed to handle source code and really struggle with the massive binary assets that are common in game development. In particular the distributed version control system really struggle with binary assets and large projects. Things are changing though, for instance) Facebook现在正在使用和改进Mercurial(Facebook are now using and improving Mercurial) 他们庞大的代码库.(for their huge code-base.) 版本控制的主要功能是能够合并由多个程序员同时编辑的源代码.不幸的是,这对于二进制资产根本不起作用!这些不能通过版本控制合并,这会造成一个可怕的过程瓶颈,在此过程中,一个人一次只能处理一个二进制资产.让多个人处理二进制资产会导致一种情况,即一个人(如果不是更多的话)必须失去他们已经完成的工作.(A key feature of version control is the ability to merge source code that has been simultaneously edited by multiple programmers. Unfortunately this doesn’t work at all for binary assets! These are not mergeable through version control, this creates a horrible process bottleneck where only one person can work on a binary asset at a time. To have multiple people working on a binary assets causes situations where one person (if not more) must lose the work they have done.) 一些版本控制系统允许资产被锁定,这是可接受的(即使不是很好)的解决方案.这样可以确保只有一个人可以一次编辑二进制资产,并且没有人会失去工作.当然,这仅在传统系统中是可能的,分布式系统的本质阻止了锁定.当然,您可以制作一个插件或其他方法来滚动您自己的锁定系统,但这是一项繁重的工作,使您无法真正制作游戏.(Some version control systems allow assets to be locked and this is an acceptable, if not great, answer to this problem. This ensures that only a single person can edit a binary asset at a time and no one is at risk of losing their work. Of course this is only possibly in traditional systems, the very nature of the distributed systems prevents locking. Of course you could make a plugin or some other method to roll your own locking system, but that’s busy work that takes you away from actually making games.) 如果由于选择版本控制系统而无法锁定二进制文件,则必须找到另一种方法来处理此问题.(If you are unable to lock binary files due to your choice of version control system you must find another way of dealing with this issue.)

流程和工作流程(Process and workflow)

您绝对应该做的一件事就是努力使您的工作模块化,从而更轻松地在团队中分配任务而不会引起冲突.当我们制作代码模块时,编码人员已经做到了.我们将代码逐个文件拆分.然后,一个开发人员可以处理一个文件,另一位开发人员可以处理另一个文件,并且只要开发人员正在处理单独的文件,就不需要合并.我们创建的模块越分离,开发人员就越有可能在不互相干扰的情况下工作,并且合并冲突的风险最小化.在某种程度上,这种方法也可以与资产一起使用…网格,纹理和场景都可以分为模块(并在运行时加载/流式传输),这意味着艺术家和设计师在他们所需的资产中重叠的可能性较小编辑.(One thing you should definitely do is strive to modularize your work to make it easier to distribute tasks among the team without causing conflicts. Coders do this already when we make code modules. We split the code up file by file. One developer can then work on one file, another developer can work on a different file, and there will be no merges needed so long as the developers are working on separate files. The more separate modules we create the more likely it is that developers can work without interfering with each other and the risk of merge conflicts is minimized. To some extend this approach can also be taken with assets… Meshes, textures and scenes can all be divided up into modules (and loaded/streamed at runtime) meaning there is less chance that artists and designers will overlap in the assets they need to edit.) 解决此问题的另一种方法是拥有流程或工作流程.很多人使用我喜欢打电话的系统(Another way to deal with this problem is to have a process or work-flow. Many people use a system I like to call)**谁拥有资产？(who has the asset?)**在这个系统中,一个人一次可以索取(In this system one person at a time can claim)**所有权(ownership)**资产.在那个时候,只有那个单身人士被允许编辑资产.仅当团队遵循流程中定义的规则时才强制执行此系统,这意味着团队必须受到足够的纪律约束以遵守规则.每个团队成员必须了解其他人当前正在使用哪些资产,并且必须尊重自己,使其无法处理其他人当前主张的资产.如果您都在同一个房间里,这并不是特别困难,只需在工作时向团队提出即可!或者,可以将其写在白板上以跟踪谁拥有什么.对于分布式团队中的人员,您可以通过在线交流来实现,例如(of the asset. In that time only that single person is allowed to edit the asset. This system is enforced only when the team follows the rules defined in the process, by this I mean that the team must be disciplined enough to stick to the rules. Each team member must understand what assets the others are currently working with and must respectfully restrain themselves from working on assets that are currently claimed by others. If you are all in the same room this isn’t particularly difficult, just call it out to the team as you work! Or maybe write it up on a whiteboard to keep track of who has what. For those in distributed teams you can achieve this via online communication, something like) 松弛(Slack) 会成功的(will do the trick.) 您可能有理由思考(You might justifiably be thinking)**多么可怕的过程(what a horrible process)**要么(or)游戏行业如何做到这一点(how did the games industry get to this point).是的,这很疯狂,远非理想的情况.不幸的是,有时由于我们的处境,团队或技术选择,我们只能采取这样的策略,而我们仍然需要完成工作,并且还需保持一些理智!(. Yes this is crazy-far from an ideal situation. Unfortunately sometimes we we are reduced to tactics like this because of our situation, team or choice of technology and we still need to get the job done with some shreds of sanity remaining!)

发布管理(Release management)

对于游戏开发人员而言,另一个有趣的问题是,与通常的软件开发相比,我们通常更快地完成项目.软件项目通常会持续多年.另一方面,游戏可以很快结束,最小的游戏可以在几个月内创建.手机游戏与改进技术相结合的趋势意味着,游戏的构建速度比以往任何时候都要快.这就引出了一个问题,即项目完成后我们该怎么办？我们需要退休该项目并将其存档,但是如果以后可以再次访问该项目以供参考或为另一个项目提取代码和资产将是一个很好的选择.正如我们很快将看到的那样,某些版本控制系统比其他版本处理系统能够更好地处理这种事情.(Another interesting problem for game developers is that we often go through projects more quickly than normal software development. Software projects often last for many years. Games on the other hand can be over quickly, the smallest games are created in a matter of months. The trend of mobile games combined with improved technology means that games are being built more quickly than ever before. This begs the question what do we do when the project has finished? We need to retire the project and archive it, although it would be good if we could access the project again later for reference or to pull out code and assets for a different project. As we’ll soon see some version control systems handle this sort of thing better than others.) 像传统软件项目一样,游戏通常需要管理和维护多个发行版.在某个时候,您将需要(Games, like traditional software projects, often need to manage and maintain multiple releases. At some point you will need)**发展(development)**和(and)**生产(production)**代码版本.通常,游戏还具有并行开发的多个版本.例如,发布一个(versions of the code. Often, games also have multiple versions being developed in parallel. For example it’s not uncommon to have released an) α(alpha) 建立您要反馈,更新和重新发布的信息.同时,其他团队成员正在分别努力(build that you are taking feedback on, updating and re-releasing. At the same time other team members are separately working towards the) 贝塔(beta) 版.然后有一个人不得不分叉(version. Then there’s that one person who had to fork the)**α(alpha)**发布并整理原型演示以在(release and hackup a prototype demo to show at)百富(PAX).(.) 你明白我的意思.我们需要一个项目的多个版本,每个版本都有多个人员参与.项目的每个单独的版本都不能互相干扰.别呼吸,还有更多.您最终还需要将所有项目中的更改合并到一个主版本中.例如,您将修复了(You see what I mean. We need multiple versions of a project with multiple people contributing to each version. Each separate version of the project can’t interfere with each other. Don’t take a breath yet, there’s more. You also eventually need to consolidate the changes from all projects into a single master version. For example you’ll have fixed some bugs in the)**α(alpha)**您需要带入的版本(version that you need to bring forward into the)**贝塔(beta)**版.如果您不熟悉开发,可能听起来像一场噩梦.好吧,可以.但是我所描述的这些情况只能通过版本控制来实现.看起来似乎仍然很混乱并且很难跟踪正在发生的事情以及谁在做什么,但是通过版本控制,您可以管理和控制混乱并朝着明智的方向进行指导.您可以使用的工具是(version. If you are new to development this might sound like a complete nightmare. Well it can be. But these situations that I am describing are only made possible with version control. It may still seem chaotic and hard to keep track of what is happening and who is doing what, but with version control you have a means to manage and control the chaos and guide it in a sensible direction. The tools you have at your disposal are)分枝(branching),(,)**分叉(forking)**和(and)标记(tagging).分布式版本控制系统(. Distributed version control systems)**擅长(excel)**在管理多个版本.(at managing multiple versions.)

版本控制和Unity(Version control and Unity)

团结有(Unity has) Perforce和Plastic SCM的集成(integrations for Perforce and Plastic SCM) .如果您使用Perforce或Plastic,这些可以使您的生活更轻松.不幸的是,Subversion,Mercurial或Git没有内置集成.这些插件的代码是开源的,(. These can make your life easier if you are working with either Perforce or Plastic. Unfortunately there is no built-in integration for Subversion, Mercurial or Git. The code for these plugins is open-source and) 你可以在Bitbucket上找到它(you can find it on Bitbucket) .如果您在代码中查看,您会看到有对SVN的支持!但是,SVN尚未包含在Unity中.如果您在资产商店中搜索,您会发现支持Mercurial和Git的各种软件包,尽管我并不是真的认为有必要,但我个人认为Mercurial和Git可以很好地与Unity一起使用,而无需插件.(. If you look in the code you can see there is support for SVN! However SVN hasn’t yet been included with Unity. If you search on the asset store you will find various packages that support Mercurial and Git, although I don’t really think it’s necessary, personally I think Mercurial and Git work pretty well with Unity without needing a plugin.) 如果您不使用Unity的版本控制插件,则应设置(If you aren’t using Unity’s version control plugins then you should set)**版本控制模式(Version Control Mode)**至(to)可见的元文件(Visible Meta Files) 如Unity手册中所述(as mentioned in the Unity manual) .(.)

如果可能的话,我也喜欢设置(Where possible I also like setting)**资产序列化模式(Asset Serialization Mode)**至(to)强制文字(Force Text).这导致资产(如项目设置,元文件和场景)存储为文本文件.这是有争议的,但是这样做的好处是,在提交资产(例如通常以二进制形式存储且因此不可扩散的场景)之类的资产时能够查看差异.这可以帮助您了解Unity资产的结构.不幸的是,此设置不能很好地适应大型项目,并且可能导致Asset Store中的第三方包装出现问题.在这种情况下,您应该将其设置为(. This causes assets like project settings, meta files and scenes to be stored as text files. This is arguable, but the benefit of this is being able to view differences when committing assets like scenes that normally are stored as binary and are hence not diffable. This can help you understand the structure of Unity assets. Unfortunately this setting doesn’t scale very well to very large projects and can cause problems with 3rd party packages from the Asset Store. In these cases you should set it to)**混合的(Mixed)**用于大型项目.(for large projects.)**强制文字(Force Text)**对小型项目最有用,尤其是在您学习Unity数据格式时.(is most useful for small projects, especially when you are learning about Unity data formats.)

问题(Issues)

编辑场景和其他二进制资产(Editing scenes and other binary assets) 编辑Unity场景和其他二进制资产是一个巨大的过程瓶颈.通常只有一个(Editing Unity scenes and other binary assets is a massive process bottleneck. Normally only a)**单(single)**艺术家或设计师可以同时处理这些文件.(artist or designer can work on these files at the same time.) 使用(Using)强制文字(Force Text)(前面提到)可以提供帮助.这会将您的场景文件存储为文本文件,因此可以合并它们,尽管合并非常容易并且((mentioned earlier) can help. This will store your scene files as text files so it becomes possible to merge them, although merging is rarely easy and)**强制文字(Force Text)**对于大型项目可能并不可行.如果您的版本控制系统支持(may not be feasible for large projects. If your version control system supports)**文件锁定(file locking)**那么这将有助于对Unity场景和二进制资产进行单用户编辑.(then this will help enforce single user editing of Unity scenes and binary assets.) 甚至其他方面,成熟的开发人员也可以通过此问题而屈服.事实是,只有一个团队成员才能一次在一个场景上工作.我相信这是Unity应该解决的唯一最大问题.(Even otherwise sophisticated developers can be bought to their knees by this issue. The fact is that only a single team member can work on a scene at one time. I believe this is the single biggest problem that Unity should be fixing.) 模块化可以提供帮助.分解大型场景,并在运行时使用流合并它们. Unity 5.3的新功能(Modularization can help. Break up large scenes and use streaming to merge them at runtime. Unity 5.3’s new) 场景管理器(SceneManager) 可以帮助您.(can help with this.) 同步时不要alt标签(Don’t alt-tab while syncing) 从版本控制同步Unity项目时,请注意不要(When you are syncing a Unity project from version control be careful you don’t) alt标签(alt-tab) 切换回Unity.如果在同步过程中执行此操作,可能会发生不良情况.想象一下这种情况:正在进行同步,您的资产和场景已经更新,尽管尚未更新您的(to switch back to Unity. If you do this while the sync is in progress bad things can happen. Imagine this situation: the sync is in progress, your assets and scenes have been updated, although it hasn’t yet updated your)**元(meta)**文件.您可以按Alt键重新回到Unity.然后,Unity认为您有一堆没有元文件的资产.因此,它会生成元文件.同时,版本控制同步将继续并继续获取元文件,但是由于它是保守的并且不希望覆盖Unity刚生成的元文件,因此它不会获取元文件.现在,您打开场景,发现脚本和预制件的链接已断开!(files. You alt-tab back to Unity. Unity then thinks you have a bunch of assets without meta files. So it generates meta files. Meanwhile the version control sync continues and proceeds getting the meta files, however it doesn’t get the meta files because it’s conservative and doesn’t want to overwrite the meta files that were just generated by Unity. Now you open your scene and discover that links to scripts and prefabs are broken!) 这不仅是人为的情况,我已经看到它多次发生.问题随着存储库大小的增长而变得越大,同步存储库所需的时间越长,触发此行为的机会就越大.(This isn’t just a contrived case, I have seen it happen on multiple occasions. The problem grows larger with repository size, the longer it takes to sync a repository the more chance you have of triggering this behavior.)

发布管理技术(Techniques for managing releases)

分支,标签和派生是管理发布的三种不同技术.选择哪种取决于您的需求以及您喜欢的工作方式.(Branches, tags and forks are three different techniques to manage your releases. Which you choose depends on your needs and what you are comfortable working with.)

分行(Branches)

可以将分支视为存储库的内部克隆.(A branch can be thought of as an internal clone of a repository.) 处理仓库时,您将选择要使用的分支.如果您尚未创建任何分支,那么您将自动使用(When you are working on a repo you will choose which branch to work with. If you haven’t created any branches then you are automatically working with the)默认分支(default branch).您可以随时在现有分支的基础上创建新分支,然后根据在任何给定时间需要处理的内容在分支之间进行切换.(. At any time you can create a new branch based on an existing branch, then you change between branches depending on what you need to work on at any given time.) 开发人员出于各种原因分支他们的代码.通常,为特定版本创建一个分支,这使您可以维护与生产代码分开的存储库的开发版本.(Developers branch their code for all sorts of reasons. Commonly a branch is created for a particular release, and this allows you to maintain a development version of the repository that is separate to your production code.) 我也知道团队(I’ve also known teams to) 功能分支(branch for features) (他们先在单独的分支中实现一项功能,然后再对其进行测试,然后将其合并回((they implement a feature in a separate branch before testing it and then merging it back to the) 树干(trunk) ).您还可以按任务,团队和个人进行分支.(). You can also branch by task, team and individual.) Jeff Atwood对(Jeff Atwood has a good overview of) 分支和分支策略(branching and branching strategies) .(.)

标签(Tags)

标签允许您标记特定的修订.这是将修订版本与特定版本或里程碑相关联的好方法.例如,一旦完成(Tags allow you to label a particular revision. This can be a great way of associating a revision with a particular releases or milestone. For example once you finish the)**PAX演示(PAX Demo)**您可以使用该名称标记修订.这样做,您便可以在修订历史记录中标识代码版本.(you could label the revision with that name. Do this and you have a way to identify code releases in your revision history.) 标签比分支更易于使用,但功能却不如分支.例如,如果您想返回并进行编辑(Tags are simpler to work with than branches but they aren’t as powerful. For example if you wanted to go back and edit)**PAX演示(PAX Demo)**并重新发布该代码,您会发现使用标记实现此操作很棘手,并且可能会导致您的修订历史记录混乱.(and re-release that code you will find that achieving this with tags is tricky and will likely cause a mess in your revision history.)

前叉(Forks)

**分叉(Forking)**要么(or)**克隆(cloning)**您的存储库是分支的替代方法.(your repository is an alternative to branching.) 如果分支是存储库的内部副本,则分支是外部复制:完全独立的存储库.分叉的存储库与原始存储库相关,并且代码更改可以轻松地在它们之间合并.您可以用分支做的任何事情,也可以通过分叉来做.您可以为开发和生产创建单独的存储库,也可以为功能,任务和个人创建单独的存储库.(Where a branch is an internal copy of a repository, a fork is an external copy: a completely separate repository. A forked repository is related to the original repository and code changes can easily be merged between them. Anything you can do with branching you can also do by forking. You can fork separate repositories for development and production, you can fork separate repositories for features, tasks and individuals.) 分支比分支更灵活.分支存储库后,它将保留在存储库中并对其大小做出贡献(膨胀存储库).存储库的分支在外部存在,这使得在不再需要它们时更容易安全地处理它们.如果发现自己创建的是短暂的分支或许多分支,则可能需要考虑使用派生.(Forking can be more flexible than branching. Once you have branched your repository it remains in your repository and contributes to its size (bloating the repository). Forks of a repository exist externally and this makes it easier to safely dispose of them when they are no longer needed. If you find yourself creating short-lived or many branches you might want to consider using forks instead.) 分支比分支更容易理解.毕竟,分支只是存储库的另一个副本.您可以在文件系统中看到它.您在文件系统中看不到分支,分支仅通过版本控制系统提供的工具存在.(Forks can be easier to understand than branching. After all a fork is simply another copy of the repository. You can see it in your file system. You can’t see a branch in your file system, branches only exist through the tools provided by your version control system.)

使用哪个？(Which to use?)

我主张采取平衡的方法.(I advocate a balanced approach.) 存储库之间的长期存在且高度耦合的关系应表示为分支.(Long lived and highly coupled relationships between repositories should be represented as branches.)**发展历程(Development)**和(and)**生产(production)**分支就是一个很好的例子.(branches are a good example.) 存储库之间的短暂关系应该是fork.例如你的(Short-lived relationships between repositories should be forks. For example your)**PAX演示(PAX Demo)**将在几周内结束.您可能需要将代码分成几部分,因此您想分支.我认为在这里分叉是一个更好的选择,因为您将要在一个月左右的时间内退休.退出分支比分支要容易得多,因为可以轻松地从文件系统中删除分支(或将其归档到其他文件夹).(will be over in a matter of weeks. You may need to hack your code to bits, so you’d like to branch. I think forking is a better option here because you will want to retire the repository in a month or so. It’s much easier to retire a fork than a branch as a fork can easily be deleted from the file system (or archived to some other folder).) 如果存储库之间有许多关系,则还应考虑分叉.例如,在"真正的严肃游戏"中,我们分叉(When you have many relationships between repositories you should also consider forking. For example at Real Serious Games we fork)**代码发布(code releases)**定期(每3-6个月)(at regular intervals (every 3-6 months) from our)开发资料库(development repository).我们将代码发布编号从(. We number the code releases starting with)版本1(release 1).我们现在要(. We are now up to)发行22(release 22).我们喜欢保留这些旧代码版本,因为我们可以存档旧代码并在客户返回给我们并要求新功能时轻松地将其恢复.对于我们来说,拥有22个分支膨胀我们的主存储库是不可行的.(. We like to keep these old code releases because we can archive old code and easily revive it should a client come back to us and ask for new features. For us having 22 branches bloating our master repository would not be feasible.)

有效使用版本控制(Using version control effectively)

这里展示的是我的技巧和最佳实践.这些将帮助您更有效地使用版本控制.(Presented here is a my grab-bag of techniques and best practices. These will help you be more effective at using version control.) 请记住,一个人的最佳实践是另一个人的不良实践.随盐服用此建议.我尝试了所有这些策略,发现它们在大多数情况下都可以很好地工作.规则和过程需要灵活.软件开发业务非常复杂,我们需要灵活性.如果可以,请遵循最佳做法,如果不能,则将其丢弃,否则请按照自己的意愿进行调整.(Just remember, one person’s best practice is another’s worst practice. Take this advice with a grain of salt. I have tried all these tactics and found them to work well in most circumstances. Rules and process need to be flexible though. The software development business is complex and we need flexibility. Follow best practices when you can, throw them out when then you can’t or otherwise adapt them as you see fit.)

训练(Training)

确保每个人都受过有关如何使用版本控制的教育.如果您的团队中有人比您更了解它,请他们教您.如果您比队友了解得更多,请教他们.教育和培训有助于解决人们在版本控制方面遇到的许多问题.(Make sure everyone is educated on how to use version control. If there is someone on your team who understands it better than you do, have them teach you. If you understand it better than your teammate, teach them. Education and training help solve many of the problems that people have with version control.)

版本控制所有内容…除了可以安装或生成的任何内容(Version control everything… except anything that can be installed or generated)

版本控制您不能失去的任何原始作品.源代码,配置文件,测试脚本,源资产.(Version control any original work that you can’t afford to lose. Source code, configuration files, test scripts, source assets.) 不要提交设置或构建过程可能生成的文件!(Don’t commit files that can be generated by a setup or build process!) 您应该具有一个项目安装脚本,该脚本可以安装第三方软件包和依赖项.您还需要一个构建脚本,该脚本会处理一切工作,以便从源代码和资产创建构建.有了这两件事,新开发人员就可以更轻松地开始一个项目.这也意味着安装和生成的文件不必包含在版本控制中.在版本控制中包含这些文件会使您的存储库过大,并使复制和同步速度变慢.(You should have a project setup script that installs 3rd party packages and dependencies. You also need a build script that takes care of everything to create a build from source code and assets. Having these two things makes it much easier for new developers to get started with a project. It also means that installed and generated files don’t have to be included in your version control. Including those sort of files in version control bloats out your repository and makes it slow to copy and synchronize.)

代码审查(Code review)

我们的过程与版本控制进行交互的地方为我们提供了一些自然的地方,可以进行代码审查.(Where our process interacts with version control provides us with some natural points at which to conduct code review.) 在提交之前,您应该进行(Prior to committing you should conduct) 自我审查(self-review) 要么(or) 同行评审(peer-review) .自我审查类似于同行审查,只是您正在审查自己的代码,但是您应该假装自己正在审查别人的代码!这样可以更轻松地发现代码中的错误.(. Self-review is similar to peer-review, only you are reviewing your own code, however you should pretend you are reviewing someone else’s code! That makes it easier to spot the errors in your code.) 使用分支的用户可以在接受代码到分支之前执行代码审查.例如,当您将代码合并到您的(Those using branches can perform code review prior to accepting code into a branch. For example as you merge code into your)**发布候选(release candidate)**分支,您可以查看它.或者当您将代码合并到您的(branch you can review it. Or as you merge code into your)**生产(production)**分支机构,您可以在代码进入公众手中之前进行最终代码检查.(branch you can do final code checks before the code gets into the hands of the public.) 如果您使用的是分布式版本控制,则当您推送到主存储库时,您还有另一个机会进行审查.这是确保您不会向队友发送错误代码的另一次机会.(If you are using distributed version control you have another opportunity to review… when you push to the master repository. This is another chance to ensure that you aren’t pushing bad code to your team mates.) Github有一个很棒的系统,可以进行远程代码审查.当您准备将更改集成回主存储库时,您将提交一个(Github has a great system that enables remote code review. When you are ready to integrate your changes back to the master repository you submit a) 拉取请求(pull-request) .其他人应该查看拉取请求并将其合并到主请求中.如果在审阅过程中出现任何问题,审阅者可以使用查询和应解决的问题来注释拉取请求.(. Someone else should review the pull-request and merge it into the master. If any issues come up during the review the reviewer can annotate the pull-request with queries and issues that should be addressed.)

在提交之前进行测试,不要破坏构建!(Test before you commit, don’t break the build!)

确保你有(Make sure you have) 测试了您的代码(tested your code) 进行版本控制之前,请先进行彻底检查.(thoroughly before you commit to version control.) 测试和代码审查有助于防止问题进入主存储库.这是查找和修复缺陷的最便宜的时间.随着代码和功能深入开发流程并进入我们的参与者的手中,缺陷的查找和修复变得越来越困难,代价也越来越昂贵.(Testing and code-review helps prevent issues getting into the master repository. This is the cheapest time at which to find and fix defects. As code and features go further along the pipeline and into the hands of our players, defects become progressively more difficult and expensive to find and fix.)

同步时要小心(Be careful when you synchronize)

请注意,构建可能随时会被破坏!(Be aware that at any time the build could be broken!) 代码审查,自动化测试,持续集成和尽责的开发人员都可以帮助最大程度地减少损坏的构建的发生,但是确实会发生人为错误,有时还会出现问题!(Code reviews, automated tests, continuous integration and conscientious developers can all help minimize the occurrence of broken builds, but human error does happen and sometimes problems can slip through!) 与他人的工作同步时,请准备停止正常工作并解决问题.有时您会因为构建损坏而被阻止.发生这种情况时,只需跳入并修复它即可.在修复构建后,保存回顾以供以后使用.(When you synchronize with the work of others be ready to stop normal work and fix problems. There will be times when you are become blocked because the build is broken. When this happens, just jump in and get it fixed. Save the retrospective for later, after the build is fixed.) 发生错误.请注意,同步时可能会将问题合并到本地存储库中.在最适合您的时间执行此操作!然后准备处理出现的任何问题,以便您继续工作.(Mistakes happen. Be aware that when you synchronize you are potentially merging problems into your local repository. Do this at a time that best suits you! Then be prepared to deal with any problems that arise so you can get on with your job.)

提交讯息(Commit messages)

你的(Your) 提交消息(commit messages) 是一种沟通形式.您正在向队友甚至您的消息发送消息(are a form of communication. You are sending a message to your team mates or even to your) 未来自我(future self) !对你的同事好.对未来的自己好一点.确保您的提交消息有意义.(! Be nice to your colleagues. Be nice to your future self. Make sure that your commit messages are meaningful.) 与(As with) 代码注释(code comments) ,对于提交消息而言,最重要的事情是解释代码更改的意图.说明原因而不是方法.与您的代码注释不应仅解释您从阅读代码中可以轻松看到的内容相同,您的提交注释也不应仅通过检查变更集来说明您可以轻松阅读的内容.比解释代码的工作原理更重要的是…解释如此变化背后的思想比这么多编码人员似乎失败的多.解释为什么需要更改以及它带来了什么价值.(, the most important thing for commit messages is explaining the intent of the code change. Explain the why rather than the how. In the same way that your code comments shouldn’t just explain what you can easily see from reading the code, your commit comments shouldn’t just explain what you can easily read by examining the changeset. More important than explaining how the code works… and so many coders seem to fail at this… is to explain the thinking behind the change. Explain why the change was needed and what value it it adds.) 更改是否修复了错误？解释该错误,并解释该更改如何修复该错误.(Does the change fix a bug? Explain the bug and explain how the change fixes the bug.) 在某个时候,也许当您试图确定何时添加了特定的错误时,您将不得不回头查看旧的代码修订版.发生这种情况时,您会为编写有意义的提交消息感到高兴.(At some point, maybe when you are trying to figure when a particular bug was added, you will have to go back and look at an old code revision. When that happens you will be very happy that you wrote meaningful commit messages.) 您还应该将提交消息与您的流程和系统相关联.如果要通过任务跟踪系统完成任务,请确保在提交消息中包含任务编号.同样的错误.修复错误后,在提交消息中包含错误号.(You should also relate commit messages to your process and systems. If you are completing a task from your task tracking system, be sure to include the task number in your commit message. Same for bugs. When you fix a bug include the bug number in your commit message.)

这是你的日记(It’s your diary)

我喜欢将版本控制视为我的日记.(I like to think of version control as my diary.) 忘了你上周做什么？忘了你昨天在做什么？查看您的版本控制历史记录.(Forgot what you did last week? Forgot what you were doing yesterday? Have a look at your version control history.) 当我编写提交消息时,我将其写为日记条目一样,以备他人阅读.用提交消息讲述一个完整的故事.如果您可以想象别人会如何阅读该故事,那么您将撰写一个更好的故事.(When I write commit messages I write them like they are journal entries, ready for someone else to read. Tell a complete story with your commit messages. If you can imagine how someone else will read that story, you will write a better story.)

进行少量频繁的提交(Make small frequent commits)

使(Make) 小承诺(small commits) ,让他们经常.(, make them frequently.) 小提交更容易测试,因为测试更少.它们更易于代码审查,并且可以更快地发现问题.许多小的和经过测试的代码更改加在一起,使代码更加稳定.这极大地降低了未知问题堆积的风险,并在以后让您感到惊讶.一旦有了繁琐的工作流程,频繁地进行小而可靠的提交,您的工作就会迅速累加起来.一切都将在最后完成!在需要进行重要构建之前,发现棘手的问题是最糟糕的事情.(Small commits are easier to test because there is less to test. They are easier to code review and issues will be spotted more quickly. Many small and well-tested code changes adds up to vastly more stable code. This massively reduces the risk that unknown issues will build up and take you by surprise later. Once you have a humming workflow making frequent small and reliable commits your work will quickly add up to big things. And it will all be working at the end! It’s the worst thing discovering nasty issues right before you need to do an important build.) 大型提交可能隐藏许多问题.更糟糕的是,这些问题可能会纠结在一起,从而加剧了问题.从本质上讲,小型提交几乎没有潜伏的问题,这些问题更容易发现.问题将更少,因此不会将它们纠结在一起,这又使它们更容易发现和放松.(Large commits can hide many issues. What’s worse is that those issues can be tangled up together which serves to amplify the problems. Small commits, by their nature, will have few lurking issues and those issues will be easier to detect. There will be less issues and because of this they won’t be tangled up together, this again makes them easier to spot and unwind.) 每个提交都应该做一件事,应该是一个逻辑单元,并且所有代码更改都应该相关.你听说过(Each commit should do one thing, it should be a logical unit and all code changes should be related. Have you heard of the) 单一责任原则(single responsibility principle) ？提交代码时,我们应该针对类似的目标.作为提交一部分的所有更改应彼此高度相关.您绝对应该分开提交,以进行行为更改,重构和性能优化.当问题组合在一起时(因为您将它们合并成一个大型提交),由它们引起的问题将更加难以处理.(? We should aim for something similar when committing code. All changes that are a part of a commit should be highly related to each other. You should definitely separate your commits for behavior changes, refactors and performance optimization. When problems are combined (because you combined them in a large commit) the problems they cause will be more difficult to deal with.) 如果要修复错误.确保修复是一个提交.(If you are fixing a bug. Make sure the fix is one commit on it’s own.) 如果要添加功能,只需提交该功能.不要尝试偷偷进行不必要的重构和格式更改.实际上,许多功能实际上需要多次提交,尽管通常不难将大型功能分解为多个逻辑单元.(If you are adding a feature, just commit that feature. Don’t try and sneak in unnecessary refactoring and formatting changes. Many features will actually require multiple commits, usually though it is not difficult to decompose a large feature into multiple logical units.) 如果您在进行小的提交时遇到麻烦,可能是因为您没有有效地计划工作.应当计划并执行一系列小的但相关的提交来执行复杂的更改.如果您还不熟悉开发,甚至可能没有意识到它的需求,这可能会很困难.努力提高计划技巧,练习将工作分解为较小的内容,然后随着实践的发展而提高.简洁的提交是技能和经验的标志.(If you have trouble making small commits it may be because you aren’t planning your work effectively. Complex changes should be planned out and executed in a series of small but related commits. This can be difficult if you are still new to development and you may not have even been aware of the need for it. Work on improving your planning skills, practice deconstructing your work into smaller commits, you’ll improve with practice. Small concise commits are a mark of skill and experience.) 与所有此类指南一样,不要走太远!不要仅仅因为您希望它看起来像在进行小型提交就分解大型提交!不要仅仅为了适应过程而人为地进行小的提交.我见过经验不足的编码人员,他们准备进行大量提交…然后将其分成多个小的提交,以便他们满意(As with all such guidelines, don’t take this too far! Don’t break up a large commit just because you want it to look like you are making small commits! Don’t make small commits happen artificially just to fit the process. I’ve seen less experienced coders with massive commits ready to go… then divide it up into small commits so that they satisfy)过程(the process).这只是将大提交隐藏为一堆小提交,并不能真正解决任何问题.总是有一些小的提交最终很难独自解释或被破坏.在进行代码审查时,请查找这些警告警报.(. This is just hiding a big commit as a bunch of small commits and doesn’t really solve anything. Invariably some of the small commits end up being difficult to explain on their own or just broken. Look for these warning alarms when doing code reviews.) 如果您需要进行大型提交,则只需执行即可.有时我们不得不做出较大的承诺,尽管通常我们不希望这样做.当您必须执行此操作时,请留出一些时间进行反思.问自己,是否有另一种方式可以使大更改变成一系列较小的提交？自我反思对于我们成长并变得更有经验非常重要.(If you need to do a large commit, then just do it. Sometimes we have to make large commits, although generally we should prefer not to. When you must do this, set aside some time for reflection. Ask yourself was there another way that the big change could have been a series of smaller commits? Self reflection is very important for us to grow and become more experienced.)

经常推(Push frequently)

这是对(This an extension to) 进行少量频繁的提交(make small frequent commits) 对于那些使用分布式版本控制的用户.(for those that use distributed version control.) 经常推送到您的主存储库.尽可能每天推送.您等待的时间越长,将您的工作与团队进行集成,合并就越困难,并且您破坏构建的可能性就越大.(Push frequently to your master repository. Push every day where possible. The longer you wait to integrate your work with the team the more difficult merging will become and the more likely it will be that you will break the build.) 长时间不推送代码会增加计算机崩溃和丢失工作的风险.这种情况并不经常发生,但是可以并且确实发生.这将在您的编程生涯中的某个时候发生.您将失去多少工作？经常推送您的代码,可以最大程度地减少丢失的工作(如果发生这种情况).如果您需要动力…想念一个重要的截止日期,因为您(Long periods without pushing your code increases the risk that your computer will crash and you will lose work. This doesn’t happen often, but it can and does happen. It will happen to you at some time in your programming career. How much work will you lose? Push your code frequently and you minimize the work lost if this ever happens to you. If you need some motivation… think of missing an important deadline because you)**丢失(lost)**你的工作.想一想您的队友或老板会怎么想.每天推送(或可能使用自动备份系统)是您的唯一保护.(your work. Think of what your team mates or boss will think if this happens. Pushing daily (or possibly using an automated backup system) is the only protection you have.) 如果您正在研究实验性或不确定性的功能,并且不想冒险将其推入主存储库,则只需派生主存储库并将其推入.当然,您必须使用分布式系统来执行此操作.(If you are working on an experimental or uncertain feature and you don’t want to risk pushing to the master repository, simply fork the master repo and push to that. Of course you have to be using a distributed system to do this.)

保留您的回购协议的干净副本(Keep a clean copy of your repo)

通常值得在开发工作站上维护两个代码副本.您有一份用于开发.您可以使用其他副本进行测试或将更改与(It’s often worthwhile maintaining two copies of your code on your development workstation. You have one copy for development. You can use the other copy for testing or comparing your changes to the) 基准线(baseline) .您既可以使用传统版本控制也可以使用分布式版本控制.使用传统代码,您只需要将服务器存储库的新副本复制到其他工作目录中,尽管根据我的经验,使用SVN比使用Perforce更容易.如果您使用的是分布式版本控制,那么它甚至更容易.只需单独复制主存储库即可.(. You can do this with both traditional and distributed version control. With traditional code you just get a new copy of the server repository to a different working directory, although in my experience this is easier with SVN than it is with Perforce. If you are using distributed version control then it is even easier. Just make a separate clone of the master repository.) 使用分布式版本控制,拥有存储库的多个副本更容易,更有效.这是一个例子.在开发副本中进行更改.测试,审查并提交您的更改.现在,将您的更改推送到干净副本(当然,它将不再干净).现在,在干净的仓库中测试您的更改.您的测试还通过吗？将代码推送到主存储库时,代码通常会中断.也许您忘记了导入或提交文件？推送到单独的干净存储区并进行测试可以防止将此类问题强加给您的队友.一旦您纠正了干净仓库中的所有问题,现在就可以安全地将更改推送到主仓库中.(Having multiple copies of a repository is easier and more effective with distributed version control. Here’s an example. Make your changes in your development copy. Test, review and commit your changes. Now push your changes to your clean copy (which will no longer be clean of course). Now test your changes in your clean repo. Do your tests still pass? Code often breaks when you push it to the master repo. Maybe you forgot to import or commit a file? Pushing to a separate clean repo and testing there prevents these kinds of issues being forced on your team mates. Once you have rectified any issues in your clean repo you are now safe to push the changes to your master repo.) 当您的开发仓库中有错误时,拥有干净的副本是一件好事.您可以并排使用两个存储库进行比较.这可以帮助您更好地了解所做的更改.这对于了解是刚刚创建一个错误还是已经存在一个错误非常有用.当您拥有干净的副本时,可以测试这样的问题.在干净的副本中再次运行测试,您会很快发现您是否刚刚引入了错误或代码中是否已存在该错误.(Having a clean copy is good when you have a bug in your development repo. You can have two repos side-by-side for comparison. This can help you better understand the changes you have made. It’s great for understanding if a bug was just created now or if it was already there. When you have a clean copy you can test questions like this. Run your tests again in the clean copy and you will quickly find out if you have introduced a bug just now or if it was pre-existing in the code.)

在需要时还原更改(Revert changes when you need to)

是否有尚未完成的一些实验代码更改？您一直在编写代码,但是遇到了问题.您将继续用蛮力解决问题.如果提交此有问题的代码,则可能要花费数周的时间来清理问题.您可能已经遇到过这种情况.重构,尤其是在没有自动化测试的安全网的情况下,可能会导致可怕的代码损坏,并在几个月后显示出错误.(Have some experimental code changes that haven’t panned out? You’ve been working on code and you’ve hit a problem. You continue to brute force your way through the problem. If you commit this problematic code you may spend weeks mopping up the issues. You may have already experienced a situation like this. Refactoring, especially without the safety net of automated tests, can result in horribly broken code that manifests bugs for months afterward.) 编码通常与找到正确的前进方向有关.有些路径显然比其他路径要好,并且有些方向完全是错误的.如果您走错了方向,您将无法继续前进并编写出正确的方法.当您发现当前方向存在问题时,请停止为自己挖一个更深的洞!(Coding is often about finding the right path forward. Some paths are clearly better than others and there are some directions that are just plain wrong. If you are heading in the wrong direction you can’t just continue pushing forward and code your way out of it. When you recognize a problem with your current direction, stop digging a deeper hole for yourself!) 当变化不顺利时,不要害怕还原变化!如果存在明显的问题或感觉不对劲,只需还原代码,花点时间思考一下,然后从另一个角度解决问题.你已经在做(Don’t be afraid to revert changes when they aren’t going well! If there are obvious problems or something doesn’t feel right, simply revert your code, take some time to think, then come at the problem from a different angle. You are already doing) 小承诺(small commits) …因此您将失去的工作量将很小.(… so the amount of work you will lose will be small.) 另一种选择是(Another alternative is to) 藏(stash) 要么(or) 搁置(shelve) 您所做的更改,直到您找出解决问题的方法为止.另外,当您计划重构或进行实验性更改时,请考虑(your changes until you figure out how to solve the problem. Also when you plan to refactor or make experimental changes consider)**分叉(forking)**要么(or)**分枝(branching)**这样您就可以防止可能发生的重大更改影响团队伙伴.(so that you can keep your potentially broken changes from affecting your team mates.)

测试中(Testing)

版本控制可以帮助进行测试.考虑使用一个单独的存储库来记录您的结果(Version control can help with testing. Consider having a separate repository just for recording the results of your)输出测试(output testing)(在((check it out in the) 测试文章的技术部分(Techniques section of the Testing article) ).运行测试时,可以使用版本控制系统来区分更改,以了解行为是否已更改或发生了故障.(). When you run your tests you can use your version control system to diff the changes to understand if behavior has changed or something has broken.)

代码冻结(Code freezes)

在开发生命周期中,有时您会想要(There will be times in your development lifecycle when you will want to) **冻结(freeze)**代码库(the code-base) .(.) 例如,假设您刚刚发布了游戏的一个版本,或者您已经通过了一个重要的里程碑.此时,您需要保留游戏的版本.不可避免地,您将不得不再次更新和发布该版本.同时,您的开发人员必须能够继续前进(For example, say you’ve just released a version of your game to production or maybe you’ve passed a significant milestone. You need to preserve a version of the game at this point. Inevitably you will have to update and release that build again. At the same time your developers must be able to move forward with)**工作正在进行中(work in progress)**以便将来发布.您需要将这些工作流分开,以使您的开发人员(他们尽力而为地工作)不会破坏以前工作的生产版本.(for a future release. You need to keep these streams of work separate so that your developers (who are working as hard and fast as they can) don’t break the previously working production build.) 如果您的版本控制系统支持此功能,请使用它来强制执行(If your version control system supports this, use it to enforce the)代码冻结(code freeze).特定的版本控制系统,尤其是传统的系统,可以支持可配置的读/写权限.如果是这种情况,请在代码冻结期间删除写权限.使用分布式版本控制,一种简单的方法是重命名您的(. Particular version control systems, especially traditional systems, may support configurable read/write permissions. If that’s the case remove write permissions during a code freeze. With distributed version control a simple technique is to rename your)**冷冻的(frozen)**回购.将仓库重命名为类似(repo. Rename the repo to something obvious like)冻结的里程碑2(Frozen Milestone 2).这样可以防止您的开发人员无意间推送到冻结的代码库.(. This prevents your developers from accidentally pushing to the frozen code-base.) 当然,您还需要一个(Of course you also need a)**工作正在进行中(work in progress)**复制代码库,以供开发人员继续工作.分布式版本控制使此变得微不足道.你只是(copy of the code-base for developers to continue their work. Distributed version control makes this trivial. You simply)**叉子(fork)**要么(or)**克隆(clone)**冻结的存储库,并使用新的回购继续进行中的工作.(the frozen repository and continue the work in progress with the new repo.)

仅在需要时分支或派生(Branch or fork only when you need to)

请记住,您创建的每个分支或分支都需要在头部留出空间以记住正在发生的事情.保持简单.仅当您有正当的理由或拥有易于理解每个分支或分支目的的系统时,才这样做.(Remember that each branch or fork that you create requires space in your head to remember what is going on. Keep things simple. Only branch or fork when you have a justifiable reason for doing so or when you have system that makes it easy to understand the purpose of each branch or fork.) 如果必须有许多分支或分支,请记录每个分支的目的,以免您难以记住.(If you must have many branches or forks, document the purpose of each so that you don’t struggle to remember.)

错误恢复和错误调查(Error recovery and bug investigation)

您是否曾经不小心将重要的错误发布到生产代码中？您拼命尝试调试问题时,老板是否徘徊？(Have you ever accidentally released a significant bug to production code? Has your boss hovered while you desperately try to debug the problem?) 版本控制可以在这里提供帮助,它为解决已暴露给用户的新问题提供了一种方便的方法.只是(Version control can help here, it provides a convenient way out for new problems that have been exposed to your users. Simply)**回滚(rollback)**要么(or)**退出(backout)**删除更新和损坏的代码.尽快将您的用户恢复为工作版本.然后,只有当情况恢复正常时,才花点时间评估出了什么问题并调查问题.(to remove the updated and broken code. Revert your users back to a working version as quickly as possible. Then, only when things are back to normal, take the time out to assess what went wrong and investigate the problem.) 您当前的修订版本被严重破坏了,您不知道为什么吗？确定导致该问题的修订版,您将发现该问题更容易解决.修复错误最困难的部分通常是找到导致该错误的代码.我相信您已经有经验,需要花费几天的时间才能找到问题的根源,然后只需5分钟即可修复负责的单行代码.如果您可以找到引入问题的修订版本,则可以很容易地理解问题.通常,了解问题比解决问题要困难得多.(Is your current revision horribly broken and you have no idea why? Identify the revision that caused the issue you will find the issue is much easier to fix. Often the most difficult part of fixing a bug is finding the code that causes it. I’m sure you’ve had the experience where it takes days to find the source of an issue and then only 5 minutes to fix the single line of code that was responsible. If you can locate the revision where an issue was introduced it will be significantly easier for you to understand the problem. Understanding the problem is usually much more difficult than fixing the problem.) 为了找到错误的原因,我们必须在代码中找到它.如果您搜索整个代码库,就好像在大海捞针中找针.您可以采取任何缩小搜索空间的方法都会有所帮助.通常,这意味着使用您对代码的理解和一些直觉来针对您怀疑与该问题相关的特定代码模块.但也要考虑到这一点,如果将搜索空间缩小到单个修订版,则搜索将非常有针对性.查找错误所必须搜索的代码已大大减少,尤其是当您这样做时(To find the cause of a bug we must locate it in the code. If you search the entire code-base it’s like trying to find a needle in a haystack. Anything you can do to narrow down the search space will help. Often this means using your understanding of the code and some intuition to target particular code modules that you suspect are related to the issue. But also consider this, if you narrow down the search space to a single revision, then your search will be extremely well targeted. The code you must search to find the bug is vastly reduced, especially when you do) 小承诺(small commits) .这将自动使您更接近查找错误.在许多情况下,当您检查有问题的代码修订版时,错误的原因将立即显而易见.(. This automatically puts you closer to finding the bug. In many cases the cause of the bug will be immediately obvious when you inspect the offending code revision.) 提出了一个问题:我们如何找到引入该错误的修订版？您正在寻找的技术称为(The raises the question: how do we find the revision that introduced the bug? The technique you are looking for is called) 二等分(bisection) .这就像一个(. This is like a) 二进制搜索(binary search) 应用于您的代码库.您有一系列的代码修订,最新的修订已被破坏,过去的修订是可以的:您必须在引入错误的位置之间搜索修订.当然,您可以使用任何版本控制系统手动执行此操作,尽管这可能会花费大量时间和耐心,但有时即使手动操作也是值得的,因为(applied to your code-base. You have a sequence of code revisions, the latest revision is broken, some past revision is ok: You must search for the revision in-between where the bug was introduced. Of course you can do this manually with any version control system, although this can take significant time and patience, sometimes however even the manual approach is worthwhile, because for)**最恐怖的(the most horrible)**错误,仍然可能是导致问题原因的最快途径.(bugs it still may be the fastest route to the cause of the problem.) 幸运的是,现代的分布式版本控制系统(Fortunately modern distributed version control systems) 提供用于二等分的内置工具(provide built-in tools for bisection) .一旦了解了这意味着什么,您就会发现它非常神奇. Bisect工具可以大大加快您的手动过程.它们还提供了自动平分的潜力.要进行构建,您需要投资于自动化的构建和测试过程,这并不便宜,但是它还具有许多其他优点.在这种情况下,优点是我们可以运行全自动的二等分过程.让它完成它的工作,当您回到工作站时,它将在代码损坏时告诉您修订版本.对我来说,这非常像拥有超级大国.如果您能做到这一点,您的队友将屈从于您神似的编码能力.(. You’ll find it quite amazing once you understand what this means. Bisect tools can significantly speed up your manual process. They also offer the potential for an automated bisection. To build that you will need to have invested in an automated build and test process, that’s not cheap but it has many other advantages. In this case the advantage is that we can run a fully automated bisection process. Let it do it’s job and when you come back to your workstation it will tell you the revision when the code was broken. To me this feels very much like having superpowers. If you can achieve this your team mates will bow to your god-like coding powers.)

怪(Blame)

怪(Blame) 当您需要标识最后修改一行代码的程序员时,它有时很有用.我通常会提拔(is occasionally useful when you need to identify the programmer that last modified a line of code. Normally I promote)**代码的共同责任(shared responsibility of code)**和一种文化(and a culture)没有责备(without blame).无论如何,有时您需要知道谁负责特定的代码行.这在拥有许多开发人员的大型公司中最有用,例如,在您需要了解以前从未编辑过的代码模块的情况下. Blame将让您知道谁最后一次编辑了您正在查看的代码.现在,您可以找到他们询问他们的代码发生了什么.(. Regardless, sometimes you need to know who was responsible for a particular line of code. This is most helpful in larger companies with many developers, say in a situation where you need to understand a code module you haven’t edited before. Blame will let you know who last edited the code you are looking at. Now you can find them to ask what is going on with their code.)

钩子(Hooks)

版本控制挂钩可能非常有用.使用它们来检测何时有人将其推送到存储库.例如,当有人将更改推送到主存储库时,您可能希望发送通知.或触发自动构建和测试.更高级:当您在云VM上推送到仓库时,触发服务器重启.这是用于简单服务器部署的有用技术.(Version control hooks can be very useful. Use them to detect when someone has pushed to a repository. For example you might want to send a notification when someone has pushed changes to the master repo. Or trigger an automated build and test. More advanced: trigger a server restart when you push to repo on a cloud VM. This is a useful technique for simple server deployments.)

删除旧代码(Delete old code)

不要害怕删除旧代码.在阅读代码时,最好将其删除而不是将其注释掉并争夺大脑空间.如果您再次需要该代码(大多数时候不需要),则可以轻松地从版本控制历史记录中恢复它.(Don’t be afraid to delete old code. Better to delete it rather than comment it out and have it vying for brainspace when you are reading through code. If you need that code again (most times you won’t) you can easily recover it from the version control history.) 当应该删除注释掉的代码时,不要保留在适当的位置.我保证将来某人(可能是您的未来自我)将不得不弄清楚如何处理该代码.帮他们一个忙,现在就删除它(Don’t leave commented-out code in place when it should be deleted. I guarantee that in the future someone (probably your future-self) will have to figure out what to do with that code. Do them/yourself a favor and just delete it now at a time when you)**最好的了解(best understand)**该代码.(that code.) 如果您确实有理由保留注释掉的代码,请在代码中加上注释,并说明必须保留该代码的原因.(If you do have a justifiable reason for leaving in commented-out code… document that code with comments and state the reason why you must leave the code in place.)

合并中(Merging)

不要害怕合并.如果与其他程序员一起工作,则有时必须合并代码.有时合并会变得很糟,很难解决它们.值得学习如何对合并充满信心.创建示例存储库,然后练习,练习,练习.确保您尝试了几种不同类型的合并软件,并非所有软件都是一样的,并且您可能会发现其中的一些软件比其他软件更易于理解.(Don’t be afraid of merging. If you work with other programmers you will at some point have to merge your code. Sometimes merges go bad and it can be very difficult to resolve them. It’s worthwhile learning how to be confident at merging. Create an example repository and practice, practice, practice. Make sure you try a few different types of merge software, not all were created equal and you may find some easier to understand than others.) 永远不要尝试合并二进制文件.(Don’t ever attempt to merge binary files.) 永远不要尝试合并生成的文本文件.您可以简单地重新生成这些文件,因此无需浪费您宝贵的大脑资源来尝试合并它们(注意:无论如何,生成的文件可能都不应该处于版本控制中).(Don’t ever attempt to merge generated text files. You can simply regenerate such files, so there is no need to waste your precious brain resources trying to merge them (note: generated files probably shouldn’t be in version control anyway).) 保持代码干净整洁.良好分离的代码模块意味着编码人员更有可能在单独的模块上工作,因此,他们的工作重叠的可能性较小,因此合并的可能性也较小.(Keep your code clean and well organized. Well-separated code modules mean that coders are more likely to be working on separate modules, so there is less chance their work will overlap and therefore less chance of needing to merge.)

与其他工具整合(Integrate with other tools)

尽可能将版本控制与其他工具集成. Visual Studio 2015内置了Git集成,这非常有用.对于其他各种版本控制系统,都有Visual Studio扩展.(Integrate version control with other tools where possible. Visual Studio 2015 has built in Git integration which is very useful. There are Visual Studio extensions for various other version control systems.) 如果您使用Perforce或PlasticSCM和Unity,请确保您查找(If you use Perforce or PlasticSCM and Unity, make sure you look up) Unity版本控制集成(Unity version control integration) .(.) 在可能的地方将您的版本控制与持续集成和持续交付系统集成在一起.(Where possibly integrate your version control with your continuous integration and continuous delivery systems.)

版本控制软件(Version Control Software)

本节总结了我使用的版本控制软件以及对每个版本的想法.(This section is a stock-take of the version control software that I have used and my thoughts on each.) 请寻求维基百科的完整信息(Please seek Wikipedia for a full) 版本控制软件的比较(comparison of version control software) .(.)

颠覆(SVN)(Subversion (SVN))

广泛使用的开源/免费传统版本控制系统.如果您想使用传统模型并且不想为专有解决方案付费,则可以使用该选项.(A widely used open-source/free traditional version control system. If you want to use the traditional model and you don’t want to pay for a proprietary solution, this is the option you want to use.) 它已经相当成熟并且相当容易上手.我已经在多家公司使用过它,它可以处理大量的存储库和许多分支.(It’s quite mature and reasonably easy to get started with. I’ve used this at several companies and it can handle massive repository and many branches.) 它支持二进制或大型资产.(It’s support for binary or large assets is ok.) SVN具有文件锁定系统,当您希望防止多个人同时处理同一个文件时,该系统可以提供帮助,但是该过程并没有真正内置,因为您不必(SVN has a file locking system which can help when you want to prevent multiple people working on the same file at the same time, however this isn’t really built into the process as you don’t have to)**退房(check out)**在编辑文件之前.从很多方面来说,这是件好事,因为您可以修改文件,并且SVN会根据您的需要进行更改,但是这对文件锁定不利,因为这使用户有责任在更改文件之前检查文件是否已锁定.这给用户错误留下了空间,并且意味着多个用户可以编辑一个二进制文件,即使它是(a file before editing it. In many ways this is good because you can modify files and SVN will figure out for you want have you have changed, but it’s bad for file locking because it makes it the user’s responsibility to check if a file is locked before changing it. This makes room for user error and means multiple users can edit a binary file, even when it is)已锁定(locked),当用户提交时,他们会发现,如果其他人已经锁定了文件,则他们必须丢失所做的更改.(, when the users comes to submit they will find that they must lose their changes if someone else already has the file locked.)

外星人(Alienbrain)

自从我使用了十多年(It has been more than 10 years since I used) 外星人(Alienbrain) .我发现它是一个非常强大的解决方案,为大型二进制文件和大型项目提供了强大的支持. Alienbrain专为娱乐行业而建,主要供数字艺术家使用.它与3ds max和Photoshop等美术工具具有很好的集成和支持.它还具有良好的API,并且非常可定制.不幸的是(. I found it to be a very robust solution with great support for large binary files and large projects. Alienbrain is built for the entertainment industry and is mostly used by digital artists. It has great integration and support for art tools like 3ds max and Photoshop. It also has good API and is very customizable. Unfortunately it is) 非常贵(very expensive) 除了最大的制片厂之外,这超出了所有其他公司的范围.(which puts it out of range for all except the largest studios.)

Perforce(Perforce)

我曾在多家公司使用过Perforce.这是专业行业中的标准.它既强大又可靠.它可以支持庞大的团队和数千个分支机构.它具有出色的性能,并且可以很好地处理二进制资产和大型项目.团结有(I’ve used Perforce at various companies. It is something of a standard in the professional industry. It is robust and fairly reliable. It can support massive teams and thousands of branches. It has great performance and it deals well with binary assets and large projects. Unity has) 内置与Perforce合作的支持(built-in support for working with Perforce) .(.) 但是,Perforce有一些严重的缺点.有时,我们会遇到不可复制的异常不良行为.我们的构建服务器有时会淘汰错误的构建.通常,通过(However, there are a some serious downsides to Perforce. Occasionally we encounter unusual bad behavior that isn’t reproducible. Our build server sometimes churns out bad builds. It’s usually easy to fix by doing a)**强制得到(Force get)**资产和重建.我们不能确定Perforce还是Unity是真正的罪魁祸首,但这意味着我不能肯定地说Perforce是100%坚如磐石.(of the assets and a rebuild. We can’t be sure if Perforce or Unity is the real culprit here, but this means that I can’t say for sure that Perforce is 100% rock solid.) 我们似乎经常与随机的Perforce问题,其神秘的API或笨拙而过时的界面作斗争.是的,版本控制可能很复杂,很难理解,但是Perforce有时似乎会竭尽全力使事情变得更糟.我有些怀疑(We often seem to battle against random Perforce issues, its arcane API, or its awkward and outdated interfaces. Yes version control can be complicated, it can be tough to understand, however Perforce sometimes seems to go out of its way to make things worse for us. I sometyimes wonder) 为什么使用Perforce(why Perforce is used) 尽可能多.当然有很多有效的(as much as it is. Of course there are many valid) 原因(reasons) 使用Perforce,但我个人很难推荐,特别是对于小型工作室.它确实很好地解决了一些问题,因此是否值得考虑真的取决于您的情况.(to use Perforce, but personally I have found it difficult to recommend, especially to small studios. It does solve some problems very well, though so whether it’s worth considering really depends on your situation.) 由于分布式模型的日益流行,Perforce已开始参加革命.我没有尝试使用Perforce的这一新方面,因此我无法对此发表评论,我之所以提及它,只是因为有趣的是,注意到Perforce已经注意到了分布式运动.(Due to the rising popularity of the distributed model, Perforce have moved to to take part in the revolution. I haven’t tried using this new aspect of Perforce so I can’t comment on it, I mention it just because it is interesting to note that Perforce have taken notice of the distributed movement.) 关于Perforce的真正困扰我的一件事是,您必须(One thing that really annoys me about Perforce is that you have to)**退房(check out)**在编辑文件之前.当使用Subversion和分布式系统时,您只需开始编辑代码或资产,然后软件就会为您找出发生了什么变化.这是使Perforce显得非常过时的一件事.当然了(a file before editing it. When using Subversion and the distributed systems you simply start editing your code or assets and the software figures out for you what has changed. This is one thing that makes Perforce seem incredibly old-fashioned. Of course the)**编辑前签出(check out before edit)**该模型实际上对二进制资产最有效(因为它允许锁定这些文件-这是Perforce的有用功能),但由于其他原因,这是不必要的麻烦.(model actually works best for binary assets (because it allows these files to be locked - a useful feature of Perforce), but for every other reason it’s an unnecessary frustration.) Perforce很棒的一件事,我已经提到过,(One thing that’s great about Perforce and I’ve mentioned this already, is just) 有多快(how fast it is) .尝试将1 GB项目从存储库同步到工作站. Perforce会更快地解决此问题,而使用您的操作系统在同一网络上复制1 GB文件将花费更快.你最终想知道(. Trying syncing a 1 GB project from the repository to your workstation. Perforce will chomp it’s way through this faster that it would take to copy a 1 GB file over the same network using your operating system. You end up wondering)它真的得到了所有文件吗？(did it really get all the files?) 我不知道Perforce如何能这么快地复制文件,这似乎很神奇.这个方程式的反面是Perforce令人难以置信(I have no idea how Perforce can copy files so quickly, it seems like magic. The flip side of this equation is that Perforce is incredibly)笨(stupid).我已经提到过,Perforce无法确定您所做的更改,您必须(. I’ve already mentioned that Perforce can’t figure out what you have changed, you have to)**退房(check out)**编辑之前.当然可以使用(before editing. Of course you can use the)**协调离线更改(Reconcile offline changes)**功能,但是在大型项目中这会非常缓慢.还有一个缓存系统,使Perforce可以非常快速地复制文件.这对于提高性能非常有用,但是这意味着Perforce无法及时了解工作目录中当前的最新信息.例如,您可以删除部分工作目录,然后执行(feature, but that’s painfully slow on a large project. There’s also the caching system that makes Perforce very fast to copy files. That’s great for performance, but it means Perforce doesn’t keep up to date with what’s actually currently in your working directory. For example you can delete part of your working directory then do a)**取得最新(Get latest)**一切都不会降下来.就Perforce而言,您仍然是最新的!那是因为Perforce不会检查工作目录的状态,而是检查其缓存,并且缓存已过期.(and nothing will come down. As far as Perforce is concerned you are still completely up to date! That’s because Perforce isn’t checking your working directory for it’s state, it’s checking its cache and it’s cache is out of date.) 就像我说的那样,Perforce并不聪明.此外,Perforce也无法从工作副本中充分清除已删除的文件.当某些已删除的DLL留在项目中并导致构建失败时,这是一个痛苦的问题.由于与DLL问题有关的Unity错误消息错误,您甚至可能无法找出导致问题的DLL!解决此问题的标准方法是删除项目并执行(Like I said Perforce is not smart. Also Perforce doesn’t adequately clean up deleted files from the working copy. This is a painful problem when some deleted DLL gets left in a project and causes a build to fail. Due to Unity’s bad error messages relating to DLL problems you might not even be able to find out which DLL is causing the problem! The standard way to do deal with this is by deleting the project and doing a)**强制得到(force get)**在Perforce中. (必须使用强制获取来覆盖Perforce的缓存,这会使Perforce无法理解您已删除了工作副本的一部分,再次是愚蠢的Perforce.)现在,(in Perforce. (Force get must be used to override Perforce’s cache which prevents Perforce from understanding that you have deleted part of your working copy, again stupid Perforce.) Now the)**强制得到(force get)**可以很快完成,Perforce在这种情况下很快,但是现在您必须将整个项目重新导入到Unity中,这可能需要一个小时或更长时间(对于大型项目).这是因为删除文件后,Perforce无法正确清理其工作目录.(will complete reasonably quickly, Perforce is fast at that sort of thing, but now you have to reimport the entire project into Unity which could take an hour or more (for a large project). This is all because Perforce doesn’t properly clean up its working directory when files have been deleted.) 总结一下. Perforce很好地解决了一些问题.它速度很快,可以很好地处理二进制文件和大型项目.它允许锁定文件,从而阻止多个人编辑二进制文件.(So to summarise. Perforce solves some problems very well. It’s fast, it deals well with binary files and large projects. It allows files to be locked which stops multiple people from editing binary files.) 但是,这也会引起很多问题. Perforce较旧,其工具复杂,缓慢且有漏洞.您必须解决工作流程中的各种问题以及维护成本,以使其在时间和资源上保持正常运转.关于如何使用Perforce解决问题很难找到答案,尽管入门很容易,但掌握起来却极为困难且耗时.(However there it also causes plenty of problems. Perforce is old, their tools are complicated, slow and buggy. You’ll have to workaround various issues with your workflow and the maintenance cost for keeping it working chews through time and resource. Answers on how to solve problems with Perforce can be hard to come by and although it’s easy to get started with it is extremely difficult and time-consuming to master.) Perforce提供了大量的控制和灵活性,这很好,但是要使用它,您必须处理可能不一致且难以使用的命令和API. Perforce命令的输出可能很难解析.(Perforce offers a massive amount of control and flexibility, this is good but to make use of it you’ll have to deal with their commands and APIs which can be inconsistent and difficult to work with. The outputs of Perforce commands can be tricky to parse.) 如果您必须使用Perforce,请检查我们的开源(If you must work with Perforce please check our open-source) NodeJS API(NodeJS API) .我们认为这是对Perforce API的简单抽象.如果它不能完全满足您的要求,请(. We believe this is a simpler abstraction over the Perforce API. If it doesn’t do exactly what you want, please) 在Github上做贡献(contribute on Github) .(.)

汞(HG)(Mercurial (HG))

分布式版本控制是一种管理代码的绝妙方法.无论您是开发人员还是团队,这都适用.当我第一次开始使用分布式版本控制时,我喜欢在通勤上班时可以增加提交次数.然后,当我晚上回家时,可以将所有工作推送到NAS盒中的主存储库中.分布式版本控制在Real Serious Games的开发团队中也发挥了很好的作用,我很快会谈到更多.(Distributed version control is a fantastic way to manage code. This applies whether you are a solo developer or a team. When I first started using distributed version control I loved that I could bank up commits whilst commuting to work on the train. Then when I arrived home in the evening I could push all my work to the master repository on my NAS box. Distributed version control has also worked well for the development team at Real Serious Games, I talk more about that soon.) 我喜欢(I like) 水银(Mercurial) 因为它很简单,至少我相信它比Git更简单.它非常可靠,易于设置和使用.(because it’s simple, at least I believe it is simpler than Git. It’s very reliable and it’s easy to setup and use.) 如果您想开始使用Mercurial,可以选择(If you are looking to get started with Mercurial there is a) Joel Spolsky在线上的精彩教程(great tutorial online by Joel Spolsky) .的(. The) 官方教程(official tutorial) 也不错.(is also good.) 如果您进入Mercurial,请确保签出(If you get into Mercurial, make sure you check out) 权威指南(The Definitive Guide) .(.) 比特桶(BitBucket) 是Mercurial的出色在线托管解决方案,并与(is a great online hosting solution for Mercurial and integrates well with) Atlassian的(Atlassian’s) 其他工具.(other tools.)

吉特(Git)

吉特(Git) 是另一个分布式版本控制,是Mercurial的主要替代产品. Git是最受欢迎的DVCS,尤其是在开源领域. Git和DVCS通常已经随着我们的意识的兴起而飞入我们的意识中(is another distributed version control and is the main alternative to Mercurial. Git is the most popular DVCS, especially in the open source space. Git and DVCS generally have been catapulted into our consciousness driven by the rise and rise of) 的GitHub(GitHub) .(.) 我通过GitHub上的开源开发来使用Git(无论是个人使用还是在R​​eal Serious Games上使用).在大多数方面,它与Mercurial非常相似. GitHub通常使管理Git仓库变得非常容易.尽管Git实际上非常复杂和灵活.如果您想构建一个高度定制的开发工作流程,这将很有用,尽管我更喜欢Mercurial,因为我更喜欢VCS无需任何设置或自定义即可工作.就像我说的,但是如果您使用GitHub,这会使Git的使用非常简单,实际上,如果您使用的是类似(I use Git (both personally and at Real Serious Games) through my open source development on GitHub. In most respects it’s very similar to Mercurial. GitHub generally makes it very easy to administer a Git repo. Git though is actually quite complex and flexible. This can be useful if you want to build an extremely customized development workflow, although I prefer Mercurial because I prefer a VCS to just work without requiring any setup or customization. Like I said though if you use GitHub that makes Git quite simple to use and in fact if you are using something like) 源树(SourceTree) 那么您几乎不必关心自己是在Mercurial还是Git中工作.(then you rarely have to even care whether you are working in Mercurial or Git.) 这是有帮助的(Here’s something to help) 让您开始使用Git(get you started with Git) .(.) Git也有一个(Git also has a) 很棒的参考手册(great reference manual) .(.) 的GitHub(GitHub) 是一个很棒的托管平台,对于公共(开源)存储库是免费的.(is a great hosting platform and is free for public (open-source) repositories.) 比特桶(Bitbucket) 与GitHub不同,Bitbucket还可以用于托管Git存储库,尽管Bitbucket提供免费的私有存储库.(can also be used to host Git repositories, unlike GitHub though Bitbucket offers free private repositories.)

源树(SourceTree)

我认为值得一提SourceTree.这是来自的工具(I thought it was worth mentioning SourceTree. This is a tool from) Atlassian(Atlassian) 可以用作Mercurial和Git的UI.它消除了这些软件包之间的(一些实际的)差异,以至于您几乎不必关心实际使用的是哪种类型的存储库.(that can be used as a UI for both Mercurial and Git. It smooths over the (few real) differences between these packages, to the point that you rarely have to care which type of repository you are actually using.) 不幸的是,在撰写本文时,SourceTree的最新版本是一个巨大的bug盛宴.我个人坚持使用1.6.25版,直到情况有所改善,您可以轻松(Unfortunately, as of this writing, the most recent versions of SourceTree have been a massive bug-fest. Personally I have stuck with version 1.6.25 until things improve, you can easily) 通过Chocolatey安装此版本(install this version via Chocolatey) .(.)

观看软件(Software to watch)

这些是我非常感兴趣的一些软件包.如果任何人有使用这些软件包的经验并有故事要讲,请与我联系.(These are some software packages that I’m very interested in. If anyone has experience with these and has a story to tell please contact me.)

塑料单片机(Plastic SCM)

塑料单片机(Plastic SCM) 是VCS领域的一个相对较新的角色,我非常感兴趣.他们的目标是游戏和娱乐行业. Plastic SCM旨在成为传统和分布式模型的交叉点.(is a relative new comer to the VCS scene and I am following it with much interest. They are targeting the games and entertainment industries. Plastic SCM aims to be some intersection of traditional and distributed models.) 团结有(Unity has) 内置支持Plastic SCM(built-in support for Plastic SCM) ,这是对该软件包的广泛认可,但值得吗？(, this is a massive endorsement for this package, but is it deserved?)

版本控制的替代方法(Alternatives to version control)

本文将不完整地提及用于协作工作的版本控制的替代方法.(This article wouldn’t be complete with mentioning alternatives to version control for collaborative work.)

投寄箱(Dropbox)

投寄箱(Dropbox) 是在简单的协作环境中共享工作的绝佳方式.与团队共享资产和文档是一种便捷的方法.与游戏测试人员共享构建版本的好方法.(is a fantastic way to share work in simple collaborative environments. It’s a convenient way to share assets and documents with your team. It’s a great way to share builds with your play-testers.) 但是,存在很多潜在的问题:(However, there are plenty of potential problems:)

• 不要将其用作数据的主要副本.如果这样做,可能会导致队友意外删除您的工作.(Don’t use it as your primary copy of data. If you do that you risk having a team mate accidentally delete your work.)
• Dropbox不能很好地处理冲突,它无法合并在文件上完成的同时工作.(Dropbox doesn’t handle conflicts well and it has no way to merge simultaneous work that has been done on a file.)
• Dropbox会占用互联网带宽.在局域网上可以,您可以限制它.当您使用移动数据连接时,这很糟糕.(Dropbox sucks up internet bandwidth. This is ok on a LAN and you can limit it. This is bad when you are on a mobile data connection.) 此外,Dropbox不会跟踪版本,因此您无法恢复旧版本(除非您为非常昂贵的Pro版本付费).如果您发现自己想跟踪版本,那么您应该使用的是正确的版本控制系统,而不是Dropbox.(In addition Dropbox doesn’t track versions and so you can’t recover old revisions (unless you pay for the very expensive Pro version). If you find yourself wanting to track versions then you should really be using a proper version control system and not Dropbox.) 永远不要将Dropbox与版本控制系统结合使用.过去,我尝试将Mercurial存储库放入Dropbox中,但最终导致存储库损坏.问题是Dropbox处理冲突的方式.这意味着,如果两个人尝试同时使用存储库,则很有可能被Dropbox的冲突解决方法破坏存储库.如果您想以这种方式工作,则必须非常非常小心,它很有可能会(Don’t ever ever combine Dropbox with a version control system. In the past I tried putting a Mercurial repository in Dropbox, that ended in a corrupted repository. The problem is the way Dropbox deals with conflicts. This means that if two people attempt to work with repository at the same time there is very high likelihood that the repository will be destroyed by Dropbox’s conflict resolution. You have to be very very careful if you want to work this way and there is every chance that it will)落泪(end in tears).即使您是一个单独的开发人员,也可能发生这种情况!(. This can happen even if you are a solo developer!)

Google云端硬碟(Google Drive)

我经常使用(I regularly use) Google云端硬碟(Google Drive) 用于文档,电子表格,表单和演示文稿的个人和协作工作.尽管我无法想象使用它来共享代码或从事软件项目,但它对这类东西很有用.一件很酷的事情是,您可以创建脚本来自动化和自定义Google云端硬盘工作流程,这是我唯一的一次处理存储在Google云端硬盘中的代码的工作.它带有基本的IDE/代码编辑器,可提供出色的开发体验,但我没有抱怨,可以编写Google Drive脚本并且此服务是免费的,这非常酷!(for personal and collaborative work on documents, spreadsheets, forms and presentations. It’s great for that sort of stuff, although I couldn’t imaging using it for sharing code or working on a software project. One thing that is very cool is that you can create scripts to automate and customize your Google Drive workflow, that’s the only time I work on code that’s stored in Google Drive. It comes with a basic IDE/code-editor which makes for a terrible development experience, but I’m not complaining, it’s very cool that it is possible to script Google Drive and that this service is free!) Google云端硬盘的使用方式也与Dropbox类似,但也存在我已经提到的类似问题.(Google Drive can also be used in a similar way to Dropbox and that comes with same sorts of problems I’ve already mentioned.)

我们在真实严肃游戏中使用的(What we use at Real Serious Games)

我们在Real Serious Games中的需求非常独特.我们的工作节奏快,要求高.在RSG上获胜的技术往往是最简单的,并且可以最大程度地减轻头痛.当事情阻碍了我们交付产品的能力时,就会发生以下两种情况之一:我们以某种方式使产品运行,否则我们将其淘汰.(Our needs at Real Serious Games are quite unique. Our work is fast-paced and demanding. The techniques and technologies that win at RSG are the ones that tend to be the simplest and provide the most benefit for the least headaches. When things get in the way of our ability to deliver a product, one of two things happen: We make it work, somehow or someway, otherwise we get rid of it.) 我们将Mercurial用于我们的长期内部代码库,并且效果很好.(We use Mercurial for our long-term internal code-base and it works pretty well.) 我们使用Git和GitHub与开源世界进行交互.可能有一天,我们将完全转换为对所有代码使用Git.(We use Git and GitHub for our interaction with the open-source world. Possibly one day we will completely convert to using Git for all our code.) 对于我们的Unity项目和美术资产,我们使用Perforce.这是因为Perforce很容易向我们的技术人员解释,也使他们更容易理解.这也是因为Perforce通常速度很快,并且可以很好地与二进制资产和大型项目配合使用. Perforce允许项目的部分同步. Perforce允许我们锁定二进制文件,从而阻止多个人同时处理它们,从而防止合并问题.我们有很多必须解决的Perforce问题,但是在此时,它的好处仍然胜过缺点.(For our Unity projects and art assets we use Perforce. This is because Perforce is easy to explain to our less-technical staff and it is easier for them to understand. It’s also because Perforce is generally fast and works well with binary assets and large projects. Perforce allows partial-syncing of projects. Perforce allows us to lock binary files, which stops multiple people working on them simultaneously which prevents merge issues. We have plenty of issues with Perforce that we must deal with, however at this point in time its benefits still outweigh its disadvantages.) 我们已经付出了一些努力(We have put some effort into our) Perforce的开源脚本API(open-source scripting API for Perforce) .如果您使用的是Perforce,这也可能对您有所帮助.(. If you are using Perforce this might also help you.)

结论(Conclusion)

在本文中,我详细讨论了版本控制.为什么有用.它对开发至关重要,尤其是在协作团队中.以及它与游戏开发的关系.我检查了我有经验的软件包,并展示了我们目前在Real Heavy Games中使用的软件包.(In this article I’ve talked at length about version control. Why it’s useful. How it’s essential for development, especially in collaborative teams. Also how it relates to game development. I’ve reviewed the software packages that I have experience with and I have shown what we currently use at Real Serious Games.) 传统和分布式版本控制模型都有优点和缺点.在做出决定之前,您确实需要了解对您和您的团队重要的事情.您做出的任何决定都将需要处理问题,因为无论您选择哪种版本控制软件,都会给您带来一些问题.(Both the traditional and distributed models of version control have strengths and weaknesses. You really need to understand what’s important to you and your team before you make a decision. Which ever decision you take you will need to deal with problems, because no matter which version control software you choose, it will cause you some problems.) 当然,还有许多未解决的问题.大多数分布式VCS对二进制文件和大型项目的支持都很差.这仅仅是因为它们是新的并且还没有成熟吗？也许.也可能是因为分布式模型的性质使得难以解决这些问题.我不确定.(Of course there are many unresolved issues. Most distributed VCSs have poor support for binary files and large projects. Is this just because they are new and don’t yet have the maturity? Maybe. It could also be because the nature of distributed model makes it difficult to solve those problems. I am not sure.) 我只能希望分布式系统最终能够解决这些问题,因为分布式系统非常了不起,它们确实是未来的方式.然而,这些未解决的问题使游戏开发人员的生活变得困难.也许读过这篇文章的人会迎接挑战,并着手开发完全适合游戏开发人员需求的新型开源分布式系统？会是你吗？(I can only hope that the distributed systems eventually rectify these problems, because distributed systems are amazing and they really are the way of the future. Yet these unresolved problems make life difficult for game developers. Maybe someone reading this article will rise to the challenge and start work on a new open-source distributed system that perfectly fits the needs of game developers? Will it be you?)

资源资源(Resources)

维基百科:(Wikpedia:) https://zh.wikipedia.org/wiki/版本控制(https://en.wikipedia.org/wiki/Version_control) 版本控制简介:(Intro to version control:) http://guides.beanstalkapp.com/version-control/intro-to-version-control.html(http://guides.beanstalkapp.com/version-control/intro-to-version-control.html) 视觉指南:(Visual guide:) http://betterexplained.com/articles/a-visual-guide-to-version-control/(http://betterexplained.com/articles/a-visual-guide-to-version-control/) 分布式视觉指南:(Distributed visual guide:) http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/(http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/) Git vs Mercurial:(Git vs Mercurial:) https://importantshock.wordpress.com/2008/08/07/git-vs-mercurial/(https://importantshock.wordpress.com/2008/08/07/git-vs-mercurial/) 水银教程:(Mercurial tutorial:) http://hginit.com/(http://hginit.com/) 水银参考:(Mercurial reference:) http://hgbook.red-bean.com/(http://hgbook.red-bean.com/) Git教程:(Git tutorial:) http://gitimmersion.com/(http://gitimmersion.com/) Git参考:https://git-scm.com/book/en/v2(Git reference: https://git-scm.com/book/en/v2) Subversion参考:(Subversion reference:) http://svnbook.red-bean.com/en/1.7/svn.basic.version-control-basics.html(http://svnbook.red-bean.com/en/1.7/svn.basic.version-control-basics.html) Perforce:(Perforce:) https://www.perforce.com/our-customers/game-development(https://www.perforce.com/our-customers/game-development) AlienBrain:(AlienBrain:) http://www.nxn-software.com/(http://www.nxn-software.com/) 塑料SCM:(Plastic SCM:) https://www.plasticscm.com/version-control-for-games.html(https://www.plasticscm.com/version-control-for-games.html) 比较:(Comparison:) https://zh.wikipedia.org/wiki/比较(https://en.wikipedia.org/wiki/Comparison)**的(of)**版(version)**控制(control)**软件(software)

许可

本文以及所有相关的源代码和文件均已获得The Code Project Open License (CPOL)的许可。

Unity3D Dev system Git repository Mercurial best-practices game 新闻 翻译