Git 是最流行的版本管理工具,我也是刚刚接触git,系统的学习了下Git的团队开发Branch Model,发现网上已经给出的最佳实践如下:
更详细的信息,请直接参考原文章链接:
http://nvie.com/posts/a-successful-git-branching-model/ (最佳实践的来源,强烈推荐读一下)。
http://www.ruanyifeng.com/blog/2012/07/git.html (上一篇文章的中文翻译和简化,没有原始文章清晰)
http://scottchacon.com/2011/08/31/github-flow.html (git-flow 根据第一篇的最佳实践总结出来的模式性的东西)
最佳实践如下(源于最佳实践一文):
- 任何系统或项目都常备两个 Branch, Master 和 Developer,这两个branch 永远不会删除。
-
Master branch 标志了系统的最初版本和稳定功能,如果Master branch 有提交,那么一定表示有新的稳定功能或者 bug 修改,需要重新发布新版本。版本策略由项目组独立制定,比如较大的功能发布,可以升级大版本 (v1.1.0 -> v1.2.0), hot bugfix 可以发布小版本 (v1.1.0 -> v1.1.1)等。
- Develop branch: 最初是从 Master branch 拉出。是功能开发的 upstream branch。 所有开发的功能都要 merge 到 此 branch,进行最终的集成或回归测试。如果测试通过了,那么会将功能merge 回 master(注意不是直接merge,下面会讲到),进行正式的发布。
2. 中间的branch,随需要拉出,功能执行完成后删除。主要包括如下几种:
- feature branch。故名思议,feature branch 是真正的功能开发的branch。为什么 feature branch,而不是直接在 develop branch 上开发? 因为团队合作! 如果需要并行的开发多个feature,那么在一个 develop branch上开发明显是不合适的,不内聚,容易造成错误。每个 feature 开发,都需要单独从 develop branch 拉出一个独立的feature 分支,开发并测试完成后,需要在合并到 branch 分支,然后进行验证和回归测试。确认没有问题后,删除 feature branch。
- release branch。release branch 专门用于预发布的。 feature branch上进行了功能的开发,测试通过,并合并到develop branch 上了。这时可以发布新的功能了。为什么不直接从 develop branch merge 到 master branch 并直接发布? 因为在发布的时候,我们可能还需要做一些细节上的微调工作,比如开发时版本号可能是 snapshot,到正式环境上需要去掉 snapshot,比如需要连接正式的数据库进行下验证,修复下验证中发现的一些bug。这些都是在 release branch 上进行的。release branch 工作完成后,需要 merge 到 master branch,正式发布。注意 release branch 也要 merge 回 develop 分支,确保所有的修改都同步到了 develop 分支。
- hotfix分支。上面的分支已经能够确保我们从开发到上线的流程都成功了。但是有时候在线上会发现一些比较hot 的bug,需要立即修复。这个时候走正常的 feature release 到发布显然是不能满足要求的。此时应该直接修改 master ,并合并到 develop branch. 这就是 hotfix branch 存在的理由。从 master branch 拉出 hotfix branch,bug fix 并验证后,合并到 master 和 develop。
具体的拉出分支的命令及merge 命令,请参考最上面推荐的链接。
相关推荐
团队合作:在团队开发中,需要遵循代码规范和设计原则,使用版本控制工具(如Git)进行代码管理,使用Bug跟踪系统(如JIRA)进行问题跟踪和项目管理。 优化代码性能:在开发过程中,需要注意代码性能问题,如使用...
开发过程中,我们遵循了敏捷开发的原则,采用了Git进行版本控制,让团队成员之间的协作更加高效。基农机电招平台项目可以作为毕业设计或者课程设计的参考,也可以作为初学springboot框架和前后端分离开发的实践项目...
这是一个真实的示例,使用最新的工具和技术来开发和实现强大的android应用程序,方法是使用一些SOLID原则和Clean Code Architecture实现的新Android Jetpack。 Gitflow工作流程: 如果在合并之前没有适当的流程来...
在实际开发中,我们应该按照几个基本原则进行分支管理:首先,master分支应该是非常稳定的,也就是仅用来发布新版本,平时不能在上面干活;那在哪干活呢?干活都在dev分支上,也就是说,dev分支是不稳定的,到某个...
UFES的核心原则是: 代码标准化自动化可扩展性可管理性表现这种设置主要基于我经常使用的约定和技术,以及我自己的工作流程。 但是,我认为发布它很好,以防其他开发人员发现它的使用对他们或他们的团队有益。要求...
Pyro最初是由Uber AI开发的,现在由社区贡献者(包括的专门团队)积极维护。 在2019年,Pyro Linux Foundation的一个项目,这是一个在开源软件,开放标准,开放数据和开放硬件上进行协作的中立空间。 有关Pyro的...
设计原则Gopass是基于命令行的通用密码管理器,在开发时会牢记以下原则: 容易:对于技术用户(即习惯于命令行的用户),gopass入门应该很容易。 安全:安全性很难。 我们的目标是使它尽可能容易,同时仍能为普通...
Shopify要求使用一个简单且统一的API来访问具有非常不同的内部API的数十个不同的支付网关,这是设计库的主要原则。 它是为在Ruby on Rails Web应用程序中使用而开发的,并作为Rails插件无缝集成,但它也可以作为...
我们与各种规模的组织合作,设计,开发和扩展解决方案,以管理其数据并释放其潜力。 从小型初创公司到大型跨国组织,我们与全球数十个团队合作。 我们还创建了自己的产品和数十个开源库。 这是我们的剧本。 它是...
4.8、JavaScript、nodeJS、React(受限)、设计模式、测试驱动开发、行为驱动开发、敏捷开发、AWS、Docker、微服务、MongoDB、Git、Github 技能 优秀的沟通者 我举办了许多 TDD 和 BDD 研讨会。 现在,所有与会者都...
Git 存储库适用于希望获得 Ezo 软件开发顾问职位面试机会的候选人。 如果您还没有与我们的招聘团队联系过,请发送电子邮件。 挑战 挑战包括高尔夫代码测试。 这些练习被沙盒程序员用来通过尝试应用新知识来获得乐趣...
团队 目前Sym网页主要由 、 和。 接触 您可以在上找到所有当前的主要开发人员。 贡献和建议 所有关于新功能和错误报告的建议都应该从创建一个开始,我们可以在那里进一步讨论这个话题。 如果您在网站上发现拼写错误...