GIT, GitFlow and 持续集成

本文翻译自medium----原文链接; 欢迎来和 pilishen 一起学习 php&Laravel ；学习群：109256050

When developers are finished “ coding ”, what happens to their code? How do they keep all this code sorted? I intend to explain it in this article, using only a minimum amount of tech words.

当开发者写完了代码，他们会怎么对待代码？他们是怎么储存所有这些代码的？我想在这篇文章内用尽可能少的专业术语来解释这些问题。

Why should I care?

为什么我关心这个？

If you,re asking,I,m guessing that you,re not simply interested in understanding how your team works.

如果你问这个问题，那么你就不仅仅只对你的团队怎么合作感兴趣了。

Okay then, here comes two more reasons why you definitely should care.

好的。接下来，这里有为什么你一定要关心这个问题的其中两个原因。

First of all, probably the most important reason is because it will give you the opportunity to shine during cocktail parties.And as we know all, that,s what really matters!

首先，最重要的原因可能是它会给你在聚会时展示自己的机会，因为众所周知，它实在是太重要了。

And second,because how developers are working is directly putting some constraints on business delivery. Understand it will help you realize that they are not just some immature divas trying to assess some power over the business. No, there is actually hard stuff in there and they are already doing their best.

其次，开发者的工作方式会直接对业务交付有影响。理解它会帮助你理解到它们不是一些不成熟的角色，不是通过它们来获得业务上的权利。实际上都是一些干货并且它们已经做的很好了。

The World of the Developer — Definitions

开发人员的世界—定义

We,ll explain the following terms and names:

• Version control
• GIT
• Branches
• Merge
• Branching model
• GitFlow
• Integration
• Continuous Integration

我们将解释以下的术语和名词：

• 版本控制
• GIT
• 分支
• 分支合并
• 分支模型
• GITFlow
• 集成
• 持续集成

Version control

版本控制

Developer works. The result is code. This code is shared and stored safely is some tool. We call this kind of tool version control because it not only stores safely the code,and allows the developers to share the code and collaborate together as a team on the same code, but also versions the code. That means that every time a developer adds some code, it does not replace the previous version but adds a change in the history instead. That way,developers are allowed to mess up and revert to a previous version easily. They can also investigate issues and understand what happened in the code by looking at the history.

开发者的工作归根结底是代码。这些代码可以通过一些工具来安全的共享和储存。我们称这些工具为版本控制。因为它们不仅用来安全的储存代码和使开发者共享他们的代码并作为一个团队在同样的代码上进行合作。也可以对代码进行版本控制，这意味着每当开发者添加一些代码，他们并不替换之前的版本，而是添加在历史中添加变化。通过这种方法，开发这可以轻易的将弄乱的代码返回到上一个版本。他们也可以调查问题和通过查看历史来了解代码到底那里有问题。

In some from or another, you,ve used this concept in many collaborative tools outside of the developer world. Google Docs,Slides and Sheets have this concept of history: you can review the past changes and revert to a previous version. The same goes with Wikipedia and other Wiki software, and like the developers, tool you can add some somments to help other user to get a sense out of the historys. As a matter of fact, Wikipedia contributors are urged to take the time to write such a comment to help control bad edits.

某种程度上，你可能已经在开发者世界之外的很多合作工具中用过这中概念。像 Google 的文档、幻灯片和表格有这种历史概念：你可以查看历史改变然后回退到之前的版本。Wiki 百度或者起来的 Wiki 软件也都是这样的，像开发者一样使用工具来添加注释可以帮助其它用户了解历史变化之外的东西，作为一个重要的实践，维基百科的贡献者们急切的需要花费时间去写一个这样的注释工具来帮助控制糟糕的代码提交。

Git

And GIT,well,is an example of version control software. There are many version control softwares available, but most people agree to say that it is the best version control out there for many great reasons. So today most teams are using GIT. GIT 是版本控制工具的一种，有很多的版本控制工具可以使用，但是大多数人都一致认为很多的重要原因使得 GIT 是最好的版本控制工具。所以当下很多的团队都是用 GIT

Branches

Now comparing developer-grade version control with what are doing Google Docs and Wikipedia has some limits. When you use these customer-grade tools, there is only one truth at any given time. There is a complete history that led to this truth, but in the end there is only one current version. And whenever you edit it, you edit this last and current version。

相对于开发者级的版本控制，google 文档和维基百科这样的版本控制就有局限性了。当你使用这些消费者级的工具时，任何时候你都只有一个确定的版本。使用完整的历史记录来控制这些确定的版本。最后只有一个当前版本。并且每当你编辑文档的时候，你都是直接当前的最新版本上编辑它们。

What are doing the developers can be much more complex than what you are doing in Google Docs or Wikipedia. Here are some examples:

• There is several versions of the software simultaneously in production
• Bug-fixes must be delivered on a previous version
• Big features takes a lot of time and cannot be added directly to the last, current version
• Validating new software versions takes time, cannot block the development of new
• software features but cannot be added yet to the version in production
• And so on …

开发者做的版本控制比 Google 文档或者维基百科要复杂得多，比如下面的例子：

• 在生产环境下软件同时有多个版本
• Bug 修复必须在上一个版本上进行
• 大的特性需要花费大量的时间并且不能直接添加到最近的当前版本上。
• 验证新的版本需要花费时间，这并不阻碍开发者同时进行新开发。
• 软件功能不能直接添加到生产版本上
• 等等

Basically, what we are talking about is called branches in the version control terminology. One of these branches have a special meaning and represents what is in production, what is the last, current version. In GIT, it is often (though not always) called the master branch.

基本上，我们所说的就是在版本控制术语中的分支。这些分支中有一个有着特殊的含义，它代表了生产环境内的代码，在 GIT 中最近的当前版本我们通常（不都是）称之为 master 分支。

When developers are creating a new feature, they do not work on this branch directly; they create a new branch starting from this one and that way they are able to work freely and independently on this branch. When the work is done, it is merged back into the main branch.

当开发者创建一个新的分支的时候，他们不直接在主分支上进行，而是创建一个基于这个分支创建一个新的分支，在这个新的分支上他们可以独立自由的工作。当这个工作完成后再将这个新分支合并到主分支上。

And it goes the same for the other examples I gave. Fixing a bug on a previous version of the software … Yes, that ’ s branches. Having features in validation before going to production … Yes, more branches.

在我给的另一个例子也是一样的操作，在软件的上一个版本上修复开发。是的，也是分支，在推送到生产环境之前验证特性，是的，更多的分支。

Creating and merging branches is truly part of the developer ’ s routine. That ’ s simply how they do their job.

创建和合并分支是开发者的日常工作的一部分。这就是他们怎么干活的。

Merge

Now I have introduced the term merge in the previous section. Well, that ’ s when things become tricky

我在上个部分已经提过了合并这个术语。提到这个事情开发变复杂了。

Typical non-trivial merge: the changes on the right relies on code that has been changed on the left

典型的非冲突合并：右边的变化是基于左边已有的变化。

Merging branches is not always easy; you have two versions, which one should you take? There is no easy answer, and often you ’ ll have to take changes from both branches. And maybe the changes of one branch impacts code that only exists on the other branch: when the branch added code that relies on old code that has been changed in the other branch. So really this is something that is not always straightforward. By the way, one of the reasons why people are saying that GIT is so great, is precisely because it makes merging easier.

分支的合并不是总是很简单：假设你有 2 个版本，你该选择哪一个版本？没有简单的答案，通常你需要在 2 个分支中都采用一些改变的代码。当在分支中增加一些基于另外一个分支的旧代码，且这些旧代码被修改了。这时也许一个分支的改变会影响到只存在于另一个分支上的代码。所以这是一件并不总是那么简单直接的事情。 顺便说一下，人们说 GIT 非常棒的原因之一，正是因为它使合并变得更容易

Branching Model

So merging can be tricky. But the kind of merge the team faces depends on when branches are created and on how they are managed. So the team usually agrees to follow some kind of branching and merging policy: this policy is called a branching model.

所以合并可能很棘手。但是团队所面临的合并取决于何时创建分支以及如何管理它们。因此，团队通常同意遵循某种分支和合并政策：该政策称为分支模型。

GitFlow

GitFlow is such a branching model. What makes it standing out of the crowd is that it have been widely shared and thoroughly documented by the community. GitFlow is also popular because it is very easy to understand for GIT new-comers: GitFlow matches how most people used other version control softwares. Today, I believe that the biggest advantage of GitFlow is that it is widely used: it is a way to standardize the version control practices between teams and companies, and to speed up the on-boarding of new developers. Your team uses GitFlow, you hire somebody, he knows GitFlow, he can contribute to the project from day 1.

GitFlow 是一个分支模式。让它脱颖而出的原因是，它已经被社区广泛分享和彻底地文档化了。GitFlow 很受欢迎的另一个原因是它很容易被 Git 新手理解。GitFlow 与大多数人使用其他版本控制软件的方式相匹配。

今天，我相信 GitFlow 的最大优势在于它被广泛使用：它是一种用来标准化团队和公司版本控制实践的方法，并加速新开发人员参与到项目开发中。你的团队使用了 GitFlow，你雇佣了一个人，他知道 GitFlow，他可以从第一天起就为这个项目做贡献。

GitFlow: http://nvie.com/posts/a-successful-git-branching-model/

To sum up GitFlow:

• master represents what ’ s in production
• Features and fixes are worked on their own branch
• The features and fixes branches are not directly merged into master when the work is done; it is merged into a branch called develop
• develop is thus some buffer between “ dev done ” and “ in production ”; release branches are made from develop and merged into master
• Release branches can thus be tested and validated at length in staging environment

总结一下 GitFlow

• master 代表生产环境中的代码。
• 特性和修复是在他们自己的分支上工作的。
• 当工作完成后特性和修复分支不会直接合并到主分支;它被合并到一个叫做开发的分支中
• 因此 develop 分支是开发完成和应用于线上生产之前的缓冲分支。Release 分支基于 develop 分支并合并到 master 分支
• Reslese 分支因此可以在暂存环境下充分的测试和验证

Integration

As I have explained it, merging a branch can be tricky. There can be hard to predict interactions between the different pieces of code. Unsurprisingly, developers solves this problem by testing the resulting software. If nothing is broken, we ’ re good! This whole process is called integration: we are integrating two versions of software together by merging their code and by checking (testing) that everything is right.

正如我解释的那样，合并一个分支可能是件棘手的事情。很难预测不同代码段之间的交互。意料之中的是，开发人员通过测试最终的软件来解决这个问题。如果没有什么东西坏了，我们就很好！ 这整个过程称为集成：我们通过合并他们的代码和检查（测试）所有的东西都是正确的，将两个版本的软件集成在一起。

Continuous Integration

Obviously, testing the software by hand takes a lot of time, is prone to human error (not even to speak of human boring-ness). and on average slows down the whole process.

显然，手工测试软件需要花费大量的时间，很容易出现人为错误（甚至不考虑人类的无聊），这减慢了整个项目的开发过程

Enter the idea of continuous integration, where tests are automated and run by another software. Maybe the most known continuous integration software is Jenkins (yet another buzzword you can use in cocktail parties with your dev team!).

也就进入了持续集成的概念，在那里测试是自动化的，由另一个软件运行。也许最著名的持续集成软件是 Jenkins （这是另一个你可以在于你的开发团队一起聚会时炫耀的术语！）

The GitFlow branching model is a great fit for continuous integration. The whole idea is to make sure that whenever a feature branch is merged into develop, the continuous integration checks that everything is right on this main branch. This check is done regularly. Depending on the context of the project and on the maturity of the team, this check may be done only once a day, or on the contrary every time any developer makes any single change (tip: the shorter the feedback, the better)

GitFlow 分支模型非常适合持续集成。整个想法是为了确保，每当一个特性分支被合并到 develop 分支中，持续的集成检验在这个主分支上所有的东西都运行正常。这种检验是定期执行的。根据项目的环境和团队的成熟度，这个检查可能每天只做一次，或者相反每次开发人员做任何改变时都进行（提示：反馈越短越好）。

What ’ s your take on it?

Getting version control, branching model and continuous integration right is not easy but of paramount importance.

正确的掌握版本控制、分支模型和持续集成并不容易，但却是最重要的。

Developers must spend a vast amount of time on these subjects. They should agree on how they do it and work the same way as a team. They should challenge their way of doing regularly and seek for better ways. They should setup or create all the tools they need to do their job well.

开发人员必须在这些主题上花费大量的时间。他们应该就如何做到这一点达成一致，并以与团队以相同的方式工作。他们应该挑战自己的做事方式，寻求更好的方式。他们应该搭建或创建他们需要的所有工具来做好他们的工作。