git代码审核,git简书

团队开发中 Git 最佳实践，不给队友拖后腿

蓝色字体 ，选择“标星公众号”

优质文章，第一时间送达

本文地址： .com /a/1190000004963 64 1

本文不是一篇 Git 入门教程，Git 入门教程大家可以参考:Git 教程合集。

本文要从具体实践角度，尤其是在团队协作中，阐述如何去好好地应用 Git。既然是讲在团队中的应用实践，我就尽可能地结合实际场景来讲述。

如果一个团队在使用 Git 时没有一些规范，那么将是一场难以醒来的噩梦！然而，规范固然重要，但更重要的是个人素质，在使用 Git 时需要自己养成良好的习惯。

如何去写一个提交信息，在具体开发工作中主要需要遵守的原则就是「使每次提交都有质量」，只要坚持做到以下几点就 OK 了：

假如已经把代码提交了，对这次提交的内容进行检查时发现里面有个变量单词拼错了或者其他失误，只要还没有推送到远程，就有一个不被他人发觉你的疏忽的补救方法——首先，把失误修正之后提交，可以用与上次提交同样的信息。

然后，终端中执行命令 git rebase -i [SHA] ，其中 SHA 是上一次提交之前的那次提交的，在这里是 3b22372。

最后，这样就将两次提交的节点合并成一个，甚至能够修改提交信息！

谁说 历史 不可篡改了？ 前提是，想要合并的那几次提交还没有推送到远程！

当自己一个人进行开发时，在功能完成之前不要急着创建远程分支。

请读张文钿所写的《使用 git rebase 避免无谓的 merge》：。

在将其他分支的代码合并到当前分支时，如果那个分支是当前分支的父分支，为了保持图表的可读性和可追踪性，可以考虑用 git rebase 来代替 git merge；反过来或者不是父子关系的两个分支以及互相已经 git merge 过的分支，就不要采用 git rebase 了，避免出现重复的冲突和提交节点。

Git 的一大特点就是可以创建很多分支并行开发。正因为它的灵活性，团队中如果没有一个成熟的分支模型的话，那将会是一团糟。

要是谁真把这么乱的提交图表摆在我面前，就给他一个上勾拳！

有个很成熟的叫 Git Flow 的分支模型，它能够应对 99% 的场景，剩下的那 1% 留给几乎不存在的极度变态的场景。

需要注意的是， 它只是一个模型，而不是一个工具； 你可以用工具去应用这个模型，也可以用最朴实的命令行。所以，重要的是理解概念，不要执着于实行的手段。

简单说来，Git Flow 就是给原本普普通通的分支赋予了不同的「职责」：

看到上面的「master」和「develop」加粗了吧？代表它们是「主要分支」，其他的分支是基于它们派生出来的。主要分支每种类型只能有一个，派生分支每个类型可以同时存在多个。各类型分支之间的关系用一张图来体现就是：

更多信息可参考 xi rong 所整理的《Git工作流指南》: .com / xi rong/my-git/blob/master/git-workflow-tutorial.md

一直不喜欢「＊＊最好用」这种命题，主观性太强，不会有一个结论。对于工具的选择，我一直都是秉承「哪个能更好地解决问题就用哪个」这个原则。所以，只要不影响到团队，用什么工具都是可以接受的。但根据多数开发人员的素质情况来看，建议使用图形化工具，例如 SourceTree（https:// www .sourcetreeapp .com ）。如果想用命令行，可以啊！先在心里问下自己：「我 Git 牛逼不？会不会惹麻烦给别人？」

在团队中应用 Git Flow 时，推荐使用 SourceTree 与 GitLab （ .com /）配合的形式：

SourceTree 和 GitLab 应该是相辅相成的存在，而不是互相取代。

为了将一些规范性的东西和 Git Flow 的部分操作自动化处理，要对 SourceTree 和 GitLab 进行一下配置。

按下 command + , 调出「Preferences」界面并切换到「Git」标签，勾选「Use rebase instead of merge by default for tracked branches」和「Do not fast-forward when merging, always create commit」。

这样设置之后，在点「Pull」按钮拉取代码时会自动执行 git pull --rebase；并且，每次合并时会自动创建新的包含分支信息的提交节点。

接下来，点击工具栏中的「Git Flow」按钮将相关的流程自动化。如果没有特殊需求，直接按下对话框中的「OK」就好了。初始化完成后会自动切换到 develop 分支。

这下再点「Git Flow」按钮所弹出的对话框就是选择创建分支类型的了。

在创建项目仓库后一定要把主要分支，也就是 master 和 develop 给保护起来。为它们设置权限，只有项目负责人可以进行推送和删除等操作。

被保护的分支在列表中会有特殊的标记进行区分。

在引入 Git Flow 之后，所有工作都要围绕着它来展开，将原本的流程与之结合形成「基于 Git Flow 的开发流程」。

在确定发布日期之后，将需要完成的内容细分一下分配出去，负责某个功能的开发人员利用 SourceTree 所提供的 Git Flow 工具创建一个对应的 feature 分支。如果是多人配合的话，创建分支并做一些初始化工作之后就推送创建远程分支；否则，直到功能开发完毕要合并进 develop 前，不要创建远程分支。

功能开发完并自测之后，先切换到 develop 分支将最新的代码拉取下来，再切换回自己负责的 feature 分支把 develop 分支的代码合并进来。合并方式参照上文中的「合并」，如果有冲突则自己和配合的人一起解决。

然后，到 GitLab 上的项目首页创建合并请求（merge request）。

「来源分支」选择要被合并的 feature 分支且「目标分支」选择 develop 分支后点击「比较分支」按钮，在出现的表单中将处理人指派为项目负责人。

项目负责人在收到合并请求时，应该先做下代码审核看看有没有明显的严重的错误；有问题就找负责开发的人去修改，没有就接受请求并删除对应的 feature 分支。

在将某次发布的所需功能全部开发完成时，就可以交付测试了。

负责测试的人创建一个 release 分支部署到测试环境进行测试；若发现了 bug，相应的开发人员就在 release 分支上或者基于 release 分支创建一个分支进行修复。

当确保某次发布的功能可以发布时，负责发布的人将 release 分支合并进 master 和 develop 并打上 tag，然后打包发布到线上环境。

建议打 tag 时在信息中详细描述这次发布的内容，如：添加了哪些功能，修复了什么问题。

当发现线上环境的代码有小问题或者做些文案修改时，相关开发人员就在本地创建 hotfix 分支进行修改，具体操作参考「开发功能」。

如果是相当严重的问题，可能就得回滚到上一个 tag 的版本了。

这里所提到的事情，虽非必需，但知道之后却会如虎添翼。

除了主要分支的名字是固定的之外，派生分支是需要自己命名的，这里就要有个命名规范了。强烈推荐用如下形式：

另外还有 tag，用语义化的版本号（）命名。

发布频率是影响开发人员与测试人员的新陈代谢和心情的重要因素之一，频繁无规律的发布会导致内分泌失调、情绪暴躁，致使爆粗口、砸电脑等状况出现。所以，确保一个固定的发布周期至关重要！

在有一波或几波需求来临之时，想挡掉是不太可能的，但可以在评审时将它（们）分期，在某个发布日之前只做一部分。这是必须要控制住的！不然任由着需求方说「这个今天一定要上」「那个明天急着用」的话，技术人员就等着进医院吧！

如何用github/gitlab做代码review

Github flow只有一个master长期分支，需要协同的人可以fork代码（其实就是新建了一个自己的分支，并且pull到了master上的代码），当你的功能需求代码完成之后，或者需要讨论的时候，就向master发起一个pull request。通知到别人评审、讨论、review你的代码，方便的是，在request提交之后评审的过程中，你还可以提交代码。等到你的request被accept，分支会合并到master，重新部署后，你原来的那个分支就可以删除啦。缺点是有时你的产品发布的代码版本和你master最新的版本并不是一个（比如因为苹果审核需要时间，那么你的代码就需要另一个分支来保留线上版本）。

Gitlab flow

引入了“上游优先”（upsteam first）的原则。只存在一个主分支master，它是所有其他分支的"上游"。只有上游分支采纳的代码变化，才能应用到其他分支。版本发布"的项目，建议的做法是每一个稳定版本，都要从master分支拉出一个分支。使用gitlab建立group project，可以将成员全部添加进小组中，每个人的提交都以分支合并进master分支的方式进行，我们可以将master设置成protected branch，这样就做到了强制代码review的机制，利于提升代码的质量。Issue 用于 Bug追踪和需求管理。建议先新建 Issue，再新建对应的功能分支。

代码管理-gitlab使用方法建议

对gitlab的使用主要从两个角度去分析，一个是管理员，一个是开发提交者。

1.1 初始配置

浏览器访问 http://服务器IP:11000

第一次访问会默认以root管理员用户登陆，需要输入两遍密码。

登陆后，可以看到，gitlab中主要围绕着以下几个概念进行操作：

group 团队

如果是作为个人使用，那么使用root用户创建project就可以实现上传下载代码了。

如果是小团队项目，就需要创建group，并在group中创建projects，添加user到group中，并给用户相应的权限。

1.1.1 关闭系统注册功能

为了便于管理，可以选择关闭gitlab的注册功能.

在主界面左边条依次选择 **Settings - General - Sign-up restrictions** ,点击 Expand 按钮，在 **Sign-up restrictions** 选项处将勾点掉，下拉点击 **Save changes** 就可以了。

1.1.2 修改网站logo

为了让我们的gitlab看起来更符合项目，可以对网站的logo进行调整，在 **Appearance** 中对 导航条图标（Navigation bar）、网站图标（Favicon）、登陆页图标（Sign in/Sign up pages）进行设置。

1.2 代码管理

1.2.1 团队协作方式

gitlab团队协作主要有两种方式：

使用fork

* 项目负责人在gitlab上新建一个项目，并分享URL给开发人员

* 开发人员在负责人的gitlab项目页面上点击“fork”按钮，将此项目fork到自己的gitlab上，这相当于是从负责人那拷贝了一份项目副本，无论开发人员如何修改代码都不会影响负责人那master分支上的代码

* 然后开发人员可以根据自己的项目分工，像对待普通项目一样做clone、add、commit、push等操作

* 如果开发人员人为一个小模块做好了，可以点击“**New Merge Request**”按钮，向负责人发送代码合并请求，要合并的代码文件也会以列表的形式同时发送给负责人，此时负责人会看到开发人员的请求，经审核如果代码没问题则会合并模块，并向开发人员发送确认合并的通知

不使用fork

1. 负责人为开发人员分别创建开发分支（namedev_branch）

* 项目负责人在gitlab上新建一个项目，并为每一个开发人员创建一个开发分支（namedev_branch）

* 开发人员clone项目之后，经git branch检查发现本地只有master分支，因此也需要把属于自己的开发分支也一起获取下来

`git fetch origin namedev_branch:namedev_branch`

`#拉取远程的一个叫namedev_branch的分支，并在本地创建一个叫namedev_branch的分支和远程的分支匹配`

* 切换到namedev_branch分支

`git checkout namedev_branch`

* 之后的操作如同对待普通项目一样

`git add hello.py`

`git commit -m "add hello.py"`

`git push -u origin namedev_branch #需要注意，是push到远程的namedev_branch分支`

~~这个方式感觉有风险，项目成员要注意自己的branch，很容易因为忽略branch直接向master提交变更，对代码管理会添加麻烦~~

2. 负责人不为开发人员分别创建开发分支 （开发者自己创建）

* 虽然项目负责人不分别为开发人员创建分支，但是需要把他们添加到一个group中，否则开发人员在向项目push自己的开发分支时遇到权限错误

* 开发人员在把项目clone之后需要为自己新建一个开发分支（namedev_branch），因为经由git branch查看发现本地只有master分支

`git branch namedev_branch #新建分支`

`git checkout namedev_branch #切换到开发分支`

`git push origin namedev_branch #将新建的开发分支push到远程项目上`

* 之后的操作如同对待普通项目一样

`git add hello.py`

`git commit -m "add hello.py"`

`git push -u origin namedev_branch #需要注意，是push到远程的namedev_branch分支`

之后，两种方式下项目负责人都可以在项目的gitlab主页上看到每个开发人员的工作进度，并考虑何时merge开发人员的分支到master分支上以完善项目。

所有成员包括项目负责人除克隆、修改、提交代码这些操作外，其它merge、建立分支等操作都在Gitlab网页端进行。

所有分支中，master分支为主干分支，此分支的代码不允许直接修改，只能由其它分支（一般只由develop分支）发出merge请求，经项目管理员代码审查通过后合并代码，普通开发者无权执行push、merge等操作，确保此分支任何时候、任何tag处导出的项目代码都是稳定可正常运行的代码；develop分支为开发分支，可以接受由其它分支发起的merge请求，同样只能经项目管理员代码审查通过后予以合并。

1.2.2 团队初始化

假设我们项目组分为两个组team1、team2，每个组有不同的组员和对应的不同的子项目,对项目组用户开放项目的访问，使用fork方式来做代码的更新和提交。

因此我们的gitlab的架构大概是这样的：

1. 创建Group，在主界面上方的加号选择**New Group**,创建Group只需要填写 Group path 、Group name、Description 几个选项就可以了。Visibility Level选项选择 Private-私有仓库

2. 创建user，对需要加进来的团员，由管理员负责给他们创建相应的用户，创建用户需要填写合法的Email地址，正常情况下会向这个Email发送登陆的初始连接，但是如果不方便的话，也可以在创建后由管理员修改这个user的初始登陆密码。

3. 选中Group添加相应的user，user的角色分以下几种：Guest、Reporter、Developer、Maintainer、owner，基本上我们只会用到guest和developer两种。

4. 在Group中创建project，选中Subgroup，点击 New project 来创建新的项目。

5. 项目完成创建后，相应的团队成员也可以使用fork来获取项目的内容,fork后属于成员自己的项目的git地址是不一样的，这个一定要注意，后面提交代码都是提交到这个fork项目的地址，只有在网页端发起merge request 以及从master更新fork项目时才会用到主项目

1.2.3 代码提交管理

当有新的代码提交请求时，项目负责人可以通过查看merge requests获取到来自fork或者branch的合并请求：

接受合并时，可以选择 Open in Web IDE 来检查审核变更的内容，确认没问题后点击Merge按钮来合并。

1.2.4 活跃度查询

右边条选择 Project - Activity 可以看到push、merge、issue、comment（讨论）等信息

选择 Cycle Analytics 可以看到图形化的分析内容，这部分需要有足够的数据支持，还需要好好研究下。

Cycle Analytics measures the time it takes to go from an idea to production for each project you have.

周期分析功能是监测从每个项目一个想法到产品所需的时间。

## 项目开发方式 issue+milestone+label

如何结合gitlab提供的这些功能来完整的梳理、管理一个产品、或者一个模块的开发方式

定义一个开发任务从开始如何分配到最后如何标识完成的过程。

这一块是用好gitlab的重点，否则就是用gitlab来做一个简单的代替svn的版本管理工具

2.1 fork项目

项目成员首先利用浏览器进入gitlab的系统后，查看自己的group和project，并fork自己需要参与开发的project。

在project的detail界面中点击fork按钮。

fork时会提示选择**Namespace**，这个选择是用来决定这个工程所属的，可以选Users,或者选择Groups，这个会影响到后面工程的url，项目成员都统一选择users本人的命名空间就可以了。

2.2 获取fork项目

项目内容获取主要使用git客户端工具来实现，项目开发人员首先要在本机安装git客户端软件，[下载地址]()

安装时基本都采用默认设置就可以了。

安装完成后我们主要使用Git Bash命令行工具来工作。

2.3 设置账户信息

设置修改本地对应的gitlab用户和邮箱。

2.4 配置ssh连接信息 （windows下没调成功）

1. 创建 SSH密钥

通过下面的命令生成密钥，将命令中的YOUR_EMAIL@YOUREMAIL.COM替换为注册Gitlab时用的Email地址。

`ssh-keygen -t rsa -C "duwj@gitlab.com"`

注意：Enter passphrase (empty for no passphrase) :时，可以直接按两次回车键输入一个空的 passphrase；也可以选择输入一个 passphrase 口令，如果此时你输入了一个passphrase，请牢记，之后每次提交时都需要输入这个口令来确认。

2. 获取公钥内容

SSH密钥生成结束后，根据提示信息找到SSH目录（通常ssh密钥保存路径均为~/.ssh 目录），会看到私钥id_rsa和公钥id_rsa.pub这两个文件，不要把私钥文件id_rsa的信息透露给任何人。

用记事本打开id_rsa.pub，复制里面的所有内容以备下一步使用。

3. 将密钥中的公钥添加到Gitlab

登录Gitlab的web站点，进入个人资料设置 - SSH Keys页面，将第2步所获得的内容粘贴在文本框key内，并填写title以便记忆，而后保存。

2.5 克隆代码

在gitlab网页端进入project的detail中可以下拉看到提示的代码信息。

这样在本地就可以获取到fork的项目内容。

2.6 正常代码更新提交

2.7 更新本地仓库内容命令

2.8 请求合并到master

在网页端进入到project的detail界面后，如果fork的项目代码有变动，在界面右上角会提示**Create merge request** 来提交合并申请

点击创建后，输入本次提交的title和描述，描述要说明本次提交修改的脚本、修改的内容等信息，便于管理员审核。

2.9 【关键】同步最新master库内容

fork后的项目不会自动从master主分支获取更新，需要负责fork的开发人员自己更新版本

如何更新已经fork的代码：

* 首先要先确定一下是否建立了主repo的远程源：

在本地项目库下执行 `git remote -v`

* 如果里面只能看到你自己的两个源(fetch 和 push)，那就需要添加主repo的源：

* fetch源分支的新版本到本地

执行 `git fetch upstream`

执行后本地库的内容会更新为与master库一致的内容

* 合并本地两个版本的代码：

执行 `git merge upstream/master`

* 将在本地合并后的代码push到自己的github上去，以更新github上fork的仓库

执行 `git push origin master `

执行后网页端的仓库内容更新为合并后的新版本

对于开发人员来说，会使用fork克隆项目，会使用本地git客户端对项目内容进行更新、编辑、提交，会在网页端提交代码合并申请并且规范编写申请描述就足够了。

对管理人员来说，使用gitlab能方便的知道每个员工负责的内容的提交进度情况，方便对他们提交的代码进行质量的检查走读，还有更多统计类、开发进度管理等等功能，但是需要熟练掌握gitlab上的一些功能使用方法，比如使用issue来管理开发任务分配，使用milestone来制定和管理里程碑等等。

# 3. gitlab使用开发规范

参考：[gitlab使用开发规范]()