浅析项目团队中的Git分布式工作流

Git作为目前强有力的软件团队合作工具,除去git工具的基础使用,怎样在项目团队中合理地使用强大的分布式版本控制软件,以实现敏捷高效的开发工作,也是学习Git的重要内容。本文主要参考atlassian,在该文章的基础上,做了一些标注与说明,并结合git常用操作,对Git工作流作一些介绍与分析。


关于Git基本操作,推荐廖雪峰的教程,戳Git基础教程


分布式工作流

在集中式版本控制系统如SVN、CVN下工作时,有一台中央服务器保存了项目的全部核心代码库,客户端全部是其的离线拷贝,所有提交最终都要汇总到中心服务器,并且可以影响全部离线拷贝。


集中式工作流

和集中式版本控制系统相比,分布式版本控制系统Git的安全性要高很多,因为每个人电脑里都有完整的版本库,这样,工作的时候就不需要联网了,因为版本都是在自己的电脑上。
使用Git为开发工作流提供了一些好处:

  • 它给每个开发者自己的整个项目的本地副本。 这个隔离的环境使每个开发人员独立于项目的所有其他更改工作,他们可以添加提交到本地存储库,完全忘记上游开发,直到它们方便。
  • 它让你访问Git的鲁棒分支和合并模型。 与SVN不同,Git分支被设计为一种故障安全机制,用于集成代码和在存储库之间共享更改。

分支管理

Git工作流使用最好遵循标准的使用规范,下面列出常用的分支:

  1. Master分支
    这个分支也称为Production分支,包含了最近发布到生产环境的代码,最近发布的Release, 这个分支只能从其他分支合并,不能在这个分支直接修改
  2. Develop 分支
    这个分支是我们是我们的主开发分支,包含所有要发布到下一个Release的代码,这个主要合并与其他分支,比如Feature分支
  3. Feature 分支
    这个分支主要是用来开发一个新的功能,一旦开发完成,我们合并回Develop分支进入下一个Release
  4. Release分支
    当你需要一个发布一个新Release的时候,我们基于Develop分支创建一个Release分支。
  • 这个分支只应该做Bug修复、文档生成和其它面向发布任务。一旦对外发布的工作都完成了,发布分支合并到master分支并分配一个版本号打好Tag。
  • 另外,这些从新建发布分支以来的做的修改要合并回develop分支。
  1. Hotfix分支
    当我们在Production发现新的Bug时候,我们需要创建一个Hotfix分支。这是唯一可以直接从master分支fork出来的分支。修复完成,修改应该马上合并回master分支和develop分支(当前的发布分支),master分支应该用新的版本号打好Tag。
Git工作流

工作实践

在服务器上建立好远程中央仓库。

创建Develop分支

第一步为Mater分支建立一个Develop分支。一个简单的方法是一个开发人员在本地创建一个空的Develop分支并将其推送到服务器:
git branch develop git push -u origin develop


项目组其他开发人员克隆中央仓库克隆,并切换至Develop分支:
git clone ssh://user@host/path/to/repo.git git checkout -b develop origin/develop

开发者A与B并行开发功能

开发者A与B开始各自的功能开发,工作应在新分支上展开,新的Feature分支应基于
Develop分支建立。
git checkout -b feature-X develop

在各自功能分支上进行编辑、暂存、提交:
git status git add git commit

开发者A完成并提交新功能

开发者A在完成功能后首先从从远程获取Develop分支最新版本并merge到本地。
git pull origin develop
将Feature分支合并至本地Develop分支。
git checkout develop git merge feature-A


合并成功后推送至远程仓库。
git push origin develop
推送时可能遇到冲突解决,则先git pull抓取最新提交再在本地解决冲突后再push。

开发者A进行版本发布

开发者A完成功能准备进行版本发布时,基于Develop分支创建Release分支,这个分支是清理发布、执行所有测试、更新文档和其它为下个发布做准备操作的地方,像是一个专门用于改善发布的功能分支。
git checkout -b release-0.1 develop
当准备好发布时,开发者A将首先发布分支合并回master分支,并push到服务器仓库。
git checkout master git merge release-0.1 git push
只要有合并到master分支,就应该打好Tag
以方便跟踪。
git tag -a 0.1 -m "Initial public release" master git push --tags
在发布分支中已经提交的更新需要在后面的新功能中也要是可用的,所以应合并至Develop分支。之后删除发布分支。
git checkout develop git merge release-0.1 git push git branch -d release-0.1

Bug反馈与修复

当发布后收到Bug反馈后,开发者从master
分支上拉出了一个维护分支Hotfix,提交修改以解决问题,然后直接合并回master分支:

git checkout -b hotfix master
/*Fix the bug*/
git checkout master
git merge hotfix
git push

与发布分支一样,维护分支中新加这些重要修改需要包含到develop分支中。

git checkout develop
git merge hotfix
git push
git branch -d hotfix
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。

推荐阅读更多精彩内容

  • 多种多样的工作流使得在项目中实施Git时变得难以选择。这份教程提供了一个出发点,调查企业团队最常见的Git工作流。...
    JSErik阅读 4,464评论 2 8
  • Git分支管理 master:主分支,当前分支上的代码随时可以直接发布,并且只能通过Pull Request从其他...
    UEUEO阅读 9,735评论 5 33
  • 当这个世界在我眼波里荡漾, 摇摆的身姿注定我终生凝望。 新旧悲伤渗透出来烟波浩淼, 在黑暗的河床上默然地裸露, 必...
    摩诘梵心阅读 374评论 6 4
  • 这两天闲来无事,就把前短时间项目中的搜索功能抽取出来,重新写一下,搜索功能虽然简单,但是设计到得知识点也挺多的,就...
    Zeller阅读 9,647评论 3 31
  • 0 我左手边平躺着才买不久的手机,右手边立着正充电的平板电脑,这些曾经耗费我几个月生活费买来的物件后来长期占据着我...
    清水小和尚阅读 455评论 3 4