I've never worked on a professional project with a team, as I'm still in high school. As a consequence, I've never been exposed to this whole "versioning" and "source control" thing. Are they the same? How exactly does a program that manages code manage code? I've heard you have to check out code (copy the existing code?) and merge it back in (what happens if someone changes code that you didn't change and you change something else and merge it in? Surely, his code is not replaced by your older version.) And, finally, what is the best/easiest example of this type of software?
我从未参加过一个团队的专业项目,因为我还在上高中。因此,我从来没有接触到这整个“版本控制”和“源代码控制”的事情。它们是一样的吗?管理代码的程序管理代码的确切程度如何?我听说你必须检查代码(复制现有代码?)并将其合并(如果有人更改了你没有改变的代码并且你改变了其他内容并将其合并进去,会发生什么?当然,他的代码是没有被旧版本取代。)最后,这类软件最好/最简单的例子是什么?
10 个解决方案
#1
I've heard you have to check out code (copy the existing code?) and merge it back in (what happens if someone changes code that you didn't change and you change something else and merge it in? Surely, his code is not replaced by your older version.)
我听说你必须检查代码(复制现有代码?)并将其重新合并(如果有人更改了你没有改变的代码并且你改变了其他内容并将其合并,会发生什么?当然,他的代码是没有被旧版本取代。)
That is precisely the reason for version control. It wouldn't really be a very useful tool if all it did was blindly overwrite people's code, would it? ;)
这正是版本控制的原因。如果只是盲目地覆盖人们的代码,那它真的不是一个非常有用的工具,不是吗? ;)
Source control tools maintain a repository with the entire history of the codebase. Every change is checked in as a delta, saving just what has changed. That means that if you and I both check out version A, and I then edit file B, and you edit file C, and we both check in, the source control software will compare the differences and where no conflicts exist (as in this case), just apply both changes, and if conflicts occur (if we both changed the same lines of code), it rejects the attempted check-in and tells you which two versions of the file had conflicting changes, and asks you to merge them manually. (usually it is also able to highlight the changes so you can see visually what has been changed in each version). So it never overwrites changes.
源代码控制工具维护一个存储库,其中包含代码库的整个历史记录。每个更改都以增量形式签入,只保存已更改的内容。这意味着如果你和我都签出版本A,然后我编辑文件B,你编辑文件C,我们都签到,源控制软件将比较差异和没有冲突的地方(如本例所示) ),只应用两个更改,如果发生冲突(如果我们都更改了相同的代码行),它会拒绝尝试的签入并告诉您文件的哪两个版本有相互冲突的更改,并要求您手动合并它们。 (通常它也能够突出显示更改,因此您可以直观地看到每个版本中已更改的内容)。所以它永远不会覆盖变化。
Other tasks it'll do for you is:
它将为您做的其他任务是:
- Tag specific versions or milestones so you can easily find them again later (this is the version where we finally fixed annoying bug #2524, this is beta 1, and so on
- Branch the repository into two, allowing changes that may go "out of sync" temporarliy, or even stay separate products forever (think of PHP simultaneously maintaining their PHP4 branch, while also working on PHP5. At some point they simly branched their codebase so while they started out identical, they can now apply patches to one without affecting the other). Of course it can also attempt to merge these branches back together (you may create a branch for each major feature in your product, perhaps, so they can be developed in isolation without being affected by the gradual changes happening to the rest of the code, and then when the feature is done, merge its branch back into the main repository)
标记特定版本或里程碑,以便您以后可以轻松找到它们(这是我们最终修复烦人的bug#2524的版本,这是beta 1,依此类推
将存储库分成两部分,允许更改可能会“不同步”临时,甚至永远保留单独的产品(想想PHP同时维护他们的PHP4分支,同时也在使用PHP5。在某些时候,他们简单地分支他们的代码库,所以他们开始时完全相同,他们现在可以在不影响另一个的情当然,它也可以尝试将这些分支合并在一起(您可以为产品中的每个主要功能创建一个分支,因此可以隔离开发它们,而不会受到其余代码发生的逐渐变化的影响,然后当功能完成时,将其分支合并回主存储库)
There are two basic kinds of source control tools, the centralized ones and the distributed ones. Distributed are the big new thing, while centralized has been with us for decades. In brief, centralized version control simply means that there is one master repository server, where all branches and the change history for each are stored. This server is responsible for merging checkins and all that. So every time a developer checks code out or commits it to the repository, this is the server he syncs up against. Distributed ones simply ditch the "main server" aspect of this. Instead, every time you check out your code, you create a new repository locally on your own machine, at the path you check out the code to. Then you can work against this local repository, which does all the same things, tracking change history, merging changes and so on, and once you're ready, you can merge your repository into, well, any other repository. Typically, you'll probably want to merge it into some kind of "main" repo where all the code gets glued together, but you can also merge it into your codeveloper's local repo, if perhaps he needs that feature you've been working on, but it's not yet stable enough to go into the main repo. So it gives you a lot more flexibility, and allows you to maintain a change history of your local work, without risking breaking the build at the master repository (in a centralized setup, what happens if you check in something that doesn't compile? The entire team is screwed until it's fixed. And if you don't check it in, you lose the benefits of version control, preventing you from reverting to a previous version if you find out you've been introducing new bugs)
源控制工具有两种基本类型,即集中式和分布式。分布式是一件大事,而集中化已与我们合作数十年。简而言之,集中式版本控制只是意味着有一个主存储库服务器,其中存储了所有分支和每个分支的更改历史记录。此服务器负责合并签入和所有这些。因此,每当开发人员检查代码或将其提交到存储库时,这就是他同步的服务器。分布式的只是放弃了这个“主服务器”的方面。相反,每次检查代码时,都会在您自己的计算机上本地创建一个新的存储库,在您检查代码的路径上。然后,您可以针对此本地存储库进行操作,该存储库执行所有相同的操作,跟踪更改历史记录,合并更改等等,一旦您准备好,您就可以将存储库合并到任何其他存储库中。通常情况下,您可能希望将其合并到某种“主”仓库中,其中所有代码都粘在一起,但您也可以将其合并到您的代码开发人员的本地仓库中,如果他需要您正在处理的功能,但它还不够稳定,不能进入主要的回购。因此,它为您提供了更大的灵活性,并允许您维护本地工作的更改历史记录,而不会破坏主存储库中的构建(在集中式设置中,如果您检入无法编译的内容会发生什么?整个团队都被搞砸了,直到它被修复了。如果你没有检查它,你将失去版本控制的好处,如果你发现你一直在引入新的bug,就会阻止你恢复到以前的版本)
And, finally, what is the best/easiest example of this type of software?
最后,这类软件最好/最简单的例子是什么?
Hm, the most popular is easily SVN, which an old-fashioned centralized system, but it's a bit of a pain to set up imo. Requires special software on the server. I personally am quite fond of Bazaar, which is distributed, and a server repository only requires FTP access and nothing else on the server.
嗯,最流行的很容易SVN,这是一个老式的集中式系统,但是设置imo有点痛苦。需要服务器上的特殊软件。我个人非常喜欢分发的Bazaar,服务器存储库只需要FTP访问,服务器上没有别的东西。
#2
Eric Sink has written a nice Source Control HOWTO.
Eric Sink编写了一个很好的Source Control HOWTO。
Disclaimer: Eric Sink is a principal of SourceGear which develops and sells several source control-related tools (including SourceGear Vault). However, the Source Control HOWTO is a pretty neutral, balanced writeup.
免责声明:Eric Sink是SourceGear的负责人,负责开发和销售多种与源代码控制相关的工具(包括SourceGear Vault)。但是,Source Control HOWTO是一个非常中立,平衡的写法。
#4
Version control systems aren't just for large teams! The individual developer working on a hobby project has much to gain from versioning their code.
版本控制系统不仅适用于大型团队!从事业余爱好项目的个人开发人员可以通过版本化代码获得很多好处。
Most version control systems are centered around the concept of a repository, which is managed by the system and never touched directly. When you want to edit a file, you copy it from the repository, make your changes, then send it back. The version control system identifies the differences between your new version and the old version, then stores your new version in the repository. But, in case you screwed up, the older versions, going all the way back to the beginning, are always retrievable.
大多数版本控制系统都以存储库的概念为中心,存储库由系统管理,从不直接触及。如果要编辑文件,请从存储库中复制文件,进行更改,然后将其发回。版本控制系统识别新版本和旧版本之间的差异,然后将新版本存储在存储库中。但是,如果你搞砸了,旧的版本,一直回到开头,总是可以检索。
Most version control systems are smart enough to merge changes from multiple developers on the same file, as long as the changes don't affect the same part of the file. Merge conflict can occur and cause headaches, however.
大多数版本控制系统足够智能,可以在同一文件上合并来自多个开发人员的更改,只要更改不会影响文件的同一部分。但是,合并冲突可能会发生并导致头痛。
To get started, I recommend you install something simple and free like Subversion and go through their very detailed book which has examples and explanations of the various features, most of which work comparably in other version control systems.
首先,我建议您安装一些像Subversion一样简单且免费的东西,并阅读他们非常详细的书籍,其中包含各种功能的示例和解释,其中大多数功能在其他版本控制系统中相当。
#5
All version control systems are basically the same.. None are any more difficult to use than the other.. svn commit somefile is as difficult as git commit somefile.. They just all work a bit differently.
所有版本控制系统基本相同。没有比其他更难使用.svn commit somefile和git commit somefile一样困难..它们的工作方式略有不同。
The only reason I started using git is because of github. Previous to that the only reason I used SVN over darcs (which has a really nice command-line interface) was because I found a good, free SVN server.
我开始使用git的唯一原因是因为github。之前我使用SVN而不是darcs(它有一个非常好的命令行界面)的唯一原因是因为我发现了一个好的,免费的SVN服务器。
Currently I would recommend git. Not because it's better, or because some other VCS is worse, but because there are lots of really good guides, and lots of really good projects using/based-on it.
目前我会推荐git。不是因为它更好,或者因为其他一些VCS更糟糕,而是因为有很多非常好的指南,以及很多非常好的项目使用/基于它。
Some resources you may find useful:
您可能会发现一些有用的资源:
- GitHub - what convinced me to start using git. It has a very active community, and is very helpful (when you create a new repository, it gives you the commands to push your code to it, for example). They have a good guides section too.
- A free screencast about using GitHub - explains lots of the sites features, and most of the useful basics
- Gitorious - another good git hosting site, for open-source projects (the site itself is open-source too). Not quite as nice to use as GitHub I would say, but a very good alternative.
- repo.or.cz - the first git hosting sites. Pretty archaic looking compared to GitHub/Gitorious, but it works, and hosts
- PeepCode's Git episode - $9, but is regarded very highly. Covers pretty much everything you'd need to know.
- GitCasts - a series of good screencasts. Start with the first one ("Setup, Initialization and Cloning"), and it should cover most useful things.
- GitMagic - extremely useful, especially for slightly more advanced things (It has answered a lot of my "How do I.." questions, like how to create an empty branch). Comprehensive guide (goes from basic stuff to git's internals)
- Git for beginners: The definitive practical guide - a question on * - not exactly comprehensive yet, but it's getting there..
GitHub - 说服我开始使用git的原因。它有一个非常活跃的社区,非常有用(例如,当您创建一个新的存储库时,它会为您提供将代码推送到它的命令)。他们也有很好的指导部分。
关于使用GitHub的免费截屏视频 - 解释了许多网站功能以及大多数有用的基础知识
Gitorious - 另一个优秀的git托管站点,用于开源项目(该站点本身也是开源的)。我不会像GitHub那样好用,但这是一个非常好的选择。
repo.or.cz - 第一个git托管网站。与GitHub / Gitorious相比,它看起来相当古老,但是它可以工作,还有主机
PeepCode的Git剧集 - 9美元,但被认为非常高。几乎涵盖了你需要知道的一切。
GitCasts - 一系列精彩的截屏视频。从第一个开始(“设置,初始化和克隆”),它应该涵盖大多数有用的东西。
GitMagic - 非常有用,特别是对于稍高级的东西(它已经回答了很多我的“我如何...”的问题,比如如何创建一个空分支)。综合指南(从基本内容到git的内部)
适合初学者的Git:最权威的实用指南 - 关于*的问题 - 还不完全全面,但它已经到了那里......
All that said, it's irrelevant what version control system you choose, really..
总而言之,你所选择的版本控制系统无关紧要,真的......
I found darcs really easy to use (both it's CLI, and understanding how darcs get worked to move "patches" between repositories. The "GettingStarted" darcs.net wiki page was about all I needed to get started. The only problem I had was I couldn't find any hosts for darcs projects...
我发现darcs非常容易使用(它都是CLI,并且了解darcs如何在存储库之间移动“补丁”。“GettingStarted”darcs.net wiki页面是我开始所需的全部内容。我遇到的唯一问题是我找不到darcs项目的任何主机......
SVN is easy to use, but it's centralised architecture didn't really fit how I used it, and things like branching (which is trivial in git) is difficult. Almost every action requires communicating with a central server, and I didn't want to run a local SVN server. It also basically doesn't work offline, on a laptop for example.
SVN易于使用,但它的集中式架构并不适合我使用它的方式,而分支(在git中很简单)之类的东西很难。几乎每个动作都需要与*服务器通信,我不想运行本地SVN服务器。它也基本上不能在笔记本电脑上脱机工作。
I started out learning SVN, mainly thanks to "introduction to Subversion screencast". Then when I discovered github I used git svn to import my main SVN repository into git
我开始学习SVN,主要得益于“Subversion截屏视频”。然后,当我发现github时,我使用git svn将我的主要SVN存储库导入到git中
In short: Find a good tutorial or guide for some version control system, and version all those random projects and snippets you have. It'll seem a bit pointless until you accidently make some stupid change and save/close your script, or accidently delete something.. I pretty much use VCS as "super-undo" (and for code synchronisation between computers)
简而言之:为某些版本控制系统找一个好的教程或指南,并版本化所有随机项目和片段。在您意外地进行一些愚蠢的更改并保存/关闭脚本或意外删除某些内容之前,这似乎有点无意义。我几乎使用VCS作为“超级撤消”(并且用于计算机之间的代码同步)
#6
Versioning and Source Control are the same. Well, mostly. Versioning is what Source Control does. It allows you to have multiple versions of a file. Think of it like Wikipedia's revision history. You can go back, see what was done, compare changes, and roll back to previous code.
版本控制和源代码控制是相同的。好吧,主要是。版本控制是Source Control的功能。它允许您拥有多个版本的文件。可以把它想象成*的修订历史。您可以返回,查看已完成的工作,比较更改并回滚到以前的代码。
The program normally uses some proprietary engine to keep tabs on these files (since they're just text, it normally isn't tough), and it keeps track of changes made each time the file is checked back in.
该程序通常使用一些专有引擎来监视这些文件(因为它们只是文本,通常并不困难),并且它会跟踪每次重新检入文件时所做的更改。
If you try to merge a file back in that's been changed, most Source control systems will show you a diff of the files and you can choose to merge it manually or automatically (depending on how powerful your Source control system is).
如果您尝试合并已更改的文件,大多数源控制系统将显示文件的差异,您可以选择手动或自动合并(取决于您的源控制系统的强大程度)。
The easiest example is to download Subversion onto your USB drive, and install Tortoise SVN as well.
最简单的例子是将Subversion下载到您的USB驱动器上,并安装Tortoise SVN。
#7
Here are some answers to your questions:
以下是您的问题的一些答案:
Source control is a place where everyone shares their code. When you want to make a change, you "check out" the code and modify it. While you have it checked out, no one else can make changes to it (thus preventing you from modifying an older version of the file). When you are done, you check the file back into the source control, creating a new version (this is the versioning portion of source control). At any point in time, you can resynchronize your local copy of the code base with the latest versions of all the files, keeping you up to date.
源代码管理是每个人共享代码的地方。如果要进行更改,请“签出”代码并进行修改。当您检出它时,没有其他人可以对其进行更改(从而阻止您修改该文件的旧版本)。完成后,将文件检入源控件,创建新版本(这是源代码管理的版本控制部分)。在任何时候,您都可以将代码库的本地副本与所有文件的最新版本重新同步,从而使您保持最新。
Some software that does this uses a change system. That means that there is a single copy of the file which, whenever it gets checked in, is saved as a sequence of changes to that file. Other systems store multiple copies of the file, and attach version information to the file.
一些执行此操作的软件使用更改系统。这意味着该文件只有一个副本,无论何时签入,都会保存为该文件的一系列更改。其他系统存储文件的多个副本,并将版本信息附加到文件。
If you were to change an older version of the file, and then discover that you worked off an old version (the source control program should notify you when you try to check in your code), then you would have to merge your changes with the newer version. Some source control tools come with a built in merge tool.
如果您要更改文件的旧版本,然后发现您使用旧版本(源代码管理程序应该在您尝试签入代码时通知您),那么您必须将更改与较新的版本。一些源代码控制工具带有内置的合并工具。
#8
Answering the second question you posted:
回答你发布的第二个问题:
SVN requires a centralized repository while Git is decentralized but the majority of the people I know who use it rely on github. Also Git is used for the main trunk of the linux kernel source code so its been optimized a bit more for very large code bases. Also Git seems to have a better handle on branch merging then pre-svn 1.5.x code.
SVN需要一个集中的存储库,而Git是分散的,但我知道使用它的大多数人都依赖于github。此外,Git用于linux内核源代码的主干,因此它针对非常大的代码库进行了优化。此外,Git似乎有更好的处理分支合并然后pre-svn 1.5.x代码。
#9
Versioning doesn't need to be a complicated setup nor something that is only suitable for working in a team environment and it isn't only for coding projects. Anything can go into version control. It's simply a matter of not wanting to lose anything. I version control virtually every file i edit, including everything in my home/ and lots of config files in etc/ and elsewhere and i version everything i do for work (in addition to the versioning provided for the projects). It's such a part of what i do, i think it should be provided by the filesystem.
版本控制不需要是一个复杂的设置,也不一定只适合在团队环境中工作,它不仅适用于编码项目。任何东西都可以进入版本控制。这只是一个不想失去任何东西的问题。我版本控制几乎我编辑的每个文件,包括我家里的所有文件/以及etc /和其他地方的大量配置文件,我版本我为工作做的一切(除了为项目提供的版本控制)。它是我所做的一部分,我认为它应该由文件系统提供。
I recommend starting simple and practice with RCS. Although RCS sucks for teams, it is just fine for managing local user files with only a single author. Don't concern yourself with merges and branches just yet. Learn to think of saving a file as meaning saving a version. Once you're comfortable with RCS and accept the benefit of retaining changes, you can move up to learning SVN or Git or any other real system which are far more robust and better suited for team environments.
我建议开始简单并使用RCS练习。虽然RCS对团队很糟糕,但只管理一个作者就可以管理本地用户文件。暂时不要关注合并和分支。学会将文件保存为保存版本的意义。一旦您对RCS感到满意并接受保留更改的好处,您就可以升级到学习SVN或Git或任何其他更强大且更适合团队环境的真实系统。
#10
Also take a look at the Streamed Lines paper it describes a number of best practices and version control anti-patterns, I'd also second the reference to Erik Sinks articles mentioned by Michael Burr
另外看一下Streamed Lines论文,它描述了一些最佳实践和版本控制反模式,我还要参考Michael Burr提到的Erik Sinks文章。
#1
I've heard you have to check out code (copy the existing code?) and merge it back in (what happens if someone changes code that you didn't change and you change something else and merge it in? Surely, his code is not replaced by your older version.)
我听说你必须检查代码(复制现有代码?)并将其重新合并(如果有人更改了你没有改变的代码并且你改变了其他内容并将其合并,会发生什么?当然,他的代码是没有被旧版本取代。)
That is precisely the reason for version control. It wouldn't really be a very useful tool if all it did was blindly overwrite people's code, would it? ;)
这正是版本控制的原因。如果只是盲目地覆盖人们的代码,那它真的不是一个非常有用的工具,不是吗? ;)
Source control tools maintain a repository with the entire history of the codebase. Every change is checked in as a delta, saving just what has changed. That means that if you and I both check out version A, and I then edit file B, and you edit file C, and we both check in, the source control software will compare the differences and where no conflicts exist (as in this case), just apply both changes, and if conflicts occur (if we both changed the same lines of code), it rejects the attempted check-in and tells you which two versions of the file had conflicting changes, and asks you to merge them manually. (usually it is also able to highlight the changes so you can see visually what has been changed in each version). So it never overwrites changes.
源代码控制工具维护一个存储库,其中包含代码库的整个历史记录。每个更改都以增量形式签入,只保存已更改的内容。这意味着如果你和我都签出版本A,然后我编辑文件B,你编辑文件C,我们都签到,源控制软件将比较差异和没有冲突的地方(如本例所示) ),只应用两个更改,如果发生冲突(如果我们都更改了相同的代码行),它会拒绝尝试的签入并告诉您文件的哪两个版本有相互冲突的更改,并要求您手动合并它们。 (通常它也能够突出显示更改,因此您可以直观地看到每个版本中已更改的内容)。所以它永远不会覆盖变化。
Other tasks it'll do for you is:
它将为您做的其他任务是:
- Tag specific versions or milestones so you can easily find them again later (this is the version where we finally fixed annoying bug #2524, this is beta 1, and so on
- Branch the repository into two, allowing changes that may go "out of sync" temporarliy, or even stay separate products forever (think of PHP simultaneously maintaining their PHP4 branch, while also working on PHP5. At some point they simly branched their codebase so while they started out identical, they can now apply patches to one without affecting the other). Of course it can also attempt to merge these branches back together (you may create a branch for each major feature in your product, perhaps, so they can be developed in isolation without being affected by the gradual changes happening to the rest of the code, and then when the feature is done, merge its branch back into the main repository)
标记特定版本或里程碑,以便您以后可以轻松找到它们(这是我们最终修复烦人的bug#2524的版本,这是beta 1,依此类推
将存储库分成两部分,允许更改可能会“不同步”临时,甚至永远保留单独的产品(想想PHP同时维护他们的PHP4分支,同时也在使用PHP5。在某些时候,他们简单地分支他们的代码库,所以他们开始时完全相同,他们现在可以在不影响另一个的情当然,它也可以尝试将这些分支合并在一起(您可以为产品中的每个主要功能创建一个分支,因此可以隔离开发它们,而不会受到其余代码发生的逐渐变化的影响,然后当功能完成时,将其分支合并回主存储库)
There are two basic kinds of source control tools, the centralized ones and the distributed ones. Distributed are the big new thing, while centralized has been with us for decades. In brief, centralized version control simply means that there is one master repository server, where all branches and the change history for each are stored. This server is responsible for merging checkins and all that. So every time a developer checks code out or commits it to the repository, this is the server he syncs up against. Distributed ones simply ditch the "main server" aspect of this. Instead, every time you check out your code, you create a new repository locally on your own machine, at the path you check out the code to. Then you can work against this local repository, which does all the same things, tracking change history, merging changes and so on, and once you're ready, you can merge your repository into, well, any other repository. Typically, you'll probably want to merge it into some kind of "main" repo where all the code gets glued together, but you can also merge it into your codeveloper's local repo, if perhaps he needs that feature you've been working on, but it's not yet stable enough to go into the main repo. So it gives you a lot more flexibility, and allows you to maintain a change history of your local work, without risking breaking the build at the master repository (in a centralized setup, what happens if you check in something that doesn't compile? The entire team is screwed until it's fixed. And if you don't check it in, you lose the benefits of version control, preventing you from reverting to a previous version if you find out you've been introducing new bugs)
源控制工具有两种基本类型,即集中式和分布式。分布式是一件大事,而集中化已与我们合作数十年。简而言之,集中式版本控制只是意味着有一个主存储库服务器,其中存储了所有分支和每个分支的更改历史记录。此服务器负责合并签入和所有这些。因此,每当开发人员检查代码或将其提交到存储库时,这就是他同步的服务器。分布式的只是放弃了这个“主服务器”的方面。相反,每次检查代码时,都会在您自己的计算机上本地创建一个新的存储库,在您检查代码的路径上。然后,您可以针对此本地存储库进行操作,该存储库执行所有相同的操作,跟踪更改历史记录,合并更改等等,一旦您准备好,您就可以将存储库合并到任何其他存储库中。通常情况下,您可能希望将其合并到某种“主”仓库中,其中所有代码都粘在一起,但您也可以将其合并到您的代码开发人员的本地仓库中,如果他需要您正在处理的功能,但它还不够稳定,不能进入主要的回购。因此,它为您提供了更大的灵活性,并允许您维护本地工作的更改历史记录,而不会破坏主存储库中的构建(在集中式设置中,如果您检入无法编译的内容会发生什么?整个团队都被搞砸了,直到它被修复了。如果你没有检查它,你将失去版本控制的好处,如果你发现你一直在引入新的bug,就会阻止你恢复到以前的版本)
And, finally, what is the best/easiest example of this type of software?
最后,这类软件最好/最简单的例子是什么?
Hm, the most popular is easily SVN, which an old-fashioned centralized system, but it's a bit of a pain to set up imo. Requires special software on the server. I personally am quite fond of Bazaar, which is distributed, and a server repository only requires FTP access and nothing else on the server.
嗯,最流行的很容易SVN,这是一个老式的集中式系统,但是设置imo有点痛苦。需要服务器上的特殊软件。我个人非常喜欢分发的Bazaar,服务器存储库只需要FTP访问,服务器上没有别的东西。
#2
Eric Sink has written a nice Source Control HOWTO.
Eric Sink编写了一个很好的Source Control HOWTO。
Disclaimer: Eric Sink is a principal of SourceGear which develops and sells several source control-related tools (including SourceGear Vault). However, the Source Control HOWTO is a pretty neutral, balanced writeup.
免责声明:Eric Sink是SourceGear的负责人,负责开发和销售多种与源代码控制相关的工具(包括SourceGear Vault)。但是,Source Control HOWTO是一个非常中立,平衡的写法。
#3
I believe this article explains the answers to most of your questions.
我相信这篇文章解释了大多数问题的答案。
#4
Version control systems aren't just for large teams! The individual developer working on a hobby project has much to gain from versioning their code.
版本控制系统不仅适用于大型团队!从事业余爱好项目的个人开发人员可以通过版本化代码获得很多好处。
Most version control systems are centered around the concept of a repository, which is managed by the system and never touched directly. When you want to edit a file, you copy it from the repository, make your changes, then send it back. The version control system identifies the differences between your new version and the old version, then stores your new version in the repository. But, in case you screwed up, the older versions, going all the way back to the beginning, are always retrievable.
大多数版本控制系统都以存储库的概念为中心,存储库由系统管理,从不直接触及。如果要编辑文件,请从存储库中复制文件,进行更改,然后将其发回。版本控制系统识别新版本和旧版本之间的差异,然后将新版本存储在存储库中。但是,如果你搞砸了,旧的版本,一直回到开头,总是可以检索。
Most version control systems are smart enough to merge changes from multiple developers on the same file, as long as the changes don't affect the same part of the file. Merge conflict can occur and cause headaches, however.
大多数版本控制系统足够智能,可以在同一文件上合并来自多个开发人员的更改,只要更改不会影响文件的同一部分。但是,合并冲突可能会发生并导致头痛。
To get started, I recommend you install something simple and free like Subversion and go through their very detailed book which has examples and explanations of the various features, most of which work comparably in other version control systems.
首先,我建议您安装一些像Subversion一样简单且免费的东西,并阅读他们非常详细的书籍,其中包含各种功能的示例和解释,其中大多数功能在其他版本控制系统中相当。
#5
All version control systems are basically the same.. None are any more difficult to use than the other.. svn commit somefile is as difficult as git commit somefile.. They just all work a bit differently.
所有版本控制系统基本相同。没有比其他更难使用.svn commit somefile和git commit somefile一样困难..它们的工作方式略有不同。
The only reason I started using git is because of github. Previous to that the only reason I used SVN over darcs (which has a really nice command-line interface) was because I found a good, free SVN server.
我开始使用git的唯一原因是因为github。之前我使用SVN而不是darcs(它有一个非常好的命令行界面)的唯一原因是因为我发现了一个好的,免费的SVN服务器。
Currently I would recommend git. Not because it's better, or because some other VCS is worse, but because there are lots of really good guides, and lots of really good projects using/based-on it.
目前我会推荐git。不是因为它更好,或者因为其他一些VCS更糟糕,而是因为有很多非常好的指南,以及很多非常好的项目使用/基于它。
Some resources you may find useful:
您可能会发现一些有用的资源:
- GitHub - what convinced me to start using git. It has a very active community, and is very helpful (when you create a new repository, it gives you the commands to push your code to it, for example). They have a good guides section too.
- A free screencast about using GitHub - explains lots of the sites features, and most of the useful basics
- Gitorious - another good git hosting site, for open-source projects (the site itself is open-source too). Not quite as nice to use as GitHub I would say, but a very good alternative.
- repo.or.cz - the first git hosting sites. Pretty archaic looking compared to GitHub/Gitorious, but it works, and hosts
- PeepCode's Git episode - $9, but is regarded very highly. Covers pretty much everything you'd need to know.
- GitCasts - a series of good screencasts. Start with the first one ("Setup, Initialization and Cloning"), and it should cover most useful things.
- GitMagic - extremely useful, especially for slightly more advanced things (It has answered a lot of my "How do I.." questions, like how to create an empty branch). Comprehensive guide (goes from basic stuff to git's internals)
- Git for beginners: The definitive practical guide - a question on * - not exactly comprehensive yet, but it's getting there..
GitHub - 说服我开始使用git的原因。它有一个非常活跃的社区,非常有用(例如,当您创建一个新的存储库时,它会为您提供将代码推送到它的命令)。他们也有很好的指导部分。
关于使用GitHub的免费截屏视频 - 解释了许多网站功能以及大多数有用的基础知识
Gitorious - 另一个优秀的git托管站点,用于开源项目(该站点本身也是开源的)。我不会像GitHub那样好用,但这是一个非常好的选择。
repo.or.cz - 第一个git托管网站。与GitHub / Gitorious相比,它看起来相当古老,但是它可以工作,还有主机
PeepCode的Git剧集 - 9美元,但被认为非常高。几乎涵盖了你需要知道的一切。
GitCasts - 一系列精彩的截屏视频。从第一个开始(“设置,初始化和克隆”),它应该涵盖大多数有用的东西。
GitMagic - 非常有用,特别是对于稍高级的东西(它已经回答了很多我的“我如何...”的问题,比如如何创建一个空分支)。综合指南(从基本内容到git的内部)
适合初学者的Git:最权威的实用指南 - 关于*的问题 - 还不完全全面,但它已经到了那里......
All that said, it's irrelevant what version control system you choose, really..
总而言之,你所选择的版本控制系统无关紧要,真的......
I found darcs really easy to use (both it's CLI, and understanding how darcs get worked to move "patches" between repositories. The "GettingStarted" darcs.net wiki page was about all I needed to get started. The only problem I had was I couldn't find any hosts for darcs projects...
我发现darcs非常容易使用(它都是CLI,并且了解darcs如何在存储库之间移动“补丁”。“GettingStarted”darcs.net wiki页面是我开始所需的全部内容。我遇到的唯一问题是我找不到darcs项目的任何主机......
SVN is easy to use, but it's centralised architecture didn't really fit how I used it, and things like branching (which is trivial in git) is difficult. Almost every action requires communicating with a central server, and I didn't want to run a local SVN server. It also basically doesn't work offline, on a laptop for example.
SVN易于使用,但它的集中式架构并不适合我使用它的方式,而分支(在git中很简单)之类的东西很难。几乎每个动作都需要与*服务器通信,我不想运行本地SVN服务器。它也基本上不能在笔记本电脑上脱机工作。
I started out learning SVN, mainly thanks to "introduction to Subversion screencast". Then when I discovered github I used git svn to import my main SVN repository into git
我开始学习SVN,主要得益于“Subversion截屏视频”。然后,当我发现github时,我使用git svn将我的主要SVN存储库导入到git中
In short: Find a good tutorial or guide for some version control system, and version all those random projects and snippets you have. It'll seem a bit pointless until you accidently make some stupid change and save/close your script, or accidently delete something.. I pretty much use VCS as "super-undo" (and for code synchronisation between computers)
简而言之:为某些版本控制系统找一个好的教程或指南,并版本化所有随机项目和片段。在您意外地进行一些愚蠢的更改并保存/关闭脚本或意外删除某些内容之前,这似乎有点无意义。我几乎使用VCS作为“超级撤消”(并且用于计算机之间的代码同步)
#6
Versioning and Source Control are the same. Well, mostly. Versioning is what Source Control does. It allows you to have multiple versions of a file. Think of it like Wikipedia's revision history. You can go back, see what was done, compare changes, and roll back to previous code.
版本控制和源代码控制是相同的。好吧,主要是。版本控制是Source Control的功能。它允许您拥有多个版本的文件。可以把它想象成*的修订历史。您可以返回,查看已完成的工作,比较更改并回滚到以前的代码。
The program normally uses some proprietary engine to keep tabs on these files (since they're just text, it normally isn't tough), and it keeps track of changes made each time the file is checked back in.
该程序通常使用一些专有引擎来监视这些文件(因为它们只是文本,通常并不困难),并且它会跟踪每次重新检入文件时所做的更改。
If you try to merge a file back in that's been changed, most Source control systems will show you a diff of the files and you can choose to merge it manually or automatically (depending on how powerful your Source control system is).
如果您尝试合并已更改的文件,大多数源控制系统将显示文件的差异,您可以选择手动或自动合并(取决于您的源控制系统的强大程度)。
The easiest example is to download Subversion onto your USB drive, and install Tortoise SVN as well.
最简单的例子是将Subversion下载到您的USB驱动器上,并安装Tortoise SVN。
#7
Here are some answers to your questions:
以下是您的问题的一些答案:
Source control is a place where everyone shares their code. When you want to make a change, you "check out" the code and modify it. While you have it checked out, no one else can make changes to it (thus preventing you from modifying an older version of the file). When you are done, you check the file back into the source control, creating a new version (this is the versioning portion of source control). At any point in time, you can resynchronize your local copy of the code base with the latest versions of all the files, keeping you up to date.
源代码管理是每个人共享代码的地方。如果要进行更改,请“签出”代码并进行修改。当您检出它时,没有其他人可以对其进行更改(从而阻止您修改该文件的旧版本)。完成后,将文件检入源控件,创建新版本(这是源代码管理的版本控制部分)。在任何时候,您都可以将代码库的本地副本与所有文件的最新版本重新同步,从而使您保持最新。
Some software that does this uses a change system. That means that there is a single copy of the file which, whenever it gets checked in, is saved as a sequence of changes to that file. Other systems store multiple copies of the file, and attach version information to the file.
一些执行此操作的软件使用更改系统。这意味着该文件只有一个副本,无论何时签入,都会保存为该文件的一系列更改。其他系统存储文件的多个副本,并将版本信息附加到文件。
If you were to change an older version of the file, and then discover that you worked off an old version (the source control program should notify you when you try to check in your code), then you would have to merge your changes with the newer version. Some source control tools come with a built in merge tool.
如果您要更改文件的旧版本,然后发现您使用旧版本(源代码管理程序应该在您尝试签入代码时通知您),那么您必须将更改与较新的版本。一些源代码控制工具带有内置的合并工具。
#8
Answering the second question you posted:
回答你发布的第二个问题:
SVN requires a centralized repository while Git is decentralized but the majority of the people I know who use it rely on github. Also Git is used for the main trunk of the linux kernel source code so its been optimized a bit more for very large code bases. Also Git seems to have a better handle on branch merging then pre-svn 1.5.x code.
SVN需要一个集中的存储库,而Git是分散的,但我知道使用它的大多数人都依赖于github。此外,Git用于linux内核源代码的主干,因此它针对非常大的代码库进行了优化。此外,Git似乎有更好的处理分支合并然后pre-svn 1.5.x代码。
#9
Versioning doesn't need to be a complicated setup nor something that is only suitable for working in a team environment and it isn't only for coding projects. Anything can go into version control. It's simply a matter of not wanting to lose anything. I version control virtually every file i edit, including everything in my home/ and lots of config files in etc/ and elsewhere and i version everything i do for work (in addition to the versioning provided for the projects). It's such a part of what i do, i think it should be provided by the filesystem.
版本控制不需要是一个复杂的设置,也不一定只适合在团队环境中工作,它不仅适用于编码项目。任何东西都可以进入版本控制。这只是一个不想失去任何东西的问题。我版本控制几乎我编辑的每个文件,包括我家里的所有文件/以及etc /和其他地方的大量配置文件,我版本我为工作做的一切(除了为项目提供的版本控制)。它是我所做的一部分,我认为它应该由文件系统提供。
I recommend starting simple and practice with RCS. Although RCS sucks for teams, it is just fine for managing local user files with only a single author. Don't concern yourself with merges and branches just yet. Learn to think of saving a file as meaning saving a version. Once you're comfortable with RCS and accept the benefit of retaining changes, you can move up to learning SVN or Git or any other real system which are far more robust and better suited for team environments.
我建议开始简单并使用RCS练习。虽然RCS对团队很糟糕,但只管理一个作者就可以管理本地用户文件。暂时不要关注合并和分支。学会将文件保存为保存版本的意义。一旦您对RCS感到满意并接受保留更改的好处,您就可以升级到学习SVN或Git或任何其他更强大且更适合团队环境的真实系统。
#10
Also take a look at the Streamed Lines paper it describes a number of best practices and version control anti-patterns, I'd also second the reference to Erik Sinks articles mentioned by Michael Burr
另外看一下Streamed Lines论文,它描述了一些最佳实践和版本控制反模式,我还要参考Michael Burr提到的Erik Sinks文章。