目标读者:了解 Git 的基本概念,能够使用 Git 进行基本的本地和远程操作。
有关 Git 的基础知识可以参见 知乎回答-怎样使用 GitHub?,天猪(刘勇)给出了一些很好的学习资料。
本文介绍了小团队中 Git 管理的基本使用流程。
小团队的代码管理可以采用这样一种方式:项目存在一个中心远程仓库,作为团队成员进行代码交流的主要场所。同时可以存在一些成员远程仓库,用于局限在团队中部分成员间的代码交流。并将成员分成以下几类不同的角色:负责人、普通组员、预发布责任人 和 版本修复责任人。下面的章节具体介绍了各类角色的 Git 使用流程。
基本须知:
需要多个人共同完成的分支可以建立远程分支,单个人完成的分支只建立本地分支即可。
一、负责人
负责人的职责:管理远程仓库。
负责人的工作均可直接在远程仓库完成。
1.创建项目
- 创建公有项目
- 添加README.md
- 添加证书
- 添加忽略文件
- 创建 dev 分支
2.其他
- 更新 README.md 文件
二、组员
工作流程:
- 克隆项目
- 签出并创建 dev 分支,使其跟踪远程的 origin/dev 分支。
- 在dev分支基础上创建自己的分支 member* 。
- 在自己的分支上添加文件
- 在自己的分支上修改文件
- 合并到dev分支
- 推送dev分支到origin/dev分支
// 更新 .gitignore 文件
- 从 dev 新建一个分支 ignore (如果预测变更频繁就建立一个远程分支,现在一般都有模板,偶尔有个没有忽略的直接在dev分支上改就可以了)
- 更新忽略文件
- 尽快合并到\推送到 origin/dev 分支 (避免两个组员同时更改该文件造成冲突。)
1.创建本地仓库
2.更新本地仓库
3.更新 .gitignore 文件
4.常用查询命令
5.意外情况处理
意外:推送代码到远程 dev 分支时发生冲突。
解决方案:先把 远程仓库的 origin/dev 分支拉取下来,解决冲突文件后再推送。平时的时候尽量避免不同组员更改同一个文件。
意外:不小心把自己的工作成果push到了master分支。
解决方案:先对master进行回退,再使用git push -f
将错误的提交删除。
三、预发布责任人 & 版本修复责任人
1.预发布责任人
当需要发布新的版本时,预发布责任人:
- 基于最新的 dev 分支创建一个 release-版本号 分支
- 进行修缮工作
- 合并到 dev 分支
- 合并到 master 分支
- 打标签
- 删除 release-版本号 分支
使用 git show [TAG_NAME]
可以查看标签对应的提交信息。
2.版本修复责任人
当新发布的版本发现 bug 时,版本修复责任人:
- 基于最新的 master 分支创建一个 hotfix-版本号 分支
- 进行debug工作
- 合并到 master 分支
- 打标签
- 合并到 dev 分支
- 删除 hotfix-版本号 分支
3.意外情况处理
意外:某组员完成自己的任务后合并到 dev 分支,推送时发现 release 分支的修缮工作更改了自己原来的文件,产生了冲突。
解决方案:把 origin/dev 分支拉取下来,将冲突解决后再次提交。(注意这里解决冲突后 master 分支上的文件与该组员的工作成果依旧是有冲突的。除非该组员解决冲突时不更改 relese 时的修缮代码,而仅仅更改自己的代码来解决问题。因此,一旦有冲突产生,最好双方进行合理交流达成一致意见。减少冲突。)
四、成员远程仓库
当某个团队成员希望其他成员协助完成他的编程任务时,该成员可以为自己的本地仓库创建一个远程仓库作为成员远程仓库,方便其他成员协助。建立成员远程仓库可以避免中心远程仓库的代码交流繁杂混乱。
成员远程仓库在在操作上是中心远程仓库的简化版。仅在细微处有所不同。
1.求助者
- 创建成员远程仓库
- 添加成员远程仓库
- 推送自己的分支到成员远程仓库的 master 分支
- 拉取成员远程仓库的 master 分支到自己的分支
举例:
当某个分支 a 跟踪了远程分支 b,即 b 成为 a 的默认拉取来源,也因此,一个本地分支同一时间只能跟踪一个远程分支。
让本地某分支跟踪远程分支的命令
2.协助者
- 克隆成员远程仓库
- 在 master 分支基础上创建自己的分支 member*
- 在自己的分支上修改代码
- 合并到 master 分支后推送到成员远程仓库