版本控制和 Git 简介

熟悉谷歌文档？ 好吧，如果你是的话，可以肯定地假设你知道小“版本历史”选项卡，它允许作者和相关人员检查和跟踪文档中所做的所有更改。 在任何给定的时间点。 一个方便的工具，不是吗？

现在想象一下，不是一张充满段落的工作表，而是充满数百行代码的文件。 与单个文档不同，有大量不同的文件，不断更新。

在这样的场景中，有数千行代码在运行，最终结果，即移动应用程序是企业未来所依赖的，拥有一个能够记录所有更改的软件变得更加重要在代码文件中制作。

这就是版本控制软件出现的地方。

为什么版本控制在软件开发中很重要

顾名思义，版本控制软件使移动应用程序开发人员能够跟踪软件开发周期的不同版本并对其进行更改。 这种跟踪代码中发生的所有更改以及撤消更改的选项的能力使得版本控制成为移动应用程序开发公司涉及多个开发人员的流程的重要组成部分。

现在谈到版本控制，目前市场上有许多可用的软件。 让我们看看其中的一些——

可用的版本控制软件

虽然在其 GitLab 调查中，分布式软件的领导者发现 98% 的用户使用 Git 开源工具，超过 92% 的开发人员在应用程序开发过程中使用 Git 作为版本控制语言，但有一些开发人员可能会考虑使用 Git 替代方案的原因。 其中一些原因可能有所不同 - GitHub 定价结构和 Github 在 iOS 和 Android 上启动的事实，对 Octocat 的厌恶，或者不是 Git 的版本控制语言的简单舒适度。

无论您的原因是什么，这里都是 Git 用于版本控制的替代方案 -

现在，即使有许多可供版本控制和 Appinventiv 使用的替代方案，我们在其中的很多方面都有第一手的经验，由于不同的客户要求，我们确实偏爱 Git。 让我来告诉你为什么。

为什么 Appinventiv 使用 Git 进行版本控制

1.闪电般的速度

在市场上所有的版本控制软件中，Git 日志和提交元素的工作速度是其他任何软件都无法比拟的。 当你的开发团队在一个平台上工作时，软件的速度是绝对必要的。

2.离线工作的能力

当您使用依赖于 Internet 的软件时，当您在移动中并且与中央存储库断开连接时可能会有风险。 但是，Git 并非如此。 使用 Git，您几乎可以在本地计算机上完成所有任务——提交、浏览项目历史、创建分支或合并。

3.撤消救济

Git 带有一个“撤消”命令，可让您更正和恢复整个提交。 事实上，它甚至为您提供了通过其 Reflog 选项恢复“已删除”提交的选项。

4.对于备份

当团队在 Git 上工作时，团队在他们机器上的每个克隆都带有一个可用的备份。 除此之外，几乎每一个 Git 操作都只会添加数据而不会删除它。

5.做出有用的提交

当我们的开发团队提交了一组不相关的更改——从 A 中获取一些特性，在另一个中修复一些错误——其他团队成员可能很难理解发生了什么，他们也很难回滚如果导致问题，则 A 的功能。

Git 通过创建细粒度提交来解决这个问题。 通过其“暂存区”概念，即使您只看单行，也可以轻松找出下一次提交中将包含哪些更改。

以上就是我们在 Appinventiv 使用 Git 的五个主要原因。 现在我们已经了解了原因，是时候看看如何了。 我们如何将 Git 纳入我们的版本控制流程。

现在让我们开始吧。

使用 Git 时的版本控制过程

存储库创建

Git 的目的是管理一组文件，也就是 Project。 为了做到这一点，Git 将所有信息保存在称为存储库的数据结构中。 存储库由应用程序的源代码、资源和数据集组成。 基本上，它具有定义应用程序项目的所有内容。

现在，有两种方法可以在 Git 上获取存储库。 您可以使用本地目录并使用命令行将其转换为 Git 存储库，也可以将已上传的 Git 存储库复制到您的存储库中。

创建存储库时，通常有两个选项——公共和私有。 公共存储库是其他开发人员使用 Git 可以查看的存储库，而私有存储库是只能由少数人查看的存储库。

分枝

存储库创建旁边是分支。 在像 Appinventiv 这样的公司中，在任何给定的时间点都有超过 15 到 20 名开发人员在开发一个项目，开发人员共享相同的源代码并进行工作的情况并不少见。 发生的情况是，当一些开发人员忙于解决问题时，其他开发人员可能正在实施某些功能。

在这种情况下，我们需要一个可以轻松处理同一代码库中不同代码版本的系统。

这就是 Gitflow 发挥作用的地方。 Gitflow是一个用于系统高效地分支的框架。

在我们继续讨论分支过程如何在 Gitflow 上工作之前，让我用一个例子来解释这个概念。

假设您的团队中有 5 名开发人员，他们正在开发类似 Instagram 的应用程序。 现在，假设 Feed 和 Notifications 等单个应用程序功能被表示为模块 1、模块 2 等等。 现在这些不同的模块是开发分支，经过处理后与父分支或主分支合并。

开发人员添加分支的那一刻，他们创建了一个独立的开发线，将他们的工作与团队成员的工作隔离开来。 然后将不同的分支合并到父分支中。

分支是一种允许团队成员识别他们应该期望的所有更改并且使回溯变得容易的方法。

在我们的项目中，我们通常会保留这些分支——

• 主分支
• 发展分部
• 功能分支
• 发布分支
• 热修复和错误修复

犯罪

开发人员在单个文件中所做的更改称为提交。 更改或提交将添加到本地存储库中，而不是添加到服务器中。 接下来，我们的开发人员会按照编写提交消息的习惯，在其中发布提交的描述（文件中所做的更改），以便其他开发人员也知道文件中所做的更改的详细信息。

推

当您在本地 Git 存储库中提交时，接下来发生的事情是将更改发送到服务器，这称为Push 。

当您是唯一处理文件的人时，将提交历史推送到服务器是相当容易的，但如果还有其他开发人员也参与了该过程，您必须先拉动更改，然后才能推送您的一组提交给 Git。

接下来，我们将研究在 Pull Change 步骤中做了什么。

拉取请求

当多个开发人员在处理同一个文件时，会发生一些提交可能会在您推送之前由其他开发人员推送到服务器上。 当这种情况发生时，就会发生冲突（稍后会详细介绍）。

为了避免在服务器上两次上传相同的代码库，开发人员首先从存储库中拉取更改并确保代码不同。 现在，通常，当两个或多个开发人员处理同一个文件并将他们的提交推送到服务器时，“合并”选项就会出现。

接下来我们来谈谈Merge。

合并

合并是开发人员首先将所有分支相互合并，然后与主分支或父分支合并的步骤。

每次交付输入推送命令时，他们都会获得一个合并选项，然后会询问他们想要合并提交的分支。

现在在Merge阶段，Conflict的发生非常普遍。 当您计划合并的两个分支在同一文件的同一部分中发生更改时，通常会发生冲突。 这里发生的是 Git 无法确定应该使用哪个版本。

当这个冲突问题出现时，Git 提供了两种解决方案——自动和手动。

顾名思义，一个是 Git 自己发现问题的地方，而在后者中，开发人员必须手动完成。 在 Appinventiv，我们专注于手动解决冲突，因为即使是微小的错误发生机会也能消除。

当我们使用 Git 对我们的应用程序开发过程进行版本控制时，同时发生的是问题跟踪。

由于我们是敏捷的忠实追随者，并且相信敏捷用于我们的移动应用程序开发流程，因此我们了解同时处理多个开发流程的重要性。 借助问题跟踪功能，测试人员可以更轻松地实时查看在 Git 服务器上编写和推送的代码。

我们利用 ZenHub 板来监控每个存储库中的工作流程。 该板允许我们跟踪建议更改的优先级，并帮助开发人员实时更新他们在板上的评论。