开发阶段
- Git 配置
- 团队成员各自从主分支拉取开发分支，例如基于
master 分支拉取 feature - <feature_name> 分支进行开发。
- 频繁提交代码到本地分支，每次提交都添加有意义的 commit 信息。例如：
git commit -m "Implement user login feature"。
- 代码签名配置
- 为开发机器生成代码签名密钥对（如果尚未生成）。可以使用工具如
keytool 等。例如在 Kotlin 项目中，若使用 Gradle 构建，在 build.gradle.kts 中配置签名相关属性（假设使用 JKS 密钥库）：
android {
signingConfigs {
create("release") {
storeFile = file("path/to/keystore.jks")
storePassword = "keystore_password"
keyAlias = "key_alias"
keyPassword = "key_password"
}
}
buildTypes {
getByName("release") {
signingConfig = signingConfigs.getByName("release")
}
}
}
- 在开发过程中，开发人员在本地构建和运行应用时，可以使用开发签名配置，确保本地构建的一致性。
测试阶段
- Git 配置
- 当开发完成一个功能后，将开发分支合并到测试分支（如
test 分支）。例如：git checkout test && git merge feature - <feature_name>。
- 在测试分支上进行集成测试和系统测试。如果发现问题，在测试分支上创建
hotfix - <issue_number> 分支进行修复，修复完成后合并回测试分支和开发分支。
- 代码签名配置
- 使用与开发阶段类似的代码签名配置，但密钥库和密码等信息应与测试环境匹配。确保测试环境构建的应用与生产环境有相似的签名配置，以便发现潜在的签名相关问题。例如，在测试环境中可以复用开发签名配置，但如果测试环境更接近生产环境，可能需要使用生产签名密钥库的副本（在安全的前提下）。
发布阶段
- Git 配置
- 从测试分支合并到主分支（
master）和发布分支（如 release - <version_number>）。例如：git checkout master && git merge test && git checkout release - <version_number> && git merge test。
- 打版本标签，例如：
git tag -a v1.0 -m "Release version 1.0"。
- 代码签名配置
- 使用生产环境的正式代码签名密钥对发布版本进行签名。这需要严格保护密钥库文件和密码。在 Gradle 构建中，确保
build.gradle.kts 中的签名配置指向生产密钥库：
android {
signingConfigs {
create("release") {
storeFile = file("path/to/production_keystore.jks")
storePassword = "production_keystore_password"
keyAlias = "production_key_alias"
keyPassword = "production_key_password"
}
}
buildTypes {
getByName("release") {
signingConfig = signingConfigs.getByName("release")
}
}
}
处理代码签名导致的版本冲突问题
- 冲突检测
- 当合并分支时，如果代码签名相关配置文件（如
build.gradle.kts 中签名部分）发生冲突，Git 会提示冲突。例如：
Auto - merging build.gradle.kts
CONFLICT (content): Merge conflict in build.gradle.kts
- 解决冲突
- 打开发生冲突的文件（如
build.gradle.kts），手动解决冲突。一般来说，代码签名配置在不同分支应该是相对稳定的，所以冲突可能是由于意外修改导致。
- 如果是不同环境的签名配置冲突，需要根据当前分支的用途（开发、测试、发布）确定正确的签名配置。例如，在发布分支上应该保留生产环境的签名配置，删除开发或测试环境的错误配置。
- 解决冲突后，重新提交更改：
git add build.gradle.kts && git commit -m "Resolve signing configuration conflict"。
- 确保在后续的构建和发布过程中，签名配置正确无误，再次构建和测试应用以验证签名的有效性和一致性。
