Github协作开发流程

去年三月份开始正儿八经的写代码,顺手注册了一个github账号,但是基本上都只是当作一个U盘使用,没有正式与其他人协作开发的经验。恰逢最近需要,因此回过头来整理一下github的使用经验,以及正确的团队协作开发流程。

<!--more-->

首先需要明白的是gitgithub并不是一回事,前者是分布式版本控制系统,后者是一个基于git代码托管平台

对此我的理解是:

  • git可以让我们在本地管理代码版本,比如回滚代码,在新的分支上开发新功能(换句话我,我们可以在离线的情况下更新代码版本)
  • github可以让我们远程管理我们的代码,也可以让我们参与团队协作

具体怎么安装git这个就不说了,教程一抓一大把。参考:

1. 本地仓库

1.1. 工作流程

使用git需要先初始化代码仓库,可以使用git init,也可以git clone等方式,会生成一个.git目录。

git仓库中的任何一个文件,都只有3种状态:

  • modified,已修改,表示修改了某个文件,但还没有提交保存
  • staged,已暂存,表示已修改的文件放在下次提交时要保存的清单中
  • committed,已提交,表示该文件已经被安全地保存在本地数据库 中

上面有一个“暂存”的概念,实际上只是一个简单的文件,该文件同样存放在.git目录中,一般称为索引文件或者暂存区域

使用git基本的工作流程是

  • 修改某些文件
  • git add,对修改的文件进行快照,然后保存到暂存区域
  • git commit -m "commit info" ,确认提交更新,将保存在暂存区域中的文件永久存储在Git目录下

1.2. 常用功能

在工作过程中,会使用到下面的常用功能:

  • git status,检测当前文件状态
  • .gitigore,忽略某些不想被git管理的文件,比如node_modules
  • git diff,查看已暂存和未暂存的修改
  • git rm,将文件从已跟踪文件清单中(更准确的说法是从暂存区域移除)
  • git log,查看历史提交记录
  • git commit --amend,撤销提交操作

1.3. 小结

可以看见,上述操作都是可以在离线状态下进行的,至于如何实现团队协作开发,就必须先了解远程仓库了。

2. 远程仓库

远程仓库指的是将本地的代码推送到第三方服务器上进行托管,比如最著名的github。与他人协作涉及管理远程仓库以及根据需要推送或拉取数据。

2.1. 操作远程仓库

如果初始化远程仓库

  • git remote add origin XXX@XXX.git,添加远程仓库
  • git push origin master,将本地仓库推送到远程仓库

可以使用git remote查看连接的远程仓库名称,默认为origin

接下来就可以在其他地方连接远程仓库获取代码了

  • git clone git@xxx/xxx.git,克隆远程仓库
  • 做一些修改
  • git push orgin master,将改动推送到远程仓库,
  • git pull origin master,获取最新的远程仓库,

3. 分支

3.1. 概念

分支相当于复制当前仓库,并在复制的镜像文件上进行修改,避免频繁的修改导致版本难以追踪同时也让我们拥有了相对独立的开发环境。 如果把每次commit的时间线连接起来就构成了一个分支:

  • 没有分支,需要追踪每一次commit
  • 有分支,追踪每个分支,每个分支可独立追踪每次的commit

也就是说,构成分支的时间线不宜过长(指提交的次数不宜过多,时间跨度则可以很长)

3.2. 分类

分支可分为本地分支和远程分支两大类

  • git branch查看本地所有分支,
  • git branch -a查看本地和远程仓库上的所有分支(远程分支用红色标识)

3.3. 操作分支

下面是一个在分支上开发新功能的操作流程

  • git branch feature_1,新建一个feature_1的分支
  • git checkout feature_1,切换到分支,并在该分支上进行相关操作(PS:上述两个步骤可使用快捷方式git checkout -b feature_1操作)
    • 基于当前分支开发一些内容
    • git add .
    • git commit -m "finish"提交分支改动
  • git checkout master,切回主分支
  • git merge feature_1,将分支改动合并到主分支,可能需要解决冲突
  • git branch -d feature_1,功能开发完成,删除相关分支

需要注意的是:

  • 实际上在工作中一般是不会直接把功能分支推送到master上的,下面会提到
  • 合并分支的时候,可以使用git diff feature_1 master来对比两个分支的差异。

3.4. 分支管理

下面的分支管理策略是在别人推荐的,决定在工作中进行逐步尝试:

  • master永久性分支,用于发布新的版本,master所有代码更新应该源于合并develop的代码。
  • develop开发分支,相当于是master的真身,用于管理开发版
  • 暂时性分支,源于develop分支,归并与develop分支,且一定会被删除
    • feature,新功能分支,一般命名为feature_*
    • release,预发布分支,一般命名为release-*
    • hotfix,修复bug分支,一般命名为hotfix-*

4. 分布式 Git

分布式协作已衍生出多种工作流。

4.1. 集中式工作流

核心一个集中的代码仓库,所有开发者与之关联同步,这意味着在多个开发者均做出修改之后,只有第一个开发者可以顺利把修改推送回代码库,其他开发者在推送之前必须将前面的开发者的修改合并进来。

现在的开发流程就是基于这种模式进行的,不过我们都是在各自的分支上进行开发,定期合并到develop分支上。

4.2. 集成管理者工作流

git允许多个远程仓库存在,在这种情况下,每个开发者都用于自己仓库的写权限和其他开发者仓库的读权限,一般存在一个官方权威的仓库,要为这个仓库做贡献,则需要自己克隆一个仓库进行修改,然后把自己的修改推送到自己的远程仓库,最后申请官方拉取你做的更新(一般官方会进行检测)。 在github上,上面的描述就是fork操作。

5. 最后

曾经我也喜欢打卡墙上一片绿,表明自己坚持在学习,这个初衷是正确的,但是到了后面某些时候,却出现了为了打卡而打卡,上传了一些毫无价值的代码,这跟我的最初目的完全背道而驰了。在今后的日子里,我会注意这个问题的。

2018年五月面试发现的一些问题 BFC及其应用