Gerrit搭建与代码下载

1、向管理员申请gerrit账户

一般为公司指定的个人邮箱。

2、服务器名以及地址

3、配置.gitconfig信息

Linux 的.gitconfig 在 Home 目录下。

email：你的公司邮箱

name：cm给你分配的用户名

editor：提交massage时用的编辑器

ui：高亮显示

alias：一些短引用，比如git branch，可以直接写git br

url（2处）：要替换为自己用户名，下例为ssh://hp@192.168.8.74:29418/，替换hp为上面name节点的名称，

比如范建华的可为：ssh://fjh@192.168.8.74:29418/

insteadOf：勿修改

huangpeng@ubuntu:~$ cat .gitconfig
[user]
    email = hp@hpplay.cn
    name = hp
[core]
    editor = vim
[color]
    ui = auto
[alias]
    st = status
    br = branch
    co = checkout
    ci = commit
[url "ssh://hp@192.168.8.74:29418/"]
    insteadOf = "gerrit:"
[url "ssh://hp@192.168.8.74:29418/opensource/git-repo"]
    InsteadOf=https://gerrit.googlesource.com/git-repo

4、登录并注册

4.1 用步骤1申请的账户名和密码登录

4.2 跳转到注册页面

4.3 注册邮箱

4.4 收到邮件，【拷贝】链接到浏览器

4.5 完成注册

5、配置SSH Public Keys

5.1 Linux/Ubuntu/gitbash

5.1.1 生成key，输入

ssh-keygen -t rsa -C fjh@hpplay.cn
cat ~/.ssh/id_rsa.pub

过程中会要求输入密码，为了方便的话，可以不设置密码，直接回车即可

5.1.2 把~/.ssh/id_rsa.pub的内容copy到gerrit里面，add

5.1.3 结果如下

5.1.4 配置账户

git config --global user.email "fjh@hpplay.cn"
git config --global user.name "Fan Jianhua"
git config --global core.editor vi

5.2 Windows

5.2.1 使用git的windows版本自带的Git Bash

重复上面linux步骤即可，和linux的使用一样

5.2.2 其他可视化工具，这里只列出SourceTree

5.2.2.1 创建秘钥

5.2.2.2 拷贝上面选中的key值到gerrit，Add进去

5.2.2.3 保存成private key之后，在系统托盘里面增加这个key值

5.2.2.4 剩下的使用和原来没有什么区别，只是不能直接push到git库里面了

6、提交代码

6.1 下载

git clone ssh://xx@192.168.8.74:29418/test

6.2 修改代码并本地提交

git commit -s

6.3 提交到gerrit

git push origin HEAD:refs/for/master
        第一次提交可能会缺少Chang-Id，执行下面语句
gitdir=$(git rev-parse --git-dir); scp -p -P 29418 fjh@192.168.8.247:hooks/commit-msg ${gitdir}/hooks/commit-msg"
git commit --amend
git push origin HEAD:refs/for/master

6.4 现在就可以在gerrit上看到提交信息了

6.5 配置Sourcetree，使其可push到Gerrit

如果不想使用命令提交，也可以在Sourcetree中添加push配置

打开config文件，如上图：在[remote "origin"]里面添加 push = refs/heads/:refs/for/

这样就可以使用 “推送” 按钮将文件修改push到Gerrit上了

7、Linux下repo配置

7.1 该配置是在Ubuntu下验证，下载repo，比如放在~/bin/repo

7.2 配置环境变量，

huangpeng@ubuntu:~$ vi .bashrc

export PATH=~/bin:$PATH

8、Gerrit提交规范

1、Message提交规范

ModuleName: do something

details

Ticket: LEBO5X-xxx

说明：

ModuleName是指工程里面具有比较明确划分的模块名称，如果工程比较单一，一个ModuleName就可以

比如：接收端应用，可以定义为APP即可

ModuleName后面的冒号后紧接着一个小写空格，然后是提交的内容描述，不可泛泛，控制在80列之内。

ModuleName下面空一行，再换行写具体更加详细的描述，可选。

Ticket是指jira的bug id，每次提交必须有一个bug对应，在bug里面有对本次提交的具体原因等信息

2、Gerrit提交流程

第一步：开发者自己review后+1

第二步：owner +2

第三步：开发者submit

Git 常用命令

工作区：Workspace
暂存区：Index/Stage
仓库区（或本地仓库）：Repository
远程仓库：Remote

以下是现在工作中可能会用到的一些简单的Git命令

一、获取Git仓库

git clone

获取git仓库，示例：

git clone ssh://tcc@192.168.8.74:29418/AndroidReceiver-SDK

二、分支

//查看分支

git branch 列出本地所有分支
git branch -r 列出所有远程分支
git branch -a 列出所有远程和本地分支

//切换分支

git checkout [branch-name] 切换到指定分支，并更新工作区

//新建本地分支

git branch [brnach-name] 新建分支，但依然留在当前分支
git checkout -b [branch-name] 新建分支，并切换到新分支

//删除本地分支

git branch -d [branch-name] 删除本地分支

三、拉取代码

git pull 从远程获取最新版本并merge到本地
git fetch 从远程获取最新版本到本地，不会自动merge

git fetch 示例：

//首先从远程的origin的master主分支下载最新的版本到origin/master分支上 git fetch origin master //然后比较本地的master分支和origin/master分支的差别 git log -p master..origin/master //最后进行合并 git merge origin/master

git fetch 示例2：

git fetch origin master:tmp git diff tmp git merge tmp

四、提交代码

git status 显示有变更的文件
git add [file] 提交指定文件到暂存区
git add [dir] 提交指定目录到暂存区
git add . 添加当前目录的所有文件到暂存区
git commit 提交暂存区到仓库区
git commit --amend 用来改写上一次commit的提交信息
git cherry-pick [commit] 选择一个commit，合并进当前分支

4.1、乐播 git commit 提交信息规范

模块（英文大写）: 提交信息（首行英文）

MODULE: commit message

示例：

SDK: modify VideoPlayer for leishi project

将播放器播放功能与播控UI实现分离

如果是解决在JIRA中提出的bug，需要把JIRA中bug号加上格式如下

Ticket: bug编号

示例：

SDK: Ariplay or DLNA play failed

Airplay video status error Airplay or DLNA play failed

Ticket: Base130-1, Base130-2

如果修改内容涉及到SDK和APP，可以使用 ALL来代替模块，例如

ALL: modify SDK for leishi project and supply demo module

五、推送

git push

git push [remote] [branch-name] 上传本地指定分支到远程仓库示例： git push origin r1.3.2_bugfix //Gerrit git push origin HEAD:refs/for/r1.3.2_bugfix

六、撤销修改

git checkout [file] 恢复暂存区的指定文件到工作区
git chekcout . 恢复暂存区的所有文件到工作区
git chekcout [commit] [file] 恢复某个commit的指定文件到暂存区和工作区
git reset [file] 重置暂存区的指定文件，与上一次commit保持一致，但工作区不变
git reset --hard 重置暂存区与工作区，与上一次commit保持一致
git reset [commit] 重置当前分支的指针为指定commit，同时重置暂存区，但工作区不变
git reset --hard [commit] 重置当前分支的HEAD为指定commit，同时重置暂存区和工作区，与指定commit一致

七、查看提交历史

git log 显示当前分支的版本历史
git log --oneline 参数将每次提交记录汇总成一行,默认情况下,会展示commit的id和commit信息的第一行
git log --follow [file]显示某个文件的版本历史，包括文件改名
git log --stat 显示commit历史，以及每次commit发生变更的文件
git log -S [keyword] 搜索提交历史，根据关键词
git blame [file] 显示指定文件是什么人在什么时间修改过
git show [commit] 显示某次提交的元数据和内容变化
git show --name-only [commit] 显示某次提交发生变化的文件
git show [commit]:[filename] 显示某次提交时，某个文件的内容
git diff HEAD 显示工作区与当前分支最新commit之间的差异
git diff 显示暂存区和工作区的差异

八、标签

git tag 列出所有tag
git show [tag-name] 查看tag信息

//切换代码到指定TAG

git checkout [tag-name] 切换到指定tag
git checkout -b [branch-name] [tag-name] 新建一个分支，指向某个tag

//创建TAG

git tag [tag-name] 新建一个tag在当前commit
git tag [tag-name] [commit] 新建一个tag在指定commit

//删除TAG

git tag -d [tag-name] 删除本地tag

推送代码修改到Gerrit

首先提交修改信息，与直接推送到git服务器不同的是，这里是把修改信息推送到Gerrit，待通过Gerrit审核之后，才能把代码合并到git服务器

git提交流程

gerrit提交流程

具体到提交命令就是

//git git push origin r1.3.2_bugfix

//Gerrit git push origin HEAD:refs/for/r1.3.2_bugfix

如果使用Sourcetree来提交代码需要在config文件中添加 push = refs/heads/:refs/for/

添加审核人

通过第二步把修改信息推送到Gerrit上之后，登录Gerrit查看提交信息

点击修改信息，查看修改详情

添加审核人，等待审核结果

代码审核通过，submit

代码审核不通过，继续修改，commit --amend

Java代码规范

一、为什么需要编码规范

编码规范对于程序员而言尤为重要，有以下几个原因：

一个软件的生命周期中，80%的花费在于维护
几乎没有任何一个软件，在其整个生命周期中，均由最初的开发人员来维护
编码规范可以改善软件的可读性，可以让程序员尽快而彻底地理解新的代码

二、命名

1. 包命名

命名规则：一个唯一包名的前缀总是全部小写的ASCII 字母并且是一个顶级域名，通常是com，edu，gov，mil，net，org。包名的后续部分根据不同机构各自内部的命名规范而不尽相同。这类命名规范可能以特定目录名的组成来区分部门 (department) ，项目(project)，机器(machine)，或注册名(login names)。

例如：

com.lebo.项目缩写.模块名 à com.lebo.player.live

com.lebo.项目缩写.层级名 à com.lebo.player.activities

2. 类和接口命名

命名规则：类名是个一名词，采用大小写混合的方式，每个单词的首字母大写。尽量使你的类名简洁而富于描述。使用完整单词，避免缩写词(除非该缩写词被更广泛使用，像URL，HTML)，类名必须使用驼峰命名法，即首字母必须大写，如果为词组，则每个单词的首字母也必须要大写，类名必须使用名词，或名词词组。接口一般要使用able、ible、er等后缀,

例如：

class BookMarkAdd à 正确

class AddBookReadPlanActivity à 错误！应为 class BookReadPlanAddActivity

3. 方法的命名

命名规则：方法名是一个动词，采用大小写混合的方式，第一个单词的首字母小写，其后单词的首字母大写。类中常用方法的命名：

类的获取方法（一般具有返回值）一般要求在被访问的字段名前加上get，如
getFirstName()，getLastName()。一般来说，get前缀方法返回的是单个值，find前缀的方法返回的是列表值。

类的设置方法（一般返回类型为void）：被访问字段名的前面加上前缀 set，如
setFirstName(),setLastName().

类的布尔型的判断方法一般要求方法名使用单词 is做前缀，如isPersistent()，isString()。或者使用具有逻辑意义的单词，例如equal 或equals。

类的普通方法一般采用完整的英文描述说明成员方法功能，第一个单词尽可能采用动词，首字母小写，如openFile（），addCount（）。

构造方法应该用递增的方式写。（参数多的写在后面）。

4. 变量及常量命名

变量名应简短且富于描述
第一个单词的首字母小写，其后单词的首字母大写
临时整型变量通常被取名为 i，j，k，m 和 n；字符型一般为c，d，e
非public的、非static的字段名称以m开头。
static字段名称以s开头，final static 全大写，可以不以S开头
其它字段以小写字母开头。
常量全部字母大写并用下划线分隔。

例如：

public class MyClass {

    public static final int SOME_CONSTANT = 42;
    
    public int publicField;
    
    private static MyClass sSingleton;
    
    int mPackagePrivate;
    
    private int mPrivate;
    
    protected int mProtected;

}

5. 异常命名

自定义异常的命名必须以Exception为结尾。已明确标示为一个异常。

6. layout 命名

layout xml 的命名必须以全部单词小写，单词间以下划线分割，并且使用名词或名词词组，即使用模块名_功能名称来命名。例如：

knowledge_gained_main.xml à 正确

list_book.xml à 错误！

7. id 命名

layout 中所使用的id必须以全部单词小写，单词间以下划线分割，并且使用名词或名词词组，末尾加上view的缩写，并且要求能够通过id直接理解当前组件要实现的功能。例如：

TextView @+id/textbookname à错误！应为 @+id/book_name_show_tv

EditText @+id/textbookname à错误！应为 @+id/book_name_edit_et

8. 资源命名

layout中所使用的所有资源（如drawable,style等）命名必须以全部单词小写，单词间以下划线分割，并且尽可能的使用名词或名词组，即使用模块名_用途来命名。如果为公共资源，如分割线等，则直接用用途来命名，例如：

menu_icon_navigate.png à 正确

某分割线：line.png 或 separator.png à正确

9. 书写顺序

用于日志记录的TAG放在最前面
static final放在1)后面，按照语义，每块定义中间加空格和注释
用于Handler的WHAT值，要分语义赋值，语义相关的值依次累加
相关语义的变量要有相同的前缀，类似于包名命名方式
自定义View要把所在的layout写到注释里面
View的定义顺序要与layout里面的顺序一致
系统类变量定义
自定义类变量定义
普通变量定义

如：

private static final String TAG = "LiveView";

    // WHAT values using by handler

private static final int WHAT_ADD_CHANNEL_HISTORY = 0;

private static final int WHAT_PLAY_CHANNEL = 10;

private static final int WHAT_PLAY_PIP = 11;

    // keys of data when play channel used

private static final String KEY_CHANNEL_INDEX = "channel_index";

private static final String KEY_CHANNEL_URL = "channel_url";

    // in activity_main.xml

private TitleView mTitleView;

    // in tv_content.xml

private VideoPlayerController mMainPlayerController;

private VideoPlayerController mPipPlayerController;

private ChannelMenu mChannelMenuView;

    // dynamic add/remove

private VerifyView mVerifyView;

private AudioManager mAudioManager;

private SharedPreferences mPrefs;

private ChannelManager mChannelManager;

private LayerType mCurrentLayer = LayerType.LAYER_MAIN;

private boolean mHasShowLiveGuide;

三、注释

Java 程序有两类注释：实现注释(implementation comments)和文档注释(document comments)。实现注释是使用/.../和//界定的注释。文档注释(被称为"doc comments")由/**...*/界定。文档注释可以通过javadoc 工具转换成HTML 文件。

1. 文件注释

每个文件的开头都应该有一句版权说明。然后下面应该是package包语句和import语句，每个语句块之间用空行分隔。然后是类或接口的定义。如果不过认证，就不用加。

/*

 * Copyright (C) 2013 The Android Open Source Project

 *

 * Licensed under the Apache License, Version 2.0 (the "License");

 * you may not use this file except in compliance with the License.

 * You may obtain a copy of the License at

 *

 *      http://www.apache.org/licenses/LICENSE-2.0

 *

 * Unless required by applicable law or agreed to in writing, software

 * distributed under the License is distributed on an "AS IS" BASIS,

 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.

 * See the License for the specific language governing permissions and

 * limitations under the License.

 */

package com.android.internal.foo;

import android.os.Blah;

import android.view.Yada;

import java.sql.ResultSet;

import java.sql.SQLException;

乐播文件头注释

/**

* <p>Description: </p>

* <p>Copyright: Copyright (c) 2018</p>

* <p>Company: www.hpplay.com.cn</p>

* @author LEBO

* @date ${date}

*/

2. 类注释

每个类和自建的public方法必须包含Javadoc注释，注释至少要包含描述该类或方法用途的语句。并且该语句应该用第三人称的动词形式来开头。注释尽量写中文。

/**

 * Does X and Y and provides an abstraction for Z.

 */

public class Foo {

    ...

}

3. 方法注释

每一个方法的注释都要包含当前方法的用途，当前方法参数的含义，当前方法返回值的内容和抛出异常的列表。

/** Returns the correctly rounded positive square root of a double value. */

static double sqrt(double a) {

    ...

}

或

/**

 * Constructs a new String by converting the specified array of

 * bytes using the platform's default character encoding.

 */

public String(byte[] bytes) {

    ...

}

4. 类成员变量和常量注释

公共成员变量和常量需要使用java doc形式的注释，以说明当前变量或常量的含义

5. XML注释

如果当前layout 或资源需要被多处调用，或为公共使用的layout（若list_item），或者需要特殊说明的，则需要在xml写明注释。要求注释清晰易懂。

6. TODO注释

对那些临时性的、短期的、够棒但不完美的代码，请使用TODO注释。

TODO注释应该包含全部大写的TODO，后跟一个冒号，例如：

// TODO: Remove this code after the UrlTable2 has been checked in.

// TODO: Change this to use a flag instead of a constant.

如果TODO注释是“将来要做某事”的格式，则请确保包含一个很明确的日期（“在2005年11月会修正”），或是一个很明确的事件之后删除本段代码。

7. 修改OpenSource源码注释要求

必须以下面注释开头和结尾，后面可以自行增加日期、作者、原因：

// Lebo START

// Lebo END

8. 其他注释

方法内部的注释如果需要多行使用/*…… */形式，如果为单行是用//……形式的注释。不要再方法内部使用 java doc 形式的注释“/……/”，简单的区分方法是，java doc形式的注释在 eclipse中为蓝色，普通注释为绿色。

四、代码风格

1. 缩进

不允许使用Tab进行缩进，使用4空格进行缩进。每换一次行缩进增加4个空格缩进，比如：

    Instrument i =

            someLongExpression(that, wouldNotFit, on, one, line); à正确

    Instrument i =

       someLongExpression(that, wouldNotFit, on, one, line); à错误

2. 空行

空行将逻辑相关的代码段分隔开，以提高可读性。

下列情况应该总是使用空行：

一个源文件的两个片段(section)之间
类声明和接口声明之间
两个方法之间
方法内的局部变量和方法的第一条语句之间
一个方法内的两个逻辑段之间，用以提高可读性
不同逻辑变量区域之间

3. import

使用eclipse等自动化工具做这个工作

Import最小颗粒类，比如：

import foo.Bar;à正确

import foo.*;à错误

对Import语句排序

4. 使用标准的大括号风格

大括号不单独占用一行；它们紧接着上一行书写。就像这样：

class MyClass {

int func() {

if (something) {

            // ...

        } else if (somethingElse) {

            // ...

        } else {

            // ...

        }

    }

}

对于单行语句，也要增加大括号括起来，像这样

if (condition) {

        body();

    } à正确

if (condition) body();à错误

if (condition)

        body();à错误

5. 不建议使用三目运算符

6. 限制代码行和注释的长度

每行代码的长度不超过100个字符。

注释的长度也不能超过100个字符。

五、其他约定

1. 异常

禁止忽略异常，比如下面代码：

void setServerPort(String value) {

try {

  int serverPort = Integer.parseInt(value);

       } catch (NumberFormatException e) {

    }

    }

可接受的替代方案包括：

    抛出默认异常
    抛出自定义异常
    处理错误并在catch {}语句块中替换为合适的值
    捕获异常并抛出RuntimeException。这种做法比较危险：只有确信发生该错误时最合适的做法就是崩溃，才需要这么做。
    忽略异常，但必须把原因注释出来
    忽略异常，但必须把原因打印出来

不建议捕获顶级的Exception，比如下面的代码：

ry {

        someComplicatedIOFunction();        // may throw IOException

        someComplicatedParsingFunction();   // may throw ParsingException

        someComplicatedSecurityFunction();  // may throw SecurityException

        // phew, made it all the way

    } catch (Exception e) {                 // I'll just catch all exceptions

        handleError();                      // with one generic handler!

    }

比捕获顶级Exception更好的方案：

    分开捕获每一种异常，在一条try语句后面跟随多个catch 语句块。这样可能会有点别扭，但总比捕获所有Exception要好些。请小心别在catch语句块中重复执行大量的代码。
    重新组织一下代码，使用多个try块，使错误处理的粒度更细一些。把IO从解析内容的代码中分离出来，根据各自的情况进行单独的错误处理。
    再次抛出异常。很多时候在你这个级别根本就没必要捕获这个异常，只要让方法抛出该异常即可。

2. 限制变量的作用范围

局部变量应该限制为最小的作用范围。使用局部变量，可以增加代码的可读性和可维护性，并且降低发生错误的可能性，每个变量都应该在最小范围的代码块中进行声明，该代码块的大小只要能够包含所有对该变量的使用即可，所以循环变量都应该在for语句内进行声明，比如：

for (int i = 0; i < n; i++) {

        doSomethinginformation;

    }

和

for (Iterator i = c.iterator(); i.hasNext(); ) {

        doSomethingElse(i.next());

    }

3. 去除IDE提示的警号

注意@SuppressWarnings和@Deprecated要写在方法的头部

4. 简称要保持在同一项目内一致。

5. 不建议使用View.post和View.postDelayed

禁止使用View.post和View.postDelayed，需要的地方替换为Handler的Message方式，以使代码可控。

6. Log

禁止在循环内打印VERBOSE级别以上的log
禁止直接使用系统默认log，必须使用项目内自定义的log类
打印log的开关必须有统一的控制

7. 保持一致

编码规范的重要目的就是为了保持一致。如果你正在编写代码，请花几分钟浏览一下前后的其它代码，以确定它们的风格。如果它们在if语句前后使用了空格，那你也应该遵循。如果它们的注释是用星号组成的框框围起来的，那也请你照办。

8. 编码格式

为了跨平台以及跨编辑器，请统一使用UTF-8格式

Android Studio 代码格式化配置

Android Studio统一使用Eclipse的格式化配置，可通过以下几个步骤在Android Studio中配置使用Eclipse的代码格式化方式：

一、Android Studio安装 Eclipse Code Formatter 插件

编辑

1.1、搜索Eclipse Code Formatter插件

1.2、安装Eclipse Code Formatter

安装完毕重启Android Studio

二、从Eclipse中导出代码格式化配置文件

2.1、导出配置文件

工具栏点击Windows选择Preferences

导出代码格式化配置文件

在导出之前需要修改很多默认配置，这里就不再一一赘述，建议直接使用前面配置好的xml文件，以便于保证代码格式化风格统一。

三、在Android Studio中使用eclipse_format.xml文件

编辑

3.1、如下图，找到Eclipse Code Formatter插件，找到Eclipse Java Formatter config file,选择第二步从Eclipse中导出的配置文件

3.2、在工具栏中将代码格式化插件更换为 Eclipse Code Formatter

更换前

更换后

经过以上三步，在Android Studio中就可以使用Eclipse的代码格式化方式了

C 语言代码规范

代码格式规范

使用格式化工具CoolFormat，这里不做具体展开说明。

github.com/akof1314/Su… akof1314.github.io/CoolFormat/… CoolFormat配置：

[SynTidy] C++=""-A10-xn-xc-xk-xV-s4-S-w-Y-p-xg-H-U-k3-xb-j-xf-xh-c-xy""

命名规范

1、文件命名：小写+下划线

2、函数命名：小写+下划线

3、结构体，枚举等类型命名：大驼峰

4、常量，宏：大写+下划线

5、参数，变量：前缀+小驼峰

6、命名前缀：

n：整数

b：boolean类型

p：指针

o：结构体

str：字符串

g_：全局变量

k_:   const 全局常量

xxxMutex, xxxCond, arrXxx, pArrXxx
jobjXxx,  jMethodIdXxx

7，避免使用魔数，建议使用宏或者常量

返回值

外部接口返回值：int，0 成功，其它失败

Cplusplus语言编程规范

gerrit 代码冲突解决方案

一定要确定自己处于要提交的分支上进行代码修改

因为gerrit代码冲突了是在push之后才出现的，此时仓库里面已经有了对应的提交。这里可以先将代码还原到之前的状态

git reset --hard HEAD~10

连 untracked 的目录也一起删掉

git clean -fd

然后将最新的代码拉取下来

git pull

然后将之前push的代码拉去到本地，Cherry-pick 改动到本地，Cherry-pick命令来自gerrit上的download下箭头，位置如下：

git fetch ssh://zpw@192.168.8.250:29418/phoenix/SDK refs/changes/23/101923/1 && git cherry-pick FETCH_HEAD

通过 git status 即可发现冲突

解决完冲突之后，提交代码 git add . git commit -s

将带吗推送到远程仓库

git push origin HEAD:refs/for/r60016_201_bugfix_1.0

gerrit 修改无效提交，或者补充

查找你需要修改的那条记录的commit

git log

修改已经提交至gerrit的commit

$ git checkout 有问题的commit
$ <修改>
$ git add <file>
$ git commit --amend
$ git push origin HEAD:refs/for/master
Counting objects: 5, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 546 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
remote: Processing changes: updated: 1, done
remote:
remote: Updated Changes:
remote:   http://gerrithost:8080/68
remote:
To ssh://gerrithost:29418/RecipeBook.git
 * [new branch]      HEAD -> refs/for/master

merge 两个分支

merge 前最好保证两个将要 merge 的分支是服务器上的最新代码。

比如要将 test2 merge 到 test1。

git merge test2 --no-f

此时已经将 test2 分支 merge 到 test1 了。可能会发生冲突，所以此时需要知道代码的具体逻辑，解决冲突。

冲突解决完毕之后，需要提交代码。

git commit -s

然后就可以提交到远程仓库。

git push origin HEAD:refs/for/test1