github入门训练营[5]-团队开发工作流的最佳实践

, , ,

在前面几篇文章中我们介绍了全球最大的gay站 github 的基本操作，其中也简单介绍了git命令的基本使用。如果需要深入使用git，那么需要找专门的资料来深入学习。如果你还不会使用git，除了看一下我前面几篇文章之外，还可以在bitbucket官网(这是一家提供git仓库云协作托管的公司)上按照这家公司的tutorial进行学习。 也可以在这里进行git沙盒环境的练习。

在本文中，我主要来讲解前端团队开发工作中的工作流（Workflow）。 工作流是对工作流程及其各操作步骤之间业务规则的抽象、概括描述，合理选择并使用一套工作流可以让技术团队开发更有序和高效！

工作流类型

目前业界常用的大致有如下3种工作流：

  • 集中式
  • 功能分支式
  • Git系列工作流

Git flow
Github flow
Gitlab flow

github flow的使用步骤:
https://blog.csdn.net/qq_35246620/article/details/65636022

GitHub Flow —— 以部署为中心的开发模式,通过简单的功能和规则，持续且高速 安全地进行部署。在实际开发中往往一天之内会实施几十次部署，而支撑这一切的，就是足够简单的开发流程以及完全的自动化

集中式

集中式的工作方式简而言之就是大家都使用同一个仓库同一个分支（一般是trunk或者叫master的主干分支），大家的代码都提交到这个统一的中央仓库，随时update保持同步。

svn和git都可以采用只使用一个分支的开发协作方式，当然使用git相对svn来说可以具有本地版本控制的能力。

集中式工作流协作的步骤：

  1. 团队中的一个成员(可能是leader)先负责创建好git仓库。

    对git而言，本身支持ssh协议，所以如果想在自己私有服务器上作为中央仓库，只需简单的执行:

    1
    2
    ssh user@host
    git init --bare /path/to/repo.git

    其中.git这个扩展名只是个惯例，认为这是一个git仓库。 这时会在服务器上对应的目录创建一个repo.git的目录作为本仓库的存储位置

  2. 在自己电脑上克隆远程仓库到本地

    1
    git clone ssh://root@linux.cuiyongjian.com/root/gitrepo/b2cshop.git

    由于我在自己服务器上创建了b2cshop.git这个仓库，并且放置在 /root/gitrepo 目录下，所以git clone的url就是

    1
    git clone linux.cuiyongjian.com/root/gitrepo/b2cshop.git

    然后shell会提示输入root用户的密码，然后就会克隆下来。

  3. 修改内容
    假如此时A、B、C三个开发者都克隆了一份空仓库到他们的本地。A先开始修改内容，当他使用git进行本地修改时，一般是进行这3个操作：编辑、暂存（Stage）和提交。假如A用户把自己的修改提交到了他的本地。

    1
    2
    3
    git status # 查看本地仓库的修改状态
    git add # 暂存文件
    git commit # 提交文件

    此时B开发者开始进行代码编辑，同样，B开发者也可以随意进行代码提交，无须关心其他开发者。

    此时，A开发者push自己的本地仓库到了远程

    1
    git push origin master

    这样，远程中央仓库中，就有了A开发者的对代码的修改提交。
    其中origin是远程中央仓库的别名，这个在A开发者git clone的时候，git就自动给clone的地址创建为别名 origin， 通过 git remote -v 命令可以查看当前的远程别名。

    1
    2
    origin	ssh://root@linux.cuiyongjian.com/root/gitrepo/b2cshop.git (fetch)
    origin	ssh://root@linux.cuiyongjian.com/root/gitrepo/b2cshop.git (push)

GitFlow

gitflow定义了一个围绕项目发布的严格分支模型，从而更好的管理多人协作的项目。gitflow依然使用中央仓库作为所有开发者的交互中心。

分支类型

gitflow操作步骤

如何解决多人同时要发布功能的问题?

如果基于同一个trunk/master分支进行发布，这时必然会引起夹带问题，就算人为控制必须串行发布又会带来一个人发布会阻塞其他所有发布的问题。 这在小团队发布频率比较高的情况下，特别容易造成发布效率的低下。

发布完成后要打tag，表明此次发布已经完成，下次如果发现本次发布的bug要基于这个tag进行修复。

fast-forward

Refer

http://blog.jobbole.com/76847/
http://blog.jobbole.com/76857/
http://blog.jobbole.com/76867/

refer

totoiseGit使用
git工作流
gitflow和githubflow
GitHub Flow 及 Git Flow 流程使用時機