为什么我的团队应该采用源代码控制? [英] Why should my team adopt source control?

问题描述

我有机会向我的老板正式介绍对公司有利的任何事情.我的想法是在我的工作场所采用源代码控制.我在工作中一直使用 Mercurial 来管理我自己的项目，但团队的其他成员没有一个正式的源代码控制系统.不幸的是，我不太擅长表达想法.

I have the opportunity to give a formal presentation to my boss about anything that benefits the company. My idea is to adopt source control in my workplace. I have been using Mercurial to manage my own project at work, but the rest of the team does not have a formal source control system in place. Unfortunately, I'm not very good at presenting ideas.

那么，你们能告诉我为什么开发人员必须使用源代码控制吗?此外，为什么您会选择任何工具除了 Visual SourceSafe?我没有使用 VSS 的经验，但他可能会问我们为什么不只使用 Microsoft 的工具.

So, can you guys tell me why developers MUST use source control? Additionally, why would you choose any tool except Visual SourceSafe? I don't have experience using VSS, but he is likely to ask why we wouldn't just use Microsoft's tools.

我想听听这里众多聪明程序员的意见！我的首选选项是 SVN 或 mercurial.两者似乎都对它们的 Windows 版本有很好的支持，而且都没有 CVS 过时.另外，作为一个自称开源弟子的人，我更愿意推荐一个开源工具.:)

I want to hear opinions from the many smart programmers here! My preferred options are SVN or mercurial. Both seem to have good support for their Windows versions, and both are less archaic than CVS. Also, as a self-declared open source disciple, I would prefer to suggest an open-source tool. :)

谢谢！

编辑:简而言之，一般来说，其他开发人员目前的做法是复制文件夹、带日期的标签，也可能自己记录.你得到了图片.如果我的老板说如果它有效，为什么要修复它?"

Edit: To make it short, generally, current practice for other developers is copying folder, tag with date and maybe record on their own. You get the picture. What if my boss says "if it works, why fix it?"

推荐答案

让我们比较两个例子，一个使用源代码控制的开发环境，一个没有.

Let's compare two examples, one development environment that uses source control, and one that doesn't.

• A:有用
• B:不使用

场景 1:请求、完成并推出项目

A + B) 程序员在内部开发项目，完成后，将其推送到测试，然后交付给客户(无论是谁)

A + B) Programmers develop the project internally, when it's completed, push it out to testing, and then deliver to the client (whoever that may be)

没有太大区别，大局

场景 2:项目发布后，客户决定不想要功能 X

A + B) 开发人员删除客户不想要、测试和交付的代码.

A + B) Developers remove the code that the client doesn't want, test, and deliver.

同样，差别不大.

场景 3:两周后，客户决定他们确实想要功能 X

A) 开发人员将他们在 2 中取出的代码重新集成到正常的开发树中，进行测试并交付.

A) Developers reintegrate the code they took out in 2 back into the normal development tree, test, and deliver.

B) 开发人员在他们的个人机器、文件服务器和备份上搜索旧代码.如果他们找到代码，他们必须手动重新插入每个文件.如果他们不这样做，他们可能必须重新编码整个功能.

B) The developers search for the old code on their personal machines, the file server, and backups. If they find the code, they must manually reinsert each file. If they do not, they probably have to recode that entire feature.

很容易得到你出于某种原因删除的旧代码

场景 4:系统中有一个奇怪的错误，函数应该返回布尔结果，但总是返回 false.两周前可不是这样.

A) 开发人员检查软件的所有旧版本，并发现 return false 指令不在正确的范围内 - 它在循环内而不是在循环外执行.

A) Developers examine all the old versions of the software, and figure out that a return false directive isn't in the proper scope - it's executing inside a loop instead of outside.

B) 开发人员花费数周时间试图找出问题所在.最终，他们注意到错误线路上的返回，并修复了它.没有源代码控制意味着他们必须检查执行的每个文件，而不是找出它工作时和现在之间的差异.

B) Developers spend weeks trying to figure out what the problem is. Eventually, they notice the return on the wrong line, and fix it. Not having source control means they had to examine each and every file that was executed, rather than finding the differences from when it was working and now.

场景 5:有人破坏了构建.它通过了测试，仅在几周后才被注意到.

A) 团队检查提交历史，找出谁破坏了构建，让那个人修复它并购买团队晚餐.

A) The team examines the commit history, finds out who broke the build, makes that person fix it and buy the team dinner.

B) 团队必须回溯整个项目才能找到错误，但无法弄清楚代码是谁放的.开发人员互相指责，团队动态失败.

B) The team has to go back through the entire project to find the error, but can't figure out who put that code in. Developers blame each other, and the team dynamic fails.

很容易看出谁犯了什么、何时犯以及为什么犯了.

这篇关于为什么我的团队应该采用源代码控制?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！