git配置git-flow

开发工作流的体系结构是根据发布的quality和quantity来设计的。 在这里，质量 指的是每个版本中无错误或功能集的状态。 并且，数量是指开发过程中的发行数量。 这种架构通常并不复杂。 但是，这可能会引起混乱。

开发工作流程（也称为git-flow）是用于构建和发布软件的一系列开发步骤。 Git是一种流行且功能强大的版本控制技术，已在许多公司中使用； 但是，还有其他技术，例如Perforce或Mercurial 。 在本文中，我使用git-flow而不是开发工作流，而不会失去一般性。

在这里，我解释了两种对于初创公司必不可少的git-flow体系结构。 了解这些体系结构的详细信息可以解决开发，产品和管理团队之间不必要的冲突。 最后，我解释了git-flow的基本原理和螺栓，有助于更好地理解它。

请注意，与本文中的内容相比，git-flow体系结构可能变得更加复杂。 不过，如果您了解了两个最基本的git-flow的详细信息，那么您将在需要时轻松理解任何复杂的git-flow。

I.最常见的两种git-flow是什么？

在软件行业中使用了各种git-flow。 但是，其中两个通常在创业公司中使用。 下面，我首先描述两个场景，然后解释适用于这些场景的两个git-flow。

方案1.您需要具有频繁发布的快速开发过程。 您不想让网守签署发布。 您接受在不导致主要功能停止的情况下意外地将小错误引入master分支。 另外，您无需控制每个版本中的功能列表。 在这种情况下，您必须使用高频和低质量的体系结构。

方案2。您有相对大量的用户。 您必须在每个版本之前全面验证产品的质量。 您希望有一个不断评估该产品的团队，以及一个负责发布发布的网守。 在这种情况下，您必须使用低频和高质量的体系结构。

网闸是指定期检查产品质量并决定何时准备发布产品的人员。 在大多数初创公司中，产品经理都是看门人。

—高频和低质量

在此git-flow中，只有一个主要的源分支，开发被合并到该分支中并从中获取发布。

在启动初期，由于任何原因都不能延迟开发工作流程。 没有付费客户，主要重点是开发。 因此，开发团队旨在仅通过自动化测试来检测错误，并接受在新版本中包含一些错误。 由于此git-flow没有看门人来签署发布，因此错误仅会通过自动测试传递到发布。 这些错误必须在发现后立即修复。

—低频和高质量

在此git-flow中，有两个主要的源分支：master和release。 开发团队在master分支上工作以构建产品，而在release分支上工作以使产品准备好发布。

发布分支为产品经理创建了一个隔离的环境，可以更好地控制功能开发和发布质量。 在产品团队中，质量检查工程师在发布分支上进行手动测试，以发现并报告必须修复并合并到发布分支中的错误。 最后，由产品管理员作为网守负责签署发布。

高质量软件附带了低频发布的费用。

无论如何，不​​可能有100％的测试覆盖率。 因此，错误也可能在此git-flow中流经测试过程。 但是，此体系结构中的发行质量比以前的体系结构更可靠。

二。 git-flow的主要步骤是什么？

- 发展

git流的第一步是代码更改，即功能开发或错误修复。 当您想在代码库中进行更改时，必须始终创建一个隔离的分支，以防止在源分支中进行不必要的更改。

完成开发后，必须通过标准流程将最近的更改合并到源分支中。 Github称这个过程为pull-request，而GitLab称它为merge-request，两者都引用同一个过程。

在此过程中，代码更改将等待开发人员级别的测试（例如单元测试，集成测试和回归测试）和代码审查。 有一些应用程序（例如Hound）也使代码审查过程部分自动化。 如果代码更改可以通过测试并获得所需的批准，则它们将合并到源分支中。 并且，发展还在继续！

—测试

优质的软件就是一切 测试与开发之间的平衡。 git-flow中有两个关键点来运行测试。 首先，在将代码更改合并到源分支（例如，母版或发行版）之前，其次，在将产品交付给客户之前。

了解软件测试的重要性后，问题是我们拥有多少种测试。 测试可以是自动的或手动的。

Automated tests由DevOps解决方案（例如CircleCI）和测试框架（例如PyTest ）以完全自动化的方式执行。

Manual tests由产品团队执行，旨在涵盖未经自动测试测试的零件。

在这里，我根据软件测试提供给开发工作流程的高级价值对其进行分类。 有2种不同类型的测试：开发人员级别和用户级别。

Developer-level tests例如单元，集成和回归测试，它们评估代码的健全性，并在每次对git-flow提交之后且在构建过程之前执行。 这些测试是完全自动化的。 它的目标是确保code sanity并increase the pace of development 。

开发人员是工作流程中这些测试的所有者。

User-level tests例如验收和性能测试）可评估整个解决方案，并在部署后执行。 这些测试是手动和自动的。 它的目标是emulate user experience并measure the quality of service整体measure the quality of service 。 在大多数初创企业中，产品经理是工作流中这些测试的所有者，因为这些测试大部分是面向用户的。

在大多数情况下，您必须极大地依靠自动化测试来检查健全性和质量。 但是，这并不意味着在此过程中根本不能使用手动测试。

通过运行自动化过程在每次提交时对代码库进行集成和验证的做法称为“ Continuous Integration.

—建造

构建是指对源代码及其工件进行编译和打包的过程。 构建步骤的输出是一个二进制文件，可以随时在云上进行部署。

Example. 当您使用Docker构建二进制文件时，构建过程的输出称为Docker映像，它是在其上构建虚拟机环境的快照。

这些二进制文件必须存储在二进制存储库管理器（例如JFrog或DockerHub）上 。 将它们存储在资源库管理器中时，必须对它们进行标记，以便可以轻松地搜索和检索它们，尤其是当您要自动部署它们时。 例如，您可以使用由git创建的提交ID标记二进制文件，因为它可以准确显示解决方案的构建位置，并且可以作为唯一标识符。

从每个提交构建和存储二进制解决方案的做法称为“ Continuous Delivery 。

—部署

部署是指使用诸如Mesos ， Kubernetes或Orchestrator在云或服务器上收集，执行和协调所有构建工件的过程。 Docker Swarm 。

Example. 当您使用Docker部署解决方案时，将创建一个Docker容器，该容器可以在您的本地计算机上或在云基础架构（例如Amazon EC2）上的计算节点上运行。

最佳实践是为每个master和release分支指定一个云环境。 主分支和发布分支的云环境分别称为开发（dev）和生产（prod）。 在更复杂的工作流程中，存在暂存环境超出了本文的范围。

如果使用微服务架构，则可以独立部署每个微服务，例如前端，后端或数据库。 精心设计微服务的集合以构建主要服务。 微服务架构使您可以独立，有效地测试，维护和部署松耦合的服务。 不必说您需要正确配置此业务流程，这也不在本文的讨论范围之内。

在没有任何干预的情况下不断部署解决方案的做法称为Continuous Deployment.

您可以根据您在行业，公司阶段或客户期望中的要求，在启动时使用不同的git-flow体系结构。 在本文中，我仅描述每个人拥有一个富有成效的团队并减少不必要的冲突所必须知道的最重要的部分。 荣誉😊

翻译自: https://hackernoon.com/git-flow-is-the-source-of-productivity-not-confusion-4k3d3wro

git配置git-flow