如何组织CDK项目，避免多人协作时的Git冲突？

下面是几个实用的组织方案，能有效减少多人协作时栈文件的Git冲突：

1. 按模块拆分独立栈文件 #

把原来单一的栈类拆分成多个专注于特定资源/业务模块的栈文件，比如网络资源放NetworkStack.ts、数据库资源放DatabaseStack.ts、API服务放ApiStack.ts。每个开发者只负责修改自己模块对应的栈文件，从根源上减少冲突概率。

示例代码结构：

├── stacks/
│   ├── NetworkStack.ts
│   ├── DatabaseStack.ts
│   └── ApiStack.ts
└── main.ts

主文件中统一初始化各栈：

import { NetworkStack } from './stacks/NetworkStack';
import { DatabaseStack } from './stacks/DatabaseStack';

const app = new cdk.App();
const networkStack = new NetworkStack(app, 'NetworkStack');
// 依赖网络资源的数据库栈，通过参数传递依赖
new DatabaseStack(app, 'DatabaseStack', { vpc: networkStack.vpc });

2. 栈内拆分资源构造类 #

如果不想拆分成多个栈，可以把栈内的资源按功能拆成独立的Construct类，放在单独的constructs目录下。主栈文件只负责实例化这些构造类，开发者各自修改对应的构造文件即可。

示例：

// constructs/AppS3Buckets.ts
export class AppS3Buckets extends cdk.Construct {
  constructor(scope: cdk.Construct, id: string) {
    super(scope, id);
    new s3.Bucket(this, 'UserUploadBucket');
    new s3.Bucket(this, 'StaticAssetBucket');
  }
}

// 主栈文件 MainStack.ts
import { AppS3Buckets } from './constructs/AppS3Buckets';

export class MainStack extends cdk.Stack {
  constructor(scope: cdk.App, id: string, props?: cdk.StackProps) {
    super(scope, id, props);
    new AppS3Buckets(this, 'AppS3Buckets');
    // 其他构造类实例化
  }
}

3. 抽离环境配置与资源定义 #

把环境相关的配置（账号、区域、资源参数等）单独放到配置文件中，和资源定义代码解耦。开发者修改资源逻辑时不会触碰配置部分，减少冲突点。

示例：

├── config/
│   ├── dev.ts
│   └── prod.ts
└── stacks/MainStack.ts

配置文件dev.ts：

export const devConfig = {
  account: '123456789012',
  region: 'us-east-1',
  lambdaTimeout: 30
};

主栈文件中导入配置：

import { devConfig } from '../config/dev';

export class MainStack extends cdk.Stack {
  constructor(scope: cdk.App, id: string) {
    super(scope, id, {
      env: { account: devConfig.account, region: devConfig.region }
    });
    new lambda.Function(this, 'DevProcessingLambda', {
      runtime: lambda.Runtime.NODEJS_18_X,
      handler: 'index.handler',
      code: lambda.Code.fromAsset('lambda'),
      timeout: cdk.Duration.seconds(devConfig.lambdaTimeout)
    });
  }
}

4. 优化Git工作流 #

除了代码结构调整，配合Git工作流也能减少冲突：

• 要求开发者每次提交前先拉取最新主分支代码，本地合并后再推送；
• 采用feature分支开发，每个分支只负责一个小功能或资源修改，避免大分支长时间未合并；
• 提交PR后先做代码审查，合并前解决冲突（此时冲突范围小，更容易处理）。

内容的提问来源于stack exchange，提问作者Sourav Mondal