git如何设置master分支的权限_你是如何玩Git分支模型的呢？

最新推荐文章于 2024-09-03 06:30:00 发布

杀死约拿

最新推荐文章于 2024-09-03 06:30:00 发布

阅读量4.3k

点赞数 1

文章标签： git如何设置master分支的权限

本文链接：https://blog.csdn.net/weixin_34867001/article/details/112410340

版权

本文详细介绍了Git的分支管理模型，包括master、develop及其他辅助分支的使用，强调了Git在版本控制中的优势。通过流程图展示了分支的合并与创建策略，如功能分支、Release分支和热修复分支，旨在确保代码稳定性和高效协作。同时，文章提及了如何处理紧急修复，以快速响应生产环境的问题。

摘要由CSDN通过智能技术生成

分支管理

总览(一张流程图给大家先镇镇惊)

它主要体现了Git对我们源代码版本的管理。

(转载者加)一般情况：

master和develop并行。
master上始终是最稳定的代码，develop是正在开发的代码。
feature则是某个开发为了自己的功能拉的分支。不一般情况：
develop正在开发，如果你上线突然被拒绝了，这时候就要从master上开一个热分支，或者release分支也行，改好之后在分别合并到其他分支。但，本人感觉release通常意味着终止。别在从release上拉分支了。

为何是Git？

对于Git与其他集中式代码管理工具相比的优缺点的全面讨论，请参见这里。这样的争论总是喋喋不休。作为一个开发者，与现今的其他开发工具相比较，我更喜欢Git。Git真得改变了开发者对于合并和分支的思考。我曾经使用经典的CVS/Subversion，然而每次的合并/分支和其他行为总让人担惊受怕(“小心合并里的冲突，简直要命！”)。但是对于Git来说，这些行为非常简单和搞笑，它们被认为是日常工作中的核心部分。例如，在很多CVS/Subversion书里，分支与合并总是在后面的章节中被讨论(对于高级用户使用)，然而在每个Git书中，在第3章就已经完全涵盖了(作为基础)。简单和重复的特性带来的结果是：分支与合并不再是什么可以害怕的东西。分支/合并被认为对于版本管理工具比其他功能更重要。关于工具，不再多说，让我们直接看开发模型吧。这个模型并不是如下模型：在管理软件开发进度方面，面对每个开发过程，每个队员必须按一定次序开发。

分布式而非集中式

对于这种分支模型，我们设置了一个版本库，它运转良好，这是一个"事实上" 版本库。不过请注意，这个版本库只是被认为是中心版本库(因为Git是一个分布式版本管理系统，从技术上来讲，并没有一个中心版本库)。我们将把这个版本库称为原始库，这个名字对所有的Git用户来说都很容易理解。

每个开发者都对origin库拉代码和提交代码。但是除了集中式的存取代码关系，每个开发者也可以从子团队的其他队友那里获得代码版本变更。例如，对于2个或多个开发者一起完成的大版本变更，为了防止过早地向origin库提交工作内容，这种机制就变得非常有用。在上述途中，有如下子团队：Alice和Bob，Alice和David，Clair和David。从技术上将，这意味着，Alice创建了一个Git的远程节点，而对于Bob，该节点指向了Bob的版本库，反之亦然。