记录－交流－Web开发知识分享
作为一名开发人员 Git 常用命令每天都在使用，大家肯定信手拈来，但是在团队协作中 Git 的使用姿势和个人开发还是有很多不一样的地方，对于技术团队，期望大家使用规范的 Git 操作流程，规范的 Commit Message，规范的代码风格。这样才能提高团队开发相率和项目的可维护性。今天主要为大家介绍一套基于 Github flow 的 Git 操作流程。
首先，多人协作的情况，我们通常会 fork团队项目主仓库到自己的托管空间下，然后 Clone 到本地进行开发,假设团队项目的托管地址为：
https://github.com/fe/github-flow
此时主仓库项目下的固定分支两个，分别是 master，develop。
Clone 到本地：
git clone git@github.com:fe/github-flow.git假设上面主仓库 fork 之后的项目地址为：
https://github.com/xxx/github-flow
Fork 出来的仓库完全属于你自己，你可以任意修改该仓库的代码及配置，但是除非你向项目主仓库提交 pull request，并且被接受通过，你才可以将你fork 仓库修改的代码合并到主仓库，否则不会对主仓库产生任何影响。
此时可以在控制台输入 git remote -v
我到处旅行，向人们教授 Git，几乎我最近完成的每堂课和研讨会都问我对git-flow 的看法。我总是回答说我认为它很棒——它采用了一个系统 (Git)，它拥有一百万个可能的工作流，并记录了一个经过充分测试的、灵活的工作流，该工作流以相当简单的方式适用于许多开发人员。它已成为某种标准，因此开发人员可以在项目或公司之间移动并熟悉此标准化工作流程。
最后更新于 2022年6月26日 …
介绍基于Git 两种协作开发模式,GitHub Flow & Git Flow
对于Github 一些好用的特殊操作技巧 ，可以见GitHub 特殊操作技巧 和Git的基本操作
GitHub Flow —— 以部署为中心的开发模式,通过简单的功能和规则，持续且高速 安全地进行部署。在实际开发中往往一天之内会实施几十次部署，而支撑这一切的，就是足够简单的开发流程以及完全的自动化。
最后更新于 2022年6月26日 …
Git 作为一个源码管理系统，不可避免涉及到多人协作。
协作必须有一个规范的工作流程，让大家有效地合作，使得项目井井有条地发展下去。"工作流程"在英语里，叫做"workflow"或者"flow"，原意是水流，比喻项目像水流那样，顺畅、自然地向前流动，不会发生冲击、对撞、甚至漩涡。
本文介绍三种广泛使用的工作流程：
如果你对Git还不是很熟悉，可以先阅读下面的文章。
本文的三种工作流程，有一个共同点：都采用"功能驱动式开发"（Feature-driven development，简称FDD）。
它指的是，需求是开发的起点，先有需求再有功能分支（feature branch）或者补丁分支（hotfix branch）。完成开发后，该分支就合并到主分支，然后被删除。
最早诞生、并得到广泛采用的一种工作流程，就是Git flow 。
它最主要的特点有两个。
首先，项目存在两个长期分支。
在使用Git的过程中如果没有清晰流程和规划，否则,每个人都提交一堆杂乱无章的commit,项目很快就会变得难以协调和维护。
Git版本管理同样需要一个清晰的流程和规范。
Vincent Driessen 为了解决这个问题提出了 A Successful Git Branching Model
以下是基于Vincent Driessen提出的Git Flow 流程图
也就是我们经常使用的Master分支，这个分支最近发布到生产环境的代码，最近发布的Release， 这个分支只能从其他分支合并，不能在这个分支直接修改
这个分支是我们是我们的主开发分支，包含所有要发布到下一个Release的代码，这个主要合并与其他分支，比如Feature分支
这个分支主要是用来开发一个新的功能，一旦开发完成，我们合并回Develop分支进入下一个Release
当你需要一个发布一个新Release的时候，我们基于Develop分支创建一个Release分支，完成Release后，我们合并到Master和Develop分支
当我们在Production发现新的Bug时候，我们需要创建一个Hotfix, 完成Hotfix后，我们合并回Master和Develop分支，所以Hotfix的改动会进入下一个Release
近期评论