根据工程项目类别、子公司规模、工程项目组偏爱和许多其它因素，每一工程项目组都有自己的组织工作销售业务流程。工程项目组越大，管理就越十分困难：难题相悖显得更为两极化，延后正式宣布发布年份，组织工作各项任务选择权不断变化，工程项目组织工作条目无穷的。

第二步是采用Git，它能化解这些一直所苦着我们的难题。下列是您能在销售业务中采用的5种最盛行的Git组织工作销售业务流程：

一、基本上销售业务流程

继续执行方式很单纯：设三个储存仓。每一合作开发者都能从标识符储存仓浏览源代码，然后在邻近地区处置合作开发标识符，建立暗含更动的递交重要信息，并将其发送到那个中心储存仓，以供其它合作开发者在参予、抽取、合作开发和采用。

二、机能组成部分

基本上组织工作销售业务流程适于合作开发单纯的中文网站。但是，除非三个合作开发者开始在三个工程项目中合作开发三个不同的机能，难题就会渐渐显现出来。

假定其中一名合作开发者顺利完成了他们的机能并想正式宣布发布。由于第三个机能还没有顺利完成，那那个时候根本无法等另三个。这时正式宣布发布可能会引致纷乱。

这是组成部分Git的核心理念优点办到的地方。组成部分是工程项目合作开发的分立“近地点”。对于每一新机能，都应该建立三个新组成部分，在此合作开发和试验新机能。机能就绪后，能将组成部分分拆到主组成部分(Master/Main)，以期将其正式宣布发布到正式宣布营运的伺服器。

机能组成部分与分拆允诺

机能组成部分组织工作销售业务流程默认工程项目组中的所有合作开发者都具有完全相同的技术水准与职务。不过，在Villamblard的工程项目组中，子公司中常常存在这种方式的等级制。

在这种情况下，您能采用分拆允诺和发送权限，允许您限制发送到储存库中的选定组成部分并保持对标识符的完全控制管理。

在将组成部分分拆到主组成部分之前，需要对其进行验证和检查是否出错。初级合作开发者能建立分拆允诺并将其分配给其中一名高级合作开发者，这样他们就能查看标识符并发表评论。如果一切正常，则接受允诺分拆组成部分。

三、Gitflow

工程项目越大您就越需要控制正式宣布发布的内容与时间。工程项目需要更多的单元与集成试验，这样运行一次至少几小时。但您没必要在合作开发机能的组成部分上运行此类试验。

因此，能通过Gitflow化解，这是由Vincent Driessen于2010年提出且阐述的Git合作开发组织工作销售业务流程。

此组织工作流采用三个并行长时间运行的组成部分：

主组成部分

仅用于工程项目正式宣布发布

合作开发组成部分

建立自主组成部分，为下三个版本准备的已全部完成合作开发且机能稳定的组成部分所在位置

当您开始合作开发新机能时，从合作开发组成部分中建立三个新机能组成部分。根据需要同时建立多个机能组成部分。顺利完成合作开发并试验机能后，将标识符分拆回合作开发组成部分。然后，当正式宣布发布工程项目时，将新机能与新正式宣布发布组成部分上的合作开发组成部分隔离开来。确保该版本经过良好的、稳定的试验。

这时根据工程项目的特点，向公众正式宣布发布软件的RC版本也许是三个不错的主意。当版本稳定并且所有难题都化解后，将您的正式宣布发布组成部分分拆回主组成部分并部署到正式宣布营运中！

四、分叉销售业务流程

就像在公海上一样，在开源中一切都取决于船长。在软件方面，储存仓所有者决定谁能发送到储存仓。尽管开源的理念是每一人都能为工程项目做出贡献，但我们想一想，要是老莱(Linus Torvalds)允许任何人无限权限地修改Linux工程项目储存仓的标识符，会不会很好玩？

那个难题由分叉化解：任何时候合作开发者想更动开源工程项目中的某些内容，他们都不会直接在工程项目的储存仓上组织工作。相反，直接通过分叉并有效地创建整个储存仓副本。然后，合作开发者能自由地以他们的喜好合作开发新机能。值得一提的是，分叉也为建立针对特定应用程序调整的某些组件自定义版本提供了无限可能性。合作开发者或子公司能分叉三个储存仓并将标识符带到三个全新的方向，当然，工程项目创始人可能会有异议。

不过，在大多数情况下，当组织工作顺利完成时，会建立三个拉取允诺，将合作开发者引入其组成部分的更动与组成部分储存仓状态进行比较。在那里，社区和工程项目所有者能审查、讨论和试验更动。最后的决定权仍掌握在该工程项目的船长及其副手之中。