Git分支的最佳实践

原文:http://nvie.com/posts/a-successful-git-branching-model/
译文:http://www.tuicool.com/articles/NNzUby
精华:

Paste_Image.png

主分支:

  • master
  • 上线到生产环境的重大发布;
  • 生命周期最长,从项目开始到废弃为止;
  • 功能开发,永远不应该直接牵扯到master
  • develop:可交付代码;用于集成分支、每日构建;
  • 当develop的代码足够稳定/接近发布日期,创建release分支,并tag
    辅助分支:
  • feature-*
  • 只存在于开发者仓库中
  • 可能从develop中产生,但最终必须合并回develop
  • 开发完成后合并;或者放弃;
  • 创建:git checkout -b feature-x develop
  • 合并:git checkout develop  git merge --no-ff feature-x
  • 删除:git branch -d feature-x
  • release-*
  • 发布分支可能从 develop 分出,最终 必须*合并回 develop
    和 master
  • hotfix-*,紧急修复
  • 可能从 master 分出, 必须 合并回 develop 和 master;
  • 生产环境的bug,从master中;
  • 如果存在release,合并到release中,不进入develop;

Public vs Private

  • public
  • commit 应该简洁、原子、完善的文档描述;
  • 尽可能线性
  • 包括 Master、Release
  • private,你自己的
  • 保持在本地,避免push;
  • 向public进行合并,首先clean up分支,使用reset, rebase, squash merges, and commit amending

--no-ff

$ git merge --no-ff myfeature
确保总是新生成一个提交,避免丢失曾经存在一个特性分支的历史信息,也能够方便地看出哪些提交属于同一个特性。

Paste_Image.png

参考文章:

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
【社区内容提示】社区部分内容疑似由AI辅助生成,浏览时请结合常识与多方信息审慎甄别。
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。

推荐阅读更多精彩内容

友情链接更多精彩内容