代码是企业在整个研发活动中非常重要的资产，如果代码出现了问题，那么为客户提供的产品和服务，都会由于这些问题造成不可预知的事故，对企业造成负面影响。所以，如何让代码管理变得更加有序可靠，是广大企业和研发团队亟需重视的问题。
一个企业的研发团队都是由多个开发人员组成的。不同的开发人员技术水平有差异，擅长的领域也有区别，并且软件的开发的过程就是一个多人协作的过程，团队成员使用 Gitee 时间不长，对 git 也在慢慢学习，那么在这个过程中一定会有一些大大小小的意外，下面的这三个情况你一定遇到过：
几个人开发的内容互相有影响 不知道谁把重要分支的代码给修改了，或者干脆直接把分支删除了 合并代码的时候，Code Review 浮于表面或干脆没有 CodeReview 环节今天我们就针对上面这三个问题，为大家分享如何通过 Gitee 企业版的代码托管功能解决这些问题，让企业的代码管理变得更加有序可靠。
Gitee企业版实践 1.分支模型无论是大企业还是小企业，在最开始，都会困惑于分支模型如何规划。我们最常看到、最常听到的一种分支模型就是上面这张 git-flow 分支模型的图。但 git-flow 的分支模型，并不能适应每一个企业，分支模型和其他的管理模式一样，一个企业需要有适合自己的模式。
企业想要构建适合自己业务特点的分支模型，首先要清楚分支的用途：
管理唯一产品版本的分支 master 就是用来管理产品最稳定代码的分支，如果企业内开发场景非常简单，那么就可以直接在 master 分支上进行开发和发布。随着团队规模的增加，在保障产品发布版本代码的稳定的情况下，会在其他分支进行开发，完成后将稳定的版本合入到 master 分支。 进行随时更新的分支 git-flow 中，develop 分支就是做这个作用的。由于 master 分支只管理稳定的发布版本代码，开发过程就会将代码提交到 develop 分支中，并且可以把 develop 的代码发布到测试环境中，完成测试、发布后，再把 develop 分支的内容合并到 master 分支上面去。这样就可以形成稳定的发布分支和随时更新的开发分支。 修复紧急缺陷的分支 在产品发布之后，很有可能出现紧急的生产缺陷，这些生产缺陷我们需要进行修复，测试以后，才可以发布新的生产版本。但是由于开发分支 develop 已经新增加了很多功能，不能直接从开发分支进行修改，发布分支 master 直接修改会影响到发布版本的管理，所以可以从 master 分支中，创建一个专门用来紧急修复缺陷的 hotfix 分支。我们在 hotfix 分支中进行修复和测试，完成后再合并到 master 分支上面去，完成发布。 独立的需求开发分支 在开发团队规模增大之后，团队内部开发人员较多，大家共同在开发分支 develop 进行编码会造成大家的代码互相影响，所以，可以为开发不同的需求，创建属于这个需求自己的开发分支，在 git-flow 中提交 feature 分支。每一个开发人员在自己需求的开发分支 feature 上进行开发，完成后合入到 develop 中，这样就可以保证 develop 分支的内容都是已经完成的需求，可以随时进行测试。 设置专用的发布分支 团队规模不断增大后，为了使开发的过程可以和投产验证的过程独立，在需要进行版本发布的时候，就可以拉一条发布分支 release 分支，在 release 分支上进行测试和缺陷修复，通过后再发布到 master 分支。这样，既不会影响到 develop 分支新功能的合并，又不影响发布内容的验证。从上面这个过程就能看出来，分支模型一定是和开发工作的模式关联起来的，也会随着团队规模和业务特定进行调整，比如说团队给不同客户的版本有差异，就会根据不同的客户版本创建一个分支。适合自己团队特点的分支模型，就是最好的。
2.保护分支我们重要的分支因为开发人员的误操作，导致分支上面的代码不正常，或者重要的分支被删除，这些情况会造成我们企业非常大的损失，会使我们花大量的时间去修复这些问题。所以，Gitee 企业版中也提供了相关的功能，最大程度地避免类似问题的发生。
Gitee 在分支管理中，提供了保护分支的功能，在企业里面，我们可以把开发负责人设置成为仓库的管理员，其他开发人员设置为开发者角色。这样开发负责人就可以将重点分支比如 master 分支和 develop 分支设置为保护分支。
设置保护分支后，拥有开发者权限的普通开发人员，是无法直接将代码提交到保护分支的，并且也无法将保护分支进行删除，只能由拥有管理员权限的用户进行操作，这样就极大地帮助团队将重要的代码版本管控起来，不会受到开发人员意外操作的影响。
作为拥有管理员权限的开发负责人，可以通过设置保护分支规则，授权给其他开发人员代码推送和代码合并的权限。这样可以让团队中的成员来帮助自己进行代码审核，来维护保护分支上的代码，还可以防止分支被误删除的情况发生。
但如果设置了保护分支，普通开发人员无法直接将代码提交到保护分支上面来，那么如何将代码合并到保护分支上面来呢？这就会使用到 Gitee 企业版中的一个重要功能：代码评审（Pull Request）。
3.代码评审（Pull Request）开发人员在完成对自己功能的开发后，需要将 feature 分支上面的内容合并到集成开发分支 develop 上面，就需要通过代码评审（Pull Request）功能，把自己开发完成的内容，提交给开发负责人进行评审，在评审通过后，即可把代码合并到目标分支上。
通过代码评审的方式，可以保证团队每一次对重要分支的修改，都能够让开发负责人清晰的看到代码修改的内容并进行评审，并对每一次代码合并的内容进行记录留底，保证代码合入的可靠性。
3.1 开发人员提交代码评审开发人员通过代码评审功能，创建 Pull Request，选择自己开发任务所在的分支，并选择需要进行合入的目标分支。填写本次提交变更的标题和描述信息，告诉评审人员本次需要代码合入的内容。
开发人员提交时可以选择评审人员，本次合并需要哪些开发人员进行评审。管理员可以通过系统设置进行评审的人员名单。这样，必须在所选的评审人员和测试人员审批过后，代码才可以合并。
在创建代码评审时，可以看到我们本次开发代码时，增加了多少次提交，改动了多少个文件。
填写完成相关信息后，即可创建代码评审请求，评审人员需要对代码合并内容进行评审。
3.2 负责人检查提交内容评审人员在看到开发人员提交的代码评审请求后，可以查看代码评审的内容，包含代码评审的描述信息，关联的任务信息，了解开发人员提交代码的背景信息，帮助评审人员更好的评审代码。
在评审时，评审人员最需要的内容就是文件改动信息。评审人员在这里可以看到开发人员提交的分支信息与需要合入到的目标分支上面的所有差异文件，并且修改的内容都会高亮进行标注，使评审人员可以快速定位到需要评审的内容。
在发现问题时，可以直接在代码行间增加评论内容，指出开发人员的代码编写问题，开发人员可以在看到评审人所给出的问题后修复自己的代码。
评审人员可以逐个文件进行审查，添加自己的评审意见，如果代码存在较大问题，可以直接拒绝评审请求，被拒绝的代码无法合入到目标分支中。
3.3 代码审批通过后合并评审内容开发人员进入到自己创建的评审请求后，可以看到评审人员对自己代码的评审意见，可以根据评审意见进行代码修改。在代码修改完成后重新提交代码。
评审人员需要再次对开发人员提交的代码进行评审，满足合入标准后，可以点击评审通过，即可进行代码合并。点击合并分支后，开发人员完成的代码，即可合入到目标分支上，完成整个代码合入的过程。
完成代码评审，代码合入到目标分支后，代码合入的内容，代码评审的内容，全部都可以在代码评审的历史合并中看到，方便我们后续对代码对变更进行追溯。
3. 代码管理实践总结我们通过在企业内部建立符合企业开发团队特点的分支模型，并通过 Gitee 企业版中提供的保护分支功能，及最重要的代码评审（Pull Request）流程，可以保证我们通过Gitee 企业版，将代码管理变得更加有序可靠，帮助企业避免因为代码管理方面的混乱所造成的业务损失。