小编mep*_*sto的帖子

Git合并-压扁还是不压扁?

我目前正在努力在相当复杂的开发环境中实施git使用的准则,虽然我认为我的基础设置很好,但是特别有一个问题,我想请教一下是否有可能。这并不是一个纯粹的技术问题,而是更多关于哪个可用选项最合适。

基本上,我倾向于一个与通用的“ git flow”结构(http://nvie.com/posts/a-successful-git-branching-model/)紧密镜像的系统,但有一些例外使其能够适应我们的需求开发环境。简而言之:

  • 一个项目将至少有一个“开发”和“主”分支
  • “主”将包含最新的生产就绪代码
  • “开发”将包含最新的合并代码
  • 其他任何功能都将位于“功能/票证{number}”或“修补程序/票证{number}”分支中
  • 功能分支将由'develop'组成,修补程序分支将由'master'组成
  • 分支机构名称中的号码将始终与我们自己的更改/错误系统中的票证号码相对应
  • 通过构建适当的分支或将其合并为“开发”功能,可以单独测试功能,也可以组合测试功能

到目前为止,它确实帮助我们简化了开发流程并防止了项目之间的冲突。引发争议的一个细节是:我们是否应该使用'--squash'选项将要素/机票分支合并回各自的原点?我有点喜欢它,我喜欢它:

  • 用于开发的git日志保持整洁且可读,所有提交将仅声明原始分支名称(它告诉我们它是修补程序还是功能,以及票证编号)
  • 即使清除了原始功能或修补程序分支,合并之后也不会引起混淆

也许这些原因还不够好,也许有充分的理由在这种情况下不使用'--squash'。有什么想法吗?

git version-control merge

4
推荐指数
2
解决办法
1380
查看次数

标签 统计

git ×1

merge ×1

version-control ×1