将开发团队从FTP转换为版本控制系统 [英] Converting a development team from FTP to a Versioning System
问题描述
我在一个小型LAMP Development Studio工作，其想法是只完成代码并转到列表中的下一个项目。
I work at a small LAMP Development Studio where the idea has been to just get the code done and go on to the next item on the list.
团队在通过FTP或SFTP连接到实时服务器的Zend Studio 5.5中工作。他们最喜欢的是代码部署的速度（因为它只是修改实时代码）。
The team works in Zend Studio 5.5 connected to the Live server via FTP or SFTP. What they love about this is the speed of their deployment of code (since its just modifying live code).
但是由于许多明显的原因，这当然不好。
But of course this is not good due to many obvious reasons.
我想将它们移至版本控制系统（CVS，SVN或任何其他工具）中，但是要注意的是，我不是他们的资深人士，所以我需要胡萝卜他们开始使用它。
I would like to move them to a Versioning System (CVS, SVN or any other tool) but the catch is, I am not their senior so I need a carrot for them to start using this.
我需要在他们的机器上进行什么样的设置，以便他们可以像往常一样编码？
What kind of setup would I need to build on their machine so they can code along as usual?
我要做的是在计算机上创建此设置，然后显示它们。
What I would do is create this setup on my machine and then show them.
我知道这有点不寻常，但它变成了我的一种热情，可以将他们的思维方式从通常的代码修改转变为结构和优雅。
I know this is kinda unusual but it's turned into a passion of mine to change their way of thinking from the usual hacking of code to structure and elegance. Thanks.
更新（Jonathan Leffler的回答）：
UPDATE (for Jonathan Leffler's answer):
- 是
- 否
- 是的，他们确实如此
问题此外，该工作室还制作了一个集中式CMS系统，该系统托管在数百个站点上，他们需要修改单个站点，这些站点是在主要组合中还是在自己的组合中？
Question also, the studio makes a centralized CMS system that is hosted on hundreds of sites, they need to modify individual sites, should the sites be in the main compository or within their own one?
推荐答案
问题：
-
您（他们）从未遇到过灾难，您（他们）需要还原到该网站的先前版本，但是因为它们破坏了网站而无法这么做？
Have you (they) never had a disaster where you (they) needed to revert to a previous version of the web site but couldn't because they'd broken it?
他们是否使用临时网站服务器来测试更改？
Do they use a staging web server to test changes?
当然，如果没有在某处进行某些测试，他们是否不会在生产服务器中修改代码？
Surely they don't modify the code in the production server without some testing somewhere?
我怀疑第一个答案是是（他们曾遭受灾难），第二个答案是否，我犹豫要为第三（但从它的声音来看，答案可能是是的，他们确实如此）。如果这是正确的话，我会佩服他们的夸张，惊讶于他们从未犯错。我绝对不会冒险直接在实时网站上进行更改。
I suspect the answer to the first is "yes (they have had disasters)" and the second "no", and I hesitate to guess the answer for the third (but. from the sounds of it, the answer might be "yes, they really do"). If that's correct, I admire their bravado and am amazed that they never make a mistake. I'd never risk making changes direct on a live web site.
我建议您自己使用版本控制系统或VCS（任何VCS）。弄清楚您要查找的代码的皱纹，并开发精巧的发行版，以便轻松地（可能仍在使用SFTP）将VCS代码分发到网站。但同时也表明保留以前的版本是有其优点的-因为您可以恢复谁在什么时候做了什么。首先，您可能会发现需要下载需要处理的任何页面（文件）的当前版本，然后将最新版本放入VCS中，然后再开始修改页面，因为自该页面以来其他人可能已经对其进行了修改。在您的主存储库中最新更新。您可能还希望每天对文件进行抓取以获取当前版本-并跟踪更改。您将没有谁，也没有确切的何时（比到最近的日期要好），也没有为什么，但是您将拥有（累计）什么变化。
I would recommend using a version control system or VCS (any VCS) yourself. Work out the wrinkles for the code you look after, and develop the slick distribution that makes it easy (probably still using SFTP) to distribute the VCS code to the web site. But also show that preserving the previous versions has its merits - because you can recover who did what when. To start with, you might find that you need to download the current version of whatever page (file) you need to work on and put that latest version into the VCS before you start modifying the page, because someone else may have modified it since it was last updated in your master repository. You might also want to do a daily 'scrape' of the files to get the current versions - and track changes. You wouldn't have the 'who', nor exactly 'when' (better than to the nearest day), nor the 'why', but you would have the (cumulative) 'what' of the changes.
在回答问题时，ÓlafurWaage澄清说，由于缺少VCS，他们遭受了灾难。
In answer to comments in the question, Ólafur Waage clarified that they've had disasters because of the lack of a VCS.
通常可以使生活更加轻松。他们无所适从；他们无法消灭傻瓜-他们可能会惹恼顾客，而他们本该非常烦恼。 VCS使从此类错误中恢复变得容易得多。显然，对于任何给定的自定义网站，您都需要VCS中该网站的正确或正式版本的（中央）备份。我可能会使用对分支和合并具有良好支持的VCS为所有客户提供一个单一的存储库。刚开始时（人们逐渐习惯使用VCS时），这可能很难解决，但从长远来看可能会带来更好的结果。我会认真考虑使用现代分布式VCS（例如， git ），尽管有很多人也可以使用SVN（即使它不是分布式VCS）。
That usually makes life much easier. They goofed; they couldn't undo the goof - they probably had annoyed customers, and they should have been incredibly annoyed with themselves. A VCS makes it much easier to recover from such mistakes. Obviously, for any given customized site, you need the (central) backup of the 'correct' or 'official' version of that site available in the VCS. I'd probably go for a single repository for all customers, using a VCS that has good support for branching and merging. That may be harder to deal with at first (while people are getting used to using a VCS), but probably leads to better results in the long term. I'd seriously consider using on of the modern distributed VCS (for example, git), though lots of people use SVN too (even though it is not a distributed VCS).
这篇关于将开发团队从FTP转换为版本控制系统的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
