一.总的 Release

Gitflow 定义参考

具体定义： https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

二. SemVer定义

https://semver.org/lang/zh-CN/

1.项目中使用规范

1.1.分支命名规范

单词使用单数，完全小写，不要加 s

feature/short-description
release/v0.1.1
bugfix/short-description
hotfix/short-description

short-description 表示自己起的名字

1.2.squash merge使用

私人分支--> 公共分支，用 squash merge ，自己的杂七杂八的的提交可以压缩成 1 个 commit，
公共分支 --> 公共分支用 merge pull request，要保留其他人的提交历史

1.3.Release 分支

从 develop 切出 release/v0.4.1，
测试完成，合到 main，打 tag v0.4.1-alpha.1, v0.4.1-beta.1, v0.4.1-rc.1 具体适合哪个待定
devops 基于 tag 发版 testnet

1.4. Hotfix 分支

例如要修 release/v0.4.1

基于前面的 release，修复
测试完成，合并到 main，打 tag v0.4.1-alpha.2 之类的
devops 基于 tag 发版
Main 合回 develop
直到没有需要fix的东西，打 tag v0.4.1 最终版
如果又发现了问题，从 develop 切 release/v0.4.2 来修吧，等于是把 fix 放到下个小版本

2. 需要外部配合的 break change

升中间版本号，比如 v0.5.0，第一位暂时保持 0 不变

3.DevOps 部署只用 tag

分支保护规则

main develop 不允许直接 push，不允许 force push
release/* 不允许直接push，允许指定的人 force push (用于极少情况下回滚代码用)
重要的 feature 分支不允许直接 push：

二. 代码风格参考规范

1.Go imports

package genesis

import (
        "bytes"
        "encoding/json"
        "math/big"
        "os"
        "testing"
        "time"

        "github.com/ethereum/go-ethereum/accounts/abi/bind"
        "github.com/ethereum/go-ethereum/accounts/abi/bind/backends"
        "github.com/ethereum/go-ethereum/common"
        "github.com/ethereum/go-ethereum/common/hexutil"
        "github.com/ethereum/go-ethereum/crypto"
        "github.com/ethereum/go-ethereum/params"

        "github.com/ethereum-optimism/optimism/op-bindings/bindings"
        "github.com/ethereum-optimism/optimism/op-bindings/predeploys"
        "github.com/ethereum-optimism/optimism/op-chain-ops/deployer"

        "github.com/stretchr/testify/require"
)

第一部分，golang原生的包第二部分，以太坊里面的包第三部分，本地包第四部分，其他第三方的包

参考这个文档，配置一下goland，然后通过go format imports就能自动实现 https://medium.com/codex/better-format-your-go-imports-ce22cd648b34 Comment

// BuildL1DeveloperGenesis will create a L1 genesis block after creating
// all of the state required for an Optimism network to function.
func BuildL1DeveloperGenesis(config *DeployConfig) (*core.Genesis, error) {
}

注释以函数名开头，主要描述此函数的功能，如果参数比较多，或者命名不能直观的表示参数代表的意思，在注释里面也要加上说明

2.Tests

2.1.Unit tests

https://github.com/ethereum-optimism/optimism/blob/e33d000561af65dbf438f5b8acfcc50c729a775e/op-chain-ops/genesis/layer_one.go#LL65C3-L65C3

// BuildL1DeveloperGenesis will create a L1 genesis block after creating
// all of the state required for an Optimism network to function.
func BuildL1DeveloperGenesis(config *DeployConfig) (*core.Genesis, error) {
}

https://github.com/ethereum-optimism/optimism/blob/e33d000561af65dbf438f5b8acfcc50c729a775e/op-chain-ops/genesis/layer_one_test.go#L24

func TestBuildL1DeveloperGenesis(t *testing.T) {
        b, err := os.ReadFile("testdata/test-deploy-config-full.json")
        require.NoError(t, err)
        dec := json.NewDecoder(bytes.NewReader(b))
        config := new(DeployConfig)

2.2.命名

以Test+测试对象函数名: TestBuildL1DeveloperGenesis = Test + BuildL1DeveloperGenesis

适用场景 - 对功能比较单一，且相对独立的函数，可以通过单元测试验证功能。并且后期维护的人员也可以通过单元测试了解函数功能。

3.Coverage

Code reviewer需要在本地运行单元测试，并评估单元测试的覆盖率。
PR里面可以自动生成 unittestc运行的报告

4.Issue

4.1.Bug

标题里面最好能简要表示是什么问题，如果能确定是那个组件出问题，那么以这个组件开头，比如sequencer里面问题那么标题可以为

Sequencer: Panic issue

如果这个 bug 且需要他人修复，那么需要写明 bug 的现象，发现 bug 的运行环境，binary 版本号，以及重现步骤
给改 issue 打上标签，比如 bug，improvement，feature

4,2. Improvement & Feature

标题里面简要写明要做什么样Improvement & feature
在description里面写明为什么需要这个Improvement & feature
如果是一个全新的feature，那么应该在issue里面把spec讨论清楚，并且这个spec要被包含在相应的PR中
给改issue打上标签，比如bug，improvement，feature

5. PR

PR 要有对应的 Issue，如果 Issue 里面对要解决的问题已经解决方案进行了详细的说明和论证，那么 PR 里面的 descrption 就是简单的写成: Close [issue 链接]。对于develop到main合并的PR，在PR的description里面要列出所有issue，并加上其他release方面的描述。
创建和修改 PR 自动触发运行 unitest 和 e2e test(这个需要配置 github，我接下来会着手这块)，有运行失败的情况，不允许 merge。必须着手去解决测试的问题
PR 的 viewer 人员一定要详细看代码，不能走过场。
还没开发完的 PR以 WIP(work in progress) 开头，可以 review 的 PR 以 R4R(Ready for review)开头

一般的 GitHub 项目代码管理规范