版本控制系统(译文)3 - 签入
译：只是路过
原文:http://software.ericsink.com/scm/scm_checkins.html
( 由于粘贴的文档没有图片，因此在某些地方请参考原文。)
Chapter 2: Checkins
第二章：签入
In this chapter, I will explore the various situations wherein a repository is modified, starting with the simplest case of a single developer making a change to a single file.
这一章我将探讨一下在数据库里面进行修改的各种情况，从开发人员对一个单独文件进行变化的例子讲起。
Editing a single file
编辑一个单独的文件
Consider the simple situation where a developer needs to make a change to one source file. This case is obviously rather simple:
1. Checkout the file
2. Edit the working file as needed
3. Checkin the file
考虑一下开发人员需要对一个源文件进行变化的最简单的情况，步骤相当简单：
1. 签出一个文件
2. 编辑文件中需要修改的地方
3. 签入一个文件
I won't talk much about step 2 here, as it doesn't really involve the SCM tool directly. Editing the file usually involves the use of some other tools, like an integrated development environment (IDE).
But I do want to explore steps 1 and 3 in greater detail.
对于第二步我不会在这里讲很多，因为它不是真正的属于配置管理工具所需要考虑的范围。修该文件通常涉及到使用其他的工具，比如一个集成开发环境（IDE）。
但是我想对第一步和第三步最更近一步的探讨。
Step 1: Checkout
Checking out a file has two basic effects:
- On the server, the SCM tool will remember the fact that you have the file checked out so that others may be informed.
- On your client, the SCM tool will prepare your working file for editing by changing it to be writable.
步骤1：签出
签出一个文件会有两个基本的影响：
l 在服务器上，配置管理工具将记住你对文件的签出，其他的人也就都知道该文件当前的状态了。
l 在客户端，配置管理工具为开发人员要编辑工作文件而将文件的状态变更为可写。
The server side of checkout
服务器端的签出
File checkouts are a way of communicating your intentions to others. When you have a file checked out, other users can be aware and avoid making changes to that file until you are done with it. The checkout status of a file is usually displayed somewhere in the user interface of the SCM client application. For example, in the following screendump from Vault, users can see that I have checked out libsgdcore.cpp:
文件签出是一个同其他团队成员进行交流的方式。当你将一个文件签出，其他用户就会明白和避免去改变那个文件，直到你完成签出为止。文件的签出状态通常是显示在配置管理工具的客户端用户界面上。例如，在下面这个Vault截图中，用户可以看到我已经签出了libsgdcore.cpp这个文件。
Best Practice: Use checkouts and locks carefully
最佳实践：小心使用签出和锁定
It is best to use checkouts and locks only when you need them. A checkout discourages others from modifying a file, and a lock prevents them from doing so. You should therefore be careful to use these features only when you actually need them.
最好只在你需要的时候才签出和锁定文件。签出妨碍了别人修改文件，即一个锁阻止别人对文件的修改。因此，你应该小心的使用这些功能，只在你真正需要的时候才这样做。
Don't checkout files just because you think you might need to edit them.
当你认为你可能要修改文件的时候才去签出。
Don't checkout whole folders. Checkout the specific files you need.
不要签出这个文件夹。签出你需要的那个文件就好了。
Don't checkout hundreds or thousands of files at one time.
不要一次性签出成百上千的文件。
Don't hold exclusive locks any longer than necessary.
在不必要的时候不要再保持独立锁。
Don't go on vacation while holding exclusive locks on files.
对文件进行锁定之后不要跑去休假。
This screendump also hints at the fact there are actually two kinds of checkouts. The issue here is the question of whether two people can checkout a file at the same time. The answer varies across SCM tools. Some SCM tools can be configured to behave either way.
这幅截图也暗示了一个事实：有两种签出的方式。这个问题在这里就是：是否两个人可以在同一时间签出同一个文件。答案对于配置管理工具而言是各种各样。一些配置管理工具可以通过设置来满足所有这些方式。
Sometimes the SCM tool will allow multiple people to checkout a file at the same time. SourceSafe and Vault both offer this capability as an option. When this "multiple checkouts" feature is used, things can get a bit more complicated. I'll talk more about this later.
有的时候配置管理工具将允许多人同时取出一个文件，SourceSafe和 Vault都提供选项设置执行这个功能。当“多重签出”这个特殊功能被使用的时候，事情就变得稍微复杂些了。我将会在后面做更多描述。
If the SCM tool prevents anyone else from checking out a file which I have checked out, then my checkout is "exclusive" and may be described as a "lock". In the screendump above, the user interface is indicating that I have an exclusive lock on libsgdcore.cpp. Vault will allow no one else to checkout this file.
如果配置管理工具阻止任何人在我签出的时候再来签出，那我的签出就是“独立的、排它性的”，然后加了一把锁。在截图上面，用户界面指出我在libsgdcore.cpp文件上拥有了一个独立的锁。Vault 将拒绝其他任何人再来签出这个文件。
The client side of checkout
客户端的签出
On the client side, the effect of a checkout is quite simple: If necessary, the latest version of the file is retrieved from the server. The working file is then made writable, if it was not in that state already.
在客户端，签出的影响非常简单：如果有必要，从服务器签出得到文件的最后一个版本。然后要修改的文件必然都变得可写。
All of the files in a working folder are made read-only when the SCM tool retrieves them from the repository. A file is not made writable until it is checked out. This prevents the developer from accidentally editing a file.
当配置管理工具从配置库中取出一个工作目录下的所有文件的时候，他们都是只读的。一个文件在签出前是不会变为可写的。这就防止了开发人员不经意的修改一个文件。
Undoing a checkout
取消签出
Normally, a checkout ends when a checkin happens. However, sometimes we checkout a file and subsequently decide that we did not need to do so. When this happens, we "undo the checkout". Most SCM tools have a command which offers this functionality. On the server side, the command will remove the checkout and release any exclusive lock that was being held. On the client side, Vault offers the user three choices for how the working file should be treated:
通常，一个签入的开始就是一个签出的结束。然而，有的时候我们签出一个文件随后却发现我们不想那样做。遇到这种时候，我们“取消签出”。绝大多数配置管理工具都有这样一个命令针对这种情况。在服务器端，这个命令将删除掉签出，释放独立锁的控制。在客户端，对于如何处理工作文件，Vault给了用户三种选择：
- Revert: Put the working file back in the state it was in when I checked it out. Any changes I made while I had the file checked out will be lost.
- Leave: Leave the working file alone. This option will effectively leave the file in a state which we call "Renegade". It is a bad idea to edit a file without checking it out. When I do so, Vault notices my transgression and chastises me by letting me know that the file is "Renegade".
- Delete: Delete the working file.
I usually prefer to work with "Revert" as my option for how the Undo Check Out command behaves.
l 重置：将签出的文件恢复到签出前的状态。用户所做的任何变化都将被撤销掉。
l 移走：本功能把文件保留在一个"不一致"状态，不签出文件而去对文件进行修改是不安全的。如果用户这样做了，那么他应该会得到该文件处于"不一致"状态的提示和警告。
l 删除：删除这个文件。
当“取消签出”命令可用的时候我通常宁愿选择“恢复”。
Step 3: Checkin
步骤3:签入
Best Practice: Explain your checkins completely
最佳实践：彻底的解释你的签入
Every SCM tool provides a way to associate a comment when checking changes into the repository. This comment is important. If we consistently use good checkin comments, our repository's history contains not only every change we have ever made, but it also contains an explanation of why those changes happened. These kinds of records can be invaluable later as we forget things.
当检查到配置库中有变化的时候，每个配置管理工具都提供一种方式来将变化和注释联系到一起。注释相当重要。如果我们坚持使用签入的注释，我们的配置库的历史包含的将不只是我们曾经制造的变化的历史，而是还包含了为什么这些变化要发生的解释。这些记录对我们以后遗忘事情时的价值是不可估量的。
I believe developers should be encouraged to enter checkin comments which are as long as necessary to explain what is going on. Don't just type "minor change". Tell us what the minor change was. Don't just tell us "fixed bug 1234". Tell us what bug 1234 is and tell us a little bit about the changes that were necessary to fix it.
我认为开发人员应该被鼓励在必要的解释的时候输入签入的注释。不要只是输入“次要变更”。告诉人们次要变更是什么。不要告诉人们“修改了1234号错误”。告诉人们1234号错误内容并且告诉人们一点关于这个错误的修正引起的重要变化。
One issue does deserve special mention. Most SCM tools ask the user to enter a comment when making a checkin. This comment will be stored in the repository forever along with the changes being submitted. The comment provides a place for the developer to explain what was changed and why the change was made.
一个问题值得引起特别注意。大多数的配置管理工具要求用户签入的时候输入注释。这个注释将随着变更的提交永远的保存在配置库中。注释为开发人员解释做了什么变更和为什么变更提供了一个地方。
After the file is checked out, the developer proceeds to make her changes. She edits the file and verifies that her change is correct. Having completed all this, she is ready to submit her changes to the repository. Doing so will make her change permanent and official. Submitting her changes to the repository is the operation we call "checkin".
在签出文件后，开发人员开始进行她的变更。她编辑这个文件并且验证她的变更是否正确。当做完这些之后，她开始准备提交她的变更到配置库。做这些会使她的变更被永久保留而且变更很正式。提交她的变更到配置库中的操作就是我们所说的“签入”。
The process of a checkin isn't terribly complicated:
1. The new version of the file is sent to the SCM server where it is stored.
2. The version number of the file in the repository is incremented by one.
3. The file is no longer considered to be checked out or locked.
4. The working file on the client side is made read-only again.
签入过程并不是一个很难以理解的过程：
1. 文件的这个新版本被提交并保存在配置管理服务器上了。
2. 配置库中的文件版本也被逐一递增。
3. 文件不再被认为是处于签出或锁定状态。
4. 客户端的文件再度被改变成为只读状态。
The following screendump shows the checkin dialog box from Vault:
下面这个截图显示Vault里面的签入对话框：
Checkins are additive
签入就是添加
It is reassuring to remember one fundamental axiom of source control: Nothing is ever destroyed. Let us suppose that we are editing a file which is currently at version 4. When we checkin our changes, our new version of the file becomes version 5. Clients will be notified that the latest version is now 5. Clients that are still holding version
再次强调一个关于配置控制的基本公理：没有任何历史东西会被删除。我们假设我们修改了一个文件，其当前版本是4。当我们签入我们变更的文件，文件版本变为5。客户端将被提示最近的一个版本是5。在他们的工作目录中保持4那个版本的客户们将会被提示这个文件现在是“旧的”。
But version 4 is still there. If we ask the server for the latest version, we will get 5. But if we specifically ask for version 4, and for any previous version, we can still get it.
但是版本4仍然在的。如果我们像服务器索取最近的一个版本，我们将得到第5版，但是如果我们特别的指定要第4版，或者更早的版本，我们仍然可以得到。
Each checkin adds to the history of our repository. We never subtract anything from that history.
每个签入在我们的配置库中添加了历史。我们不能从历史里面减去什么东西。
Other kinds of checkins
其他类型的签入
We will informally use the word "checkin" to refer to any change which is made to the repository. It is common for a developer to say, "I made some checkins this afternoon to fix that bug", using the word "checkin" to include any of the following types of changes to the repository:
- Create a new folder
- Add a file
- Rename a file or folder
- Delete a file or folder
- Move a file or folder
涉及到对库的变更的时候我们将非正式的使用“签入”这个词。这对开发人员来说很普遍，“我今天下午已经签入了修改的那个bug”，使用“签入”这个词包含了以下的所有对配置库的变化：
l 创建一个目录
l 添加一个文件
l 重命名一个文件或文件夹
l 删除一个文件或文件夹
l 移动一个文件或文件夹
It may seem odd to refer to these operations using the word "checkin", because there is no corresponding "checkout" step. However, this looseness is typical of the way people use the word "checkin", so you'll get used to it.
看起来这些操作使用“签入”是很零散的，因为没有相应的“签出”步骤。当然，这种随意就是人们使用“签入”的典型的方式。
I will take this opportunity to say a few things about how these operations behave. If we conceptually think of a folder as a list of files and subfolders, each of these operations is actually a modification of a folder. When we create a folder inside folder A, then we are modifying folder A to include a new subfolder in its list. When we rename a file or folder, the parent folder is being modified.
我顺便抓住机会说说关于这些操作方式的几件事情。如果我们概念化的去考虑文件的目录及子目录，这些操作里面的任何一个事实上都是在修改一个目录。当我们在目录A里面创建一个子目录的时候，那我们修改目录A就包含了在它里面的新的子目录。当我们重命名一个目录里面的文件，父目录也都被修改了。
Just as the version number of a file is incremented when we modify it, these folder-level changes cause the version number of a folder to be incremented. If we ask for the previous version of a folder, we can still retrieve it just the way it was before. The renamed file will be back to the old name. The deleted file will reappear exactly where it was before.
正像文件的版本数一样，它是增量的，当我们修改目录的时候，这些目录的层级变化导致目录的版本数也增加。如果我们要一个目录的旧的版本，我们仍然要像前面一样去找回他们。重命名的文件将会还原到旧的名字，删除的文件将会恰好在从前的地方出现。
It may bother you to realize that the "delete" command in your SCM tool doesn't actually delete anything. However, you'll get used to it.
意识到“删除”命令在配置管理工具里面不是真正的删除了任何东西可能是最困扰你的。无论如何，你要习惯它。
Atomic transactions
原子事务
I've been talking mostly about the simple case of making a change to a single source code file. However, most programming tasks require us to make multiple repository changes. Perhaps we need to edit more than one file to accomplish our task. Perhaps our task requires more than just file modifications, but also folder-level changes like the addition of new files or the renaming of a file.
我大多数时候都只谈到对单独的源代码文件进行修改的简单例子。然后，大多数的开发工作需要我们进行多重的修改库。可能我们需要编辑不止一个文件来完成我们的任务，也可能我们的任务需要的不仅仅是文件的修改，还有像增加文件这种目录级的变化或重命名一个文件。
When faced with a complex task that requires several different operations, we would like to be able to submit all the related changes together in a single checkin operation. Although tools like SourceSafe and CVS do not offer this capability, some source control systems (like Vault and Subversion) do include support for "atomic transactions".
当面对复杂的任务需要几个不同的操作的时候，我们最好能够用一个单独的签入操作提交所有有关联的变化。尽管像VSS、CVS那样的工具不提供这样的功能，其它的版本控制系统（像Vault和Subversion）就包含了支持原子事务。
Best Practice: Group your checkins logically
最佳实践：将你的签入按逻辑关系分类
I recommend that each transaction you check into the repository should correspond to one task. A "task" might be a bug fix or a feature. Include all of the repository changes which were necessary to complete that task, and nothing else. Avoid fixing multiple bugs in a single checkin transaction.
我建议每个你签入到配置库中的事务都映射到一个任务。一个“任务”可能是修改一个bug或者是一个功能。重要的是完成那个任务或者其它的事情都包括在了配置库的变化中。避免在一个单独的签入事务中修改多数的BUG。
The concept is similar to the behavior of atomic transactions in a SQL database. The Vault server guarantees that all operations within a transaction will stay together. Either they will all succeed, or they will all fail. It is impossible for the repository to end up in a state with only half of the operations done. The integrity of the repository is assured.
原子事务这个概念很类似SQL数据库中的概念。Vault服务器确保了一个事务中的所有操作将停留在一个状态。不管他们是都成功还是都失败。在配置库中操作进行了一半的时候就结束是不可能的。配置库的完整性得到了保证。
To ensure that a transaction can contain all kinds of operations, Vault supports the notion of a pending change set. Essentially, the Vault client keeps a running list of changes you have made which are waiting to be sent to the server. When you invoke the Delete command, not only will it not actually delete anything, but it doesn't even send the command to the server. It merely adds the Delete operation to the pending change set, so that it can be sent later as part of a group.
为了确保一个事务能够包含所有类型的操作，Vault支持一个不确定的变更设置的理念。本质上，Vault客户端保持运行了一个你生成的、等待着被送到服务器的变更集合。当你调用删除命令，它不但不会真正删除任何东西，而且也不会送命令给服务器。它只不过添加了一个删除操作到变更集合中，所以它可以在将来作为部分待变更集合提交。
In the following screen dump, my pending change set contains three operations. I have modified libsgdcore.cpp. I have renamed libsgdcore.h to headerfile.h. And I have deleted libsgdcore_diff_file.c.
在下一个截图，我的变更集合包含了三个操作。我修改了libsgdcore.cpp。重命名了libsgdcore.h，还删除了libsgdcore_diff_file.c.
Note that these operations have not actually happened yet. They won't happen unless I submit them to the server, at which time they will take place as a single atomic transaction.
注意：这些操作并没有真正的发生。在我提交到服务器之前他们都不会发生，他们偶尔会像一个单独的原子事务一样发生。
Vault persists the pending change set between sessions. If I shutdown my Vault client and turn off my computer, next time I launch the Vault client the pending change set will contain the same items it does now.
Vault在会话之间持续的保持着变更集合。如果我关掉我的Vault客户端和我的计算机，下次我登录我的客户端时那些变更集合仍然保留着。
The Church of "Edit-Merge-Commit"
“编辑-合并-提交”教派
Up until now, I have explained everything about checkouts and checkins in a very "matter of fact" fashion. I have claimed that working files are always read-only until they are checked out, and I have claimed that files are always checked out before they are checked in. I have made broad generalizations and I have explained things in terms that sound very absolute.
I lied.
直到现在，我解释关于签出签入的事情都是一个“事实上”的方式。我曾主张工作文件在他们被签出之前处于只读状态，还主张文件在被签入之前始终是被签出的。我已经做了广泛的推广，我还在讨论中用很坚决地声音解释。其实我撒谎了。
In reality, there are two very distinct doctrines for how this basic interaction with an SCM tool can work. I have been describing the doctrine I call "checkout-edit-checkin". Reviewing the simple case when a developer needs to modify a single file, the practice of this faith involves the following steps::
1. Checkout the file
2. Edit the working file as needed
3. Checkin the file
事实上，真正的，关于进行基本的交互使用配置管理工具就能够工作有两个截然不同说法。我曾经描述过我的说法，被我称之为“签出-修改-签入”。当开发人员需要修改一个单一的文件的时候来回顾这个简单的例子，这个真实的操作实践包括了下面的步骤：
1. 签出文件
2. 修改文件中需要修改的
3. 签入文件
Followers of the "checkout-edit-checkin" doctrine are effectively submitting to live according to the following rules:
- Files in the working folder are read-only unless they are checked out.
- Developers must always checkout a file before editing it. Therefore, the entire team always knows who is editing which files.
- Checkouts are made with exclusive locks, so only one developer can checkout a file at one time.
接下来的“签出－修改－签入”说法对依赖如下原则成立的提交是有效地：
l 工作目录中的文件在被签出之前是只读的。
l 开发人员必须在编辑文件之前保证文件是一直被签出的。因此，整个团队都始终知道谁在修改哪个文件。
l 签出都是采用独立锁，所以一个开发人员一次只能够签出一个文件。
This approach is the default behavior for SourceSafe and for Vault. However, CVS doesn't work this way at all. CVS uses the doctrine I call "edit-merge-commit". Practicers of this religion will perform the following steps to modify a single file:
- Edit the working file as needed
- Merge any recent changes from the server into the working file
- Commit the file to the repository
这种方式是VSS或者Vault的缺省方式。当然，CVS就不是那样工作的了。CVS用的原则就是我所谓的“编辑－合并－提交”。实践论者将会去执行下面的步骤来修改一个文件:
l 编辑一个需要修改的文件
l 从服务器上合并任何最近的变化到这个文件里面
l 提交这个文件到配置库中
The edit-merge-commit doctrine is a liberal denomination which preaches a message of freedom from structure. Its followers live by these rules:
- Files in the working folder are always writable.
- Nobody uses checkouts at all, so nobody knows who is editing which files.
- When a developer commits his changes, he is responsible for ensuring that his changes were made against the latest version in the repository.
修改－合并－提交的说法是一个鼓吹自由的豪迈命名方式。它依赖于以下的规则：
l 工作目录中的文件总是保持可写
l 没有人一直签出，没有人知道谁正在改哪一个文件
l 当一个开发人员提交他的变更的时候，他有责任确保他的变更没有同配置库中最近的一个版本冲突
As I said, this is the approach which is supported by CVS, which actually has no support for exclusive checkouts at all. Vault supports edit-merge-commit as an option. In fact, when this option is turned on, we informally say that Vault is running in "CVS mode".
正像我说的，一直都不支持独立的锁定是CVS支持的一种方法。Vault通过一个选项支持编辑－合并－提交。事实上，当这个选项被选中，我们一般会说Vault用“CVS模式”工作。
Each of these approaches corresponds to a different style of managing concurrent development on a team. People tend to have very strong feelings about which style they prefer. The religious flame war between these two churches can get very intense.
这些方式都用不同风格的管理方法来管理一个团队并发的开发。人们非常强烈的趋向于选择他们自己喜欢的风格。这样两个阵营的争辩会越来越激烈。
Holy Wars
圣战
The "checkout-edit-checkin" doctrine is obviously more traditional and conservative. When applied strictly, it is impossible for two people to modify a given file at the same time, thus avoiding the necessity of merging two versions of a file into one.
签出－修改－签入说法是明显很传统和保守的。当严格的应用时，不大可能一个文件同一时间分配给两个人修改，这样就避免了一个文件两个版本的合并。
The "edit-merge-commit" teaches a lifestyle which is riskier. The risk is that the merge step may be tedious or cause problems. However, the acceptance of this risk rewards us with a concurrent development style which causes developers to trip over each other a lot less often.
修改－合并－提交提供了一种更危险一点的工作方式。这个危险就是合并步骤可能沉闷或者导致问题。当然，接收这个风险我们得到的回报就是：困扰开发人员并发开发受彼此牵制的情况少了。
Still, these risks are real, and we will not flippantly disregard them. A detailed discussion of file merging appears in the next chapter. For now I will simply mention that most SCM tools include features that can safely do a three-way merge automatically. Not all developers are willing to trust this feature, but many do.
当然，这些风险是真实的，我们不能轻视他们。关于文件合并的讨论将会在下面的章节逐条列出。现在我将简单的提及，大多数的配置管理工具包含的功能都能够安全的做三种方式的自动合并。不是所有的开发人员都愿意相信这个功能，但是呢很多人却做了。
So, when using the "edit-merge-commit" approach, the merge must happen, and we are left with two choices:
- Attempt the automerge. (can be scary)
- Merge the files by hand. (can be tedious)
Developers who prefer "checkout-edit-checkin" often find both of these choices to be unacceptable.
因此，当有“修改－合并－提交”方式的时候，合并必然发生，我们就剩下两种选择：
l 尝试自动合并（比较让人担忧）
l 手工合并（需要耐心）
Best Practice: Get the best of both worlds
最佳实践：最好取得整个世界
Here at SourceGear we are quite proud of the fact that Vault allows each developer to choose their own concurrent development style. Developers who prefer "checkout-edit-checkin" can work that way. Developers who prefer "edit-merge-commit" can use that approach, and they still have exclusive locks available to them for those times when they are needed. As far as I know, Vault is the only product that offers this flexibility.
Vault允许每个开发人员选择他们自己的并发开发风格。喜欢“签出－编辑－签入”方式的开发人员可以用此方式工作。开发人员也可以选择他们喜欢的“编辑－合并－提交”方式，他们仍然可以在必要的时候保持独立锁。我所知道的，Vault是唯一的一个产品支持这种弹性选择的产品。
I apologize for this completely shameless plug. I won't do it very often
我为这样不知羞耻的插话感到抱歉，我不会经常那样做的。
I will confess that I am a disciple of the edit-merge-commit religion. People who use edit-merge-commit often say that they cannot imagine going back to what life was like before. I agree.
我将承认我是一个“编辑－合并－提交”的信徒，经常用“编辑－合并－提交”的人都说他们不能想象生活竟然回到和过去一样。我同意。
It is so very convenient to never be required to checkout a file. All the files in my working folder are always writable. If I want to start working on a bugfix or a feature, I simply open a text editor and begin making my changes.
最省事的就是永远都不要签出文件。我工作目录中所有的文件都是可写的。如果我开始进行一个错误修复或者开始一个新的功能，我通常只是开一个txt编辑器进行变更。
This benefit is especially useful when I am disconnected from the server. When people ask me about the best way to use Vault while "offline", I tell them to consider using edit-merge-commit. Since I don't have to contact the server to checkout a file, I can simply proceed with my changes. The only time I need the server is when it comes time to merge and commit.
当我没有连接到服务器时，这个好处是很显著的。当有人问我关于使用Vault最好的“脱机”方式的时候，我告诉他们考虑用“编辑－合并－提交”。从我没有从服务器签出以来，我能够简单的跟踪我的变化。我需要连接到服务器的唯一的时间是需要合并和提交的的时候。
As I said, automerge is amazingly safe in practice. Thousands of teams use it every day without incident. I have been actively using edit-merge-commit as my development style for over five years, and I cannot remember a situation where automerge produced an incorrect file. Experience has made me a believer.
如我所说，自动合并是一种实践当中很让人担忧的方式。很多的团队每天都用到它，并没有出现意外。我曾经积极的使用“编辑－合并－提交”这种也是我自己开发风格的方式达五年，我不能记住哪里产生了自动合并和错误。经验使我成为一个信徒。
Looking Ahead
In the next chapter, I will be talking in greater detail about the process of merging two modified versions of a file.
下一个篇章，我将更多的谈到合并一个文件的两个版本的过程。
