GitHub工作流学习

工作流定义 

工作流&＃xff08;Workflow&＃xff09;&＃xff0c;指“业务过程的部分或整体在计算机应用环境下的自动化”。是对工作流程及其各操作步骤之间业务规则的抽象、概括描述。在计算机中&＃xff0c;工作流属于计算机支持的协同工作&＃xff08;CSCW&＃xff09;的一部分。后者是普遍地研究一个群体如何在计算机的帮助下实现协同工作的。

工作流主要解决的主要问题是&＃xff1a;为了实现某个业务目标&＃xff0c;利用计算机在多个参与者之间按某种预定规则自动传递文档、信息或者任务。

工作流概念起源于生产组织和办公自动化领域&＃xff0c;是针对日常工作中具有固定程序活动而提出的一个概念&＃xff0c;目的是通过将工作分解成定义良好的任务或角色&＃xff0c;按照一定的规则和过程来执行这些任务并对其进行监控&＃xff0c;达到提高工作效率、更好的控制过程、增强对客户的服务、有效管理业务流程等目的。尽管工作流已经取得了相当的成就&＃xff0c;但对工作流的定义还没有能够统一和明确。

Georgakopoulos给出的工作流定义是&＃xff1a;工作流是将一组任务组织起来以完成某个经营过程&＃xff1a;定义了任务的触发顺序和触发条件&＃xff0c;每个任务可以由一个或多个软件系统完成&＃xff0c;也可以由一个或一组人完成&＃xff0c;还可以由一个或多个人与软件系统协作完成。

1993年工作流管理联盟(Workflow Management Coalition&＃xff0c;WfMC)作为工作流管理的标准化组织而成立&＃xff0c;标志着工作流技术逐步走向成熟。WfMC对工作流给出定义为&＃xff1a;工作流是指一类能够完全自动执行的经营过程&＃xff0c;根据一系列过程规则&＃xff0c;将文档、信息或任务在不同的执行者之间进行传递与执行。

原文

https://guides.github.com/introduction/flow/

GitHub流是一个轻量级的、基于分支的工作流&＃xff0c;它支持定期进行部署的团队和项目。本指南解释了GitHub流是如何工作的以及为什么工作。

创建分支

当你在做一个项目的时候&＃xff0c;你会在任何时候都有很多不同的特性或想法在进行中--其中一些已经准备好了&＃xff0c;而另一些则没有。存在分支以帮助您管理此工作流。

当您在项目中创建分支时&＃xff0c;您正在创建一个可以尝试新想法的环境。在分支上所做的更改不影响master分支&＃xff0c;所以您可以自由地进行实验和提交更改&＃xff0c;因为您的分支不会被合并&＃xff0c;直到它准备好接受与您合作的人的评审。

ProTip

分支是Git中的一个核心概念&＃xff0c;整个GitHub流就是以它为基础的。只有一条规则&＃xff1a;master分支总是可部署的。正因为如此&＃xff0c;在处理特性或修复时&＃xff0c;创建新的分支非常重要。您的分支名称应该是描述性的(例如&＃xff0c;refactor-authentication, user-content-cache-key, make-retina-avatars)&＃xff0c;以便其他人能够看到正在进行的工作。

添加提交

一旦创建了分支&＃xff0c;就应该开始进行更改了。无论何时添加、编辑或删除文件&＃xff0c;都要提交文件&＃xff0c;并将它们添加到分支中。添加提交的这个过程在处理特性分支时跟踪您的进度。

提交还可以创建一个透明的工作历史&＃xff0c;其他人可以跟随它来理解您所做的事情和原因。每个提交都有一个相关的提交消息&＃xff0c;这是一种解释为什么要进行特定更改的描述。此外&＃xff0c;每个提交都被认为是一个单独的更改单元。这允许您在发现bug时回滚更改&＃xff0c;或者如果您决定向另一个方向前进。

ProTip

提交消息很重要&＃xff0c;特别是因为Git跟踪您的更改&＃xff0c;然后在提交到服务器时将它们显示为提交。通过编写清晰的提交消息&＃xff0c;您可以使其他人更容易跟踪并提供反馈。

打开拉请求

启动关于提交的讨论。因为它们与底层的Git存储库紧密集成&＃xff0c;所以任何人都可以确切地看到&＃xff0c;如果他们接受您的请求&＃xff0c;那么哪些更改将被合并。

在开发过程中的任何时候&＃xff0c;您都可以打开一个拉请求&＃xff1a;当你有很少或没有代码但想分享一些屏幕截图或一般想法时&＃xff0c;当你陷入困境&＃xff0c;需要帮助或建议时&＃xff0c;或者当你准备好让别人回顾你的工作时。通过在您的拉请求消息中使用GitHub的&＃64;TIVE系统&＃xff0c;您可以从特定的人员或团队那里获得反馈&＃xff0c;无论他们是在大厅下面还是在10个时区之外。

ProTip

拉请求对于促进开源项目和管理共享存储库的更改非常有用。如果您使用的是叉&拉模型&＃xff0c;则拉请求提供了一种通知项目维护人员您希望他们考虑的更改的方法。如果您使用的是共享存储库模型&＃xff0c;则在将所建议的更改合并到主分支之前&＃xff0c;拉请求可以帮助您启动代码评审和讨论。

讨论并检查您的代码

一旦打开了拉请求&＃xff0c;查看更改的人员或团队可能会有问题或评论。也许编码风格与项目指南不匹配&＃xff0c;更改缺少单元测试&＃xff0c;或者一切看起来都很棒&＃xff0c;道具也是井然有序。拉请求是为了鼓励和捕捉这种类型的对话而设计的。

您还可以根据对提交的讨论和反馈&＃xff0c;继续推进到您的分支。如果有人评论说您忘了做某件事&＃xff0c;或者代码中有错误&＃xff0c;您可以在您的分支中修复它并向上推高更改。GitHub将显示您的新提交以及在统一拉请求视图中可能收到的任何其他反馈。

ProTip

拉请求注释是用Markdown编写的&＃xff0c;因此您可以嵌入图像和表情符号&＃xff0c;使用预先格式化的文本块和其他轻量级格式。

部署

使用GitHub&＃xff0c;您可以在合并到主服务器之前&＃xff0c;从一个分支进行部署&＃xff0c;以便在生产中进行最终测试。

一旦对拉请求进行了检查&＃xff0c;并且分支通过了测试&＃xff0c;您就可以在生产中部署您的更改来验证它们。如果您的分支导致问题&＃xff0c;您可以通过将现有的主服务器部署到生产中来回滚它。

合并

现在已经在生产中验证了您的更改&＃xff0c;现在是将代码合并到主分支中的时候了。

合并后&＃xff0c;拉请求将保留对代码的历史更改的记录。因为他们是可搜索的&＃xff0c;他们让任何人回到过去&＃xff0c;去了解为什么和如何做出决定。

ProTip

通过将某些关键字合并到拉请求的文本中&＃xff0c;您可以将问题与代码关联起来。合并拉请求时&＃xff0c;相关问题也将关闭。例如&＃xff0c;输入短语Closes #32将关闭存储库中的第32号问题。有关更多信息&＃xff0c;请查看我们的帮助文章.