版本管理

时间 2020-03-29

标签版本管理繁體版

原文原文链接

git-book: https://git-scm.com/book/zh/v2git

项目分支流程管理规范: https://www.jianshu.com/p/217d2b3bc96d <- I should click it!测试

我关注的点:指针

分支：一条时间线，一条执行线，每次修改都会在分支上留下一个“疙瘩”，就像毛线同样。blog

分支命名：主要是一个团队商量，你们达成约定，规范，方便理解其用途。
好比feature-xxx, develop, release, master, fixbug-xxx
团队在使用时，严格按照分支用途规范本身的行为，每一个分支应该如何用，具备什么操做限制。生命周期

分支生命周期：分支分为本地分支与仓库分支，前者的生命周期视其建立目的决定，后者是与项目”同生共死“的。
举个例子：
master: 生产环境的稳定版本分支，用于线上发布，仅能从release分支/fixbug-xxx分支合并,不容许在该分支提交修改。
release: 测试分支，测试过程当中发现bug，能够直接在该分支上修改，
测试经过后，方可将其合并到master分支，同时须要合并到develop分支。
develop: 开发环境的稳定分支，是公共开发环境的rootNode。
feature-xxx: 功能分支，基于develop分支建立而来，开发人员自测功能完毕后，可将其合并回develop。
fixbug-xxx: 紧急修复分支，基于master分支建立而来，测试经过后方可合并回master，
也须要将其合并到develop分支。开发

合并: 如何规范的合并分支?
1.产生有效的合并结果；
2.合并记录具有可读性；
3.合并过程出现冲突，留下解决记录；get

变基: https://git-scm.com/book/zh/v2/Git-%E5%88%86%E6%94%AF-%E5%8F%98%E5%9F%BAit

描述: 变基是将from分支上的一系列操做“剪切”到to分支，就好像操做一开始就是基于to分支进行的。
做用: 使得提交记录变得整洁，是一条直线，没有分叉ast

遴选: 将某个分支上的commit提交到另外一个分支上。class

回滚: 将HEAD头指针指向以前的某个commit，若是须要保存，还要再次提交(push)一次。

标签: 分为简单标签和详细标签，后者包含的信息会比前者更多，按需选择，我选择详细标签。
做用: 给某个commit打上标记，方便往后追溯、查找————一般拿来做为版本标示。
对标签常见的操做: 建立
普通查看，统配模式查看
删除
推送至远程仓库
检出某个标签，查看相关内容

紧急修复: 基于稳定版本分支新建一个分支，而后进行bug修复，待测试经过，即可以将其合并回稳定版本分支。
属于临时举措，在其职责结束以后，其分支的生命周期也同时结束。

commit规范: 要求能清晰的描述本次commit的类型为什么(好比提交功能/修复bugX)，及其内容。

------------------------------------------------------------------------------------------------

git经常使用命令速查表：

------------------------------------------------------------------------------------------------

git版本回退：

------------------------------------------------------------------------------------------------

建立远程分支：

------------------------------------------------------------------------------------------------

git_reset_hard推送后找回文件方法

------------------------------------------------------------------------------------------------

git_cherry-pick