Web开发的GIT工作流程

很久以前，我与之合作的Web开发人员小团队开始使用git进行Web开发。那时我们只是致力于直接登台或掌握，然后在两者之间频繁合并。总比没有好，但也很混乱。

不久之前，我们采用了gitflow工作流程。尽管它肯定比以前出现的混乱更好，但它似乎有些繁琐且过于释放/面向里程碑。我的开发人员经常要求我弄清楚它应该如何工作，什么应该合并而不应该合并。一般而言，它似乎不适合用于Web开发工作，在Web开发工作中，我们经常部署代码，而没有跟踪特定的发布里程碑。

根据朋友最近的建议，我已经开始关注GitHub Flow。在这里阅读Scott Chacon的帖子，可以很好地解决这一难题：

那么，为什么不在GitHub上使用git-flow？好吧，主要的问题是我们一直都在部署。git-flow过程主要围绕“发行版”设计。我们实际上没有“版本”，因为我们每天都会部署到生产中，通常一天要部署几次。

FWIW，我也在Atlassian的网站上看到了这种很好的工作流汇总：https ://www.atlassian.com/git/workflows#!workflow-feature-branch

但是，它们看起来都像是在一个小型团队中，对于Web开发而言是错误的选择，并且它们又针对主要的应用程序发布而不是频繁/每日发布。

这是关于SE的一个问题，要求比较git-flow和github-flow /programming/18188492/what-are-the-pros-and-cons-of-git-flow-vs-github -流

一般而言，这是一个很好的答案，但是正如我在meta.programmers.SE下方的评论中提到的那样，这似乎表明有关最佳通用工作流程实践的问题属于此处，我希望除了git-flow和github以外，还提供更多可能的答案-flow，而特定于Web开发。因此，我认为这里值得提出一个新问题。

这样一来，对于一个小型Web开发团队来说，您发现最佳/首选的基于git的工作流程是什么？是github-flow还是其他东西？

首先，我想对您研究过的不同工作流程进行一些总结，认为您不适合所从事的开发类型：

• 集中式（源）：非常类似于SVN工作流，但现在处于分布式环境中。每个开发人员都处理的个人副本，master并origin/master直接或通过请求请求将更改推送到。

• Feature分支（Source）：好吧。每个从事特定功能的开发人员都应在专用于该功能的特定分支上工作。此功能分支应该master从另一个功能分支创建，也可以从另一个功能分支创建。最终，所有内容都合并回master。

• Gitflow（来源）：两个主要分支跟踪一个项目的历史记录，develop而master。另外3个分支叫hotfix，release并feature保持变化直接对master固定关键生产缺陷，改变版本号和其他细节，就像在一个特定的功能的版本或工作之前特性分支分别。

• GitHub flow（源代码）：开发人员创建的feature分支master。通过拉取请求推送更改。接受的更改被master GitHub bot Hubot立即部署。

对于问题的发展部分，答案取决于团队的背景。它们是否来自SVN环境？然后，您应该采用集中式方法，因为它是最类似于SVN的方法。他们和Git合作感觉舒适吗？然后，也许您不应该尝试使团队的工作流程适应其中的任何一种，而应实施自己的，精心设计的以满足您的需求的工具，如果我理解得很好，那就是开发的灵活性和快速的部署。

我也认为您应该集中精力改进后者。您的部署管道如何组成？在“ 持续交付：通过构建，测试和部署自动化的可靠软件发行版 ”中，作者确定了不频繁部署的可能原因，其中一些原因是：

• 部署过程不是自动化的。
• 测试需要很长时间。
• 人们不了解构建/测试/部署过程。
• 开发人员没有受到关于通过进行小的，增量的更改来保持应用程序正常运行的纪律，因此经常破坏现有功能

这些听起来是否可以改善？也许您可以告诉我们更多有关您和您的团队如何处理项目这一部分的信息。