我几乎每天都会读这样的内容，其中大部分都是关于源代码控制的主题。我有几个问题。我将使用 SVN 作为示例。
1）有一个团队（小，大都没关系）。早上大家检查代码开始工作。中午，A 提交，而 B 仍在努力。当 B 做出承诺时会发生什么？ B 如何知道有更新的文件？
2) 我假设第一个问题的答案是“运行一个告诉你的更新命令”，好吧，所以 B 发现他们整个上午都在处理的文件发生了变化。当他们看到更新的文件时，似乎 A 已经重写了该文件以获得更好的性能。 B 做什么？看来一整天都是浪费时间。或者如果他们提交了他们的版本，那么这就是浪费 A 的时间？
3）什么是分支机构？
谢谢，如果有人知道外行术语 pdf 或解释它的东西，那就太棒了。
I read SO nearly everyday and mostly there is a thread about source control. I have a few questions. I am going to use SVN as example.
1) There is a team (small, large dosnt matter). In the morning everyone checks out the code to start working. At noon Person A commits, while person B still works on it. What happens when person B commits? how will person B know that there is an updated file?
2) I am assuming the answer to the first question is "run an update command which tells you", ok so person B finds out that the file they have been working on all morning in changed. When they see the udpated file, it seems like person A has REWRITTEN the file for better performance. What does person B do? Seems like there whole day was a waste of time. Or if they commit their version then its a waste of person A's time?
3) What are branches?
thanks, and if anyone knows a laymen terms pdf or something that explains it that would be awesome.
发布评论
评论（13）
2) 此时，B 必须将 A 所做的更改与他自己的更改合并。如果他们处理了文件中代码的不同部分，源代码控制工具通常可以自动执行此操作。如果它们的更改重叠，这可能会成为一项相当令人讨厌的任务，但这种情况很少发生。
3）分支就像存储库的一部分的副本，您可以在其上与开发主线分开工作（提交更改） - 这对于各种目的都很有用，例如当您有想要的旧版本时提供错误修复，而不强迫用户更新到当前版本（大多数大型软件项目都会这样做）。
2) At this point, B has to merge the changes A has made with his own changes. If they have worked on different parts of the code in the file, the source control tool can generally do this automatically. If their changes overlap, it can become a pretty odious task, but this happens rarely.
3) A branch is like a copy of a part of the repository on which you can work (commit changes) separately from the main line of development - this can be useful for all kinds of purposes, e.g. when you have old releases that you want to provide bugfixes for without forcing users to update to the current version (most large software projects do this).
我猜你需要阅读更多有关 SCM 之类的工具的内容。您怀疑的这种操作在开发环境中非常常见。以下是我对 SVN 和 Git 书籍的建议：
好读:-)
I gess you need read more about SCM like tools. This operations you have doubt are very much common in a development enviroment. Here goes my suggestions about SVN and Git books:
Good read :-)
我下面所说的对于 svn 是有效的，对于 git 或 Mercurial 来说，事情略有不同（我会说更容易）。
1) B 应该在提交之前更新并合并他自己的本地副本中的更改（她也可以检查）强>如果有变化）。如果他只是尝试提交，她将收到一条消息，指出他的本地 svn 副本已过期。
2) B 遇到了一些麻烦，因为合并并不容易（它不会由 SVN 自动管理，它会冲突）...如果真的太难了，B 就不得不考虑她了再次改变。
这个问题确实没有解决办法。某些版本控制系统允许某种类型的锁定，但它会引发其他问题（文件可能会长时间保持锁定状态，并且储物柜旁边的任何人都无法在其间对其进行操作，即使对于很容易合并的更改也是如此）。只需经常进行小的更改并与其他编码人员交谈（通过真正的会议、IRC、电子邮件或任何其他方式）即可避免这种情况发生。
3）分支对于分布式版本控制系统非常有用。它以损坏的版本存在于 svn 中。只需在另一个目录中复制当前存储库的当前目录，这两个目录就会各自发展自己的生命周期（比如说，一个目录仅用于错误修复，另一个目录用于新功能和演变），并且在某些时候您尝试合并两个存储库之间的更改，例如尝试将错误修复移植到新功能分支中，或者将新分支的某些新功能向后移植到旧分支中。
What I say below is valid for svn, for git or mercurial things are slighly different (i would say easier).
1) Person B should update and merge changes within his own local copy before commit-ing (she can also just check if there is changes). If he just tries to commit she will get a message stating that his local svn copy is out of date.
2) Person B is in some trouble as the merge will not be easy (it will not be managed automatically by SVN, it will conflict)... if it's really too difficult B will have to think her changes again.
This problem does not really have a solution. Some versioning system allow some kind of lock but it raise other problems (a file could stay locked for a long time and nobody beside the locker can work on it in between even for chages that would easily merge). Just commit often small changes and speak with other coders (by real meeting, IRC, e-mail or any other mean) to avoid that to happen.
3) Branching is really usefull with distributed version control system. It exists in svn in a maimed version. Merely you make a copy of the current dir of the current repo in another directory, the two directory evolve each with his own life-cycle (say one frozen for bugfixes only and the other for new features and evolutions) and at some point you try to merge changes between the two repos, like trying to port bugfix in new features branch, or backporting some new feature of the new branch in the old one.
在 SVN 中，当 B 尝试更新其副本或签入时，B 将知道 A 的更改。在 GIT 中，他会在尝试将更改拉取到本地存储库或将其更改推送到 master 时发现。 （实际上，我不了解 GIT，所以我将继续我对 Mercurial 的了解。）
在这种情况下，无论你做什么，无论使用什么版本，都会遇到问题控制你使用。锁定 VCS 的唯一优点是它会让 A 或 B 知道对方正在处理该程序，但这可以通过其他方式来完成。正确的做法是让每个人都意识到正在发生的巨大变化，并据此进行协调。但实际上，这种情况并不经常发生。大多数时候，如果 A 和 B 正在处理一个文件，他们的更改将轻松且正确地合并。
分支是不同的“最新版本”，因此并非每个人都必须始终在同一行代码开发上工作。
分支的一种用途是开发一项功能或其他需要很长时间的功能，而不会因部分提交而扰乱主线。
另一个是维护发布版本。不要向客户提供最新版本（可能无法完全工作，并且可能包含客户尚未付费的功能）来修复错误，而是在发布分支上修复错误并发布该版本。这对客户的干扰要小得多。 （只要确保头部版本上的错误也得到修复即可。）
In SVN, B will know of A's change when B tries to update his copy or check in. In GIT, he'll find out when he tries to pull changes into his local repository or push his changes to the master. (Actually, I don't know GIT, so I'm going on what I know of Mercurial.)
In a case like that, you've got problems no matter what you do, and no matter what sort of version control you use. The only advantage of locking VCSs is that it will let A or B know that the other is working on the program, but that can be done in other ways. The proper thing to do is to have everybody aware of large changes taking place, and coordinate from there. In practice, though, this does not happen frequently. Most of the time, if A and B are working on a file their changes will merge easily and correctly.
A branch is a different "latest version", so not everybody has to work on the same line of code development all the time.
One use of branches is to develop a feature or something else that will take a long time, without messing up the main line with partial commits.
Another is to maintain release versions. Instead of shipping the customer the latest version (which may not entirely work, and may contain features the customer hasn't paid for) to fix a bug, fix the bug on the release branch and ship that. It's a lot less disruptive to the customer. (Just make sure the bug is fixed on the head version, also.)
我强烈推荐 Eric Sink 的 Source Control HOWTO。
它将为您提供所需的答案，并总体上很好地理解源代码控制。
I cannot recommend enough Eric Sink's Source Control HOWTO.
It will give you the answers you seek and a good understanding of source control in general.
1）假设有一个中央存储库（SVN和CVS就是这种情况，但不一定是Git，Bazaar，Mercurial等），并且A进行提交（然后push提交，这只是传输diff和commit消息到中央存储库），B 应该手动更新它的副本。
2）在这种情况下，是的，有人会浪费时间。 SCM 系统（源代码控制管理）无法解决团队的组织问题。这当然是一个极端的例子。大多数时候，每次提交只会有微小的差异（这里的微小的定义是任何特定的文件不应该被完全或部分重写），并且如果这些修改没有触及 B 正在处理的部分， SCM 软件将能够将这些提交合并到一个工作文件中。
这里的另一种情况是两个人更改同一文件的同一区域（例如，一个函数）。当发生此类冲突时，SCM 软件将帮助您选择将使用哪些更改，甚至让您同时使用或都不使用。
3) 分支是一条提交历史线：
这里，master 的 >B。在提交
feature、master和bugfix是分支，字母是具体的提交。对于分支master，最新提交（每个文件的最新版本）是F。另一方面，分支feature的最新提交是T并且它仅包含提交A和C、D、E和F中所做的任何更改都不包含在该特定分支中。它可以重写为：现在，分支对于将工作流程划分为不同的部分，并将工作集中在特定部分非常重要。想象一下分支
master是稳定代码所在的位置，并想象我们正在分支feature上实现一个新功能，该功能尚未准备好发布。现在想象一下插件系统已更改，并且重要的错误修复已提交到master分支，并且由于我正在实现的功能依赖于插件系统，因此我需要转移这些提交（>C到F）到分支feature。为此，您向 SCM 软件发出rebase（我在这里使用 Git 作为指导）命令，这样：现在您已经完成了分支
feature。要将提交R、S和T传输到master，您可以发出merge命令：这是分支基础知识。您还可以对分支执行许多其他很酷的操作。希望不会太长并且有帮助：P
1) Assuming there is a central repository (which is the case of SVN and CVS, but not necessarily Git, Bazaar, Mercurial, etc.), and person A commits (and then push the commit, which just transfers the diffs and commit messages to the central repository), person B should update it's copy manually.
2) In this case, yes, someone will have their time gone to waste. SCM systems (Source Control Management) can't do anything to cure a team from it's organizational problems. This is of course an extreme case. Most of the time, there will be only minor differences (the definition of minor here is that any specific file should not be completely or partially rewritten) on each commit, and if those modifications don't touch the section person B is working on, the SCM software will be able to combine those commits into one working file.
Another case here is when two people change the same area of the same file (say, a function). When such conflict happens, the SCM sofware will help you choose which changes you'll use, or even let you use both or neither.
3) A branch is a commit history line:
Here,
feature,masterandbugfixare branches, and letters are specific commits. For branchmaster, the newest commit (the most recent version of each file) isF. On the other way, branchfeature's newest commit isTand it includes only commitsAandBfrom branchmaster. Any changes made in commitsC,D,EandFaren't included in that specific branch. It can be rewritten as:Now, branches are important to divide the workflow into different compartments, and focus the work on specific parts. Imagine branch
masteris where the stable code is located, and imagine we're implementing a new feature on branchfeature, which is not yet ready for release. Now imagine that the plugin system is changed, and important bugfixes are commited to themasterbranch, and, because the feature I'm implementing relies on the plugin system, I need to transfer those commits (CthroughF) to branchfeature. To do that you issue arebase(I'm using Git as guide here) command to you SCM software, so that:So now you've finished all work on branch
feature. To transfer commitsR,SandTtomaster, you issue amergecommand:That's the branch basics. There are lots of other cool things you can do to branches. Hope that is not too long and helps :P
1 && 2）
SVN：当B尝试提交时，会出现错误，说他没有最新版本的代码。他需要执行
svn update并将 A 所做的更改与他自己所做的更改合并。请参阅如何解决 SVN 冲突。GIT：因为你有自己的本地存储库，所以你可以自由提交。当您将更改推送 (
git push) 到远程存储库时，您必须合并。请参阅解决 GIT 中的合并冲突3) 分支 Wiki 页面
1 && 2)
SVN: When B tries to commit, there will be an error saying that he does not have the latest version of the code. He'll need to do an
svn updateand merge the changes that person A has done with his own. See How to Resolve SVN conflicts.GIT: Because you have your own local repository, you can commit freely. It's when you push (
git push) your changes to the remote repository that you have to merge. See Resolving Merge Conflicts in GIT3) Branching Wiki Page
作为补充说明，如果您计划完全重写文件，通常有礼貌的是让从事相同功能的团队成员知道避免合并带来的痛苦。
As an added note, if you're planning on completely rewriting a file, it's often polite to let team members working on the same functionality know to avoid pain-in-the-tuckus merges.
1 & 2 取决于您使用的源代码管理，但必须执行某种合并。分支是从主干（主版本）分叉出来的代码版本。
1 & 2 depend on the source control that you use, but there is some kind of merge that must be performed. And branches are versions of the code that have been forked from the trunk (main version).
我会说，经常承诺。在每次提交之前，更新。
我建议阅读这份文档，它很好地解释了集中式和分散式（更好）版本控制系统的不同可能工作流程：http://wiki.bazaar.canonical.com/Workflows
I'd say, commit often. And before each commit, update.
I'd recommend reading this document, it explains pretty well the different possible workflows of centralized and decentralized (way better) version control systems: http://wiki.bazaar.canonical.com/Workflows
对于 Git 来说，你基本上将整个项目从“master”分支复制到你自己的个人分支中，你可以在其中修改并将更改提交到你自己的个人分支，如果你认为它很好，你可以将你的个人分支与主分支合并。
Well for Git, you basically copy the entire project from the "master" branch into your own personal branch, where you can modify and commit changes to your own personal branch and if you think its good you can merge your personal branch with the master one.