小编Jak*_*cki的帖子

所以情况如下:有一个实体需要与字典连接.想象一下以下结构

create table Address (
    addressId bigint not null,
    addressLine1 varchar(255),
    city varchar(255),
    country varchar(255),
    state varchar(255),
    zipCode varchar(255),
    primary key (addressId)
)

create table STATES_DICT (
    state_code varchar(255),
    state_fullname varchar(255), 
    primary key (state_code)
)

我想将ADDRESS和STATE_DICTIONARY映射到一个实体.

@Entity
@Table(name = "ADDRESS")
public class Address implements Serializable {

    @Id
    @Column(name = "ADDRESSID")
    private int addressId;

    @Column(name = "ADDRESSLINE1")
    private String addressLine1;

    @Column(name = "STATE")
    private String state;

    //??? annotations
    private String fullStateName;

    @Column(name = "ZIPCODE")
    private String zipCode;

    @Column(name = "CITY")
    private …

我最近一直在研究基于主干的开发（https://trunkbaseddevelopment.com），我们所做的非常适合该方法（小团队、频繁发布、一些直接提交或短期分支等）。

我唯一遇到的困难是标记版本。我们进行 CI，但并非每次都会投入生产，并且我们希望在代码交付到客户环境后增加（更改）版本。

在主干基础开发中（以惯用的方式）我应该如何发布？您对 master 上的发布提交感觉如何？我可以看到两种方法（我正在使用 Java + Maven 位，这只是应该出现的工具）。

方法#1

1. // trunk 中的版本信息: 'SNAPSHOT'
2. git checkout -b 版本/1.11
3. // 更新发布分支上的版本并提交
4. // 构建完整的项目并发布
5. git 结账大师
6. // 继续特性

方法#2

1. // 主干中的版本信息: '1.11-SNAPSHOT'
2. git 分支发布/1.11
3. // 将 master 分支上的版本更新为 1.12-SNAPSHOT'
4. git checkout 版本/1.11
5. // 将发布分支上的版本更新为“1.11”并提交
6. // 构建完整的项目并发布
7. git 结账大师
8. // 继续特性

第二种方法在存储库的历史记录中留下了一个提交，我不确定对此有何感受。后一种方法使代码更容易追踪，发布过程也更容易。

顺便说一句，我不太关心错误修复等。我们确实发布了新版本。但如果需要修补程序，我们计划挑选