♬ Phantom Blog

梦幻空花 ~ 何劳把捉

0%

发表于 分类于 ， 阅读次数：
本文字数： 4.9k 阅读时长 ≈ 4 分钟

前要

以下包含一些平时经常会用到但容易忘记的操作，或一些有记录价值的操作，但不包含那些更基本的命令或操作，一些较新版本的命令也不记录。部分存在比较官方的文档进行讲解的操作或命令，为了保持文章简短，会给出文档的链接，这里不会再展开。

正式文档

配置全局用户名和邮箱

git的当前用户的主配置文件在（在用户目录的.gitconfig文件）

1
2
git config --global user.name "username"
git config --global user.email "[email protected]"

配置默认编辑器

1
git config --global core.editor vim
阅读全文 »

发表于 分类于 ， ， 阅读次数：
本文字数： 608 阅读时长 ≈ 1 分钟

使用二分法(bisect)定位引入的bug

情景模拟准备

仓库中有一个record.txt文本文件,如果有一行的文本为"有bug"表示存在bug。已知其中一个正常提交的commit id是902c829f42b14d547330519993674e7f909a73a4，引入bug提交的commit id是98068739138d5785f2186d37efdfadfe9b5ebf1d。

名词定义

bad：存在bug的提交

good：无bug的提交

做法1

  1. 开始进入二分法定位bug时需要指定一个已知存在bug(bad)与无bug(good)的提交
  2. 初始化并进入二分操作
    1
    2
    # start后参数为空表示已知的bad和good提交在后续标记
    git bisect start
  3. 标记一个good的提交
    1
    git bisect good 902c829f42b14d547330519993674e7f909a73a4
  4. 标记当前commit存在bug,这时会采用二分法跳到good与bad中间的commit
    1
    git bisect bad
  5. 经过上面标记完成后,二分法定位bug正式开始.到了下一个commit,需要检查该提交是否存在bug,然后完成标记或者跳过该提交
    1
    2
    3
    4
    5
    6
    7
    8
    # 如果当前commit存在bug则标记为bad
    git bisect bad

    # 如果当前commit无bug则标记为good
    git bisect good

    # 跳过该提交则执行skip
    git bisect skip
  6. 执行上面操作之后都会定位到下一个commit,重复操作直到定位到bug,git会给出首次引入bug的commit的提示的
  7. bug定位完成后退出二分查找
    1
    git bisect reset
    #### 做法2
  8. 在初始化时标记一个bad提交和一个good提交
    1
    2
    # git bisect start <bad> <good>
    git bisect start head 902c829f42b14d547330519993674e7f909a73a4
  9. 剩下的做法与做法1相同

做法3(使用图形化)

  1. 初始化
    1
    git bisect start head 902c829f42b14d547330519993674e7f909a73a4
  2. 进入图形化操作
    1
    git bisect visualize
阅读全文 »

发表于 分类于 ， ， 阅读次数：
本文字数： 1.8k 阅读时长 ≈ 2 分钟

分支类型

git flow规范有这些类型的分支：master、develop、feature branches、release branches、hotfixes、bugfixes和support。其中保持稳定存在并且唯一的是master和develop。

从时间线上看可以参考下面这个图（来自 - A successful Git branching model）： git flow model

master

master分支也称production（产品）分支，主分支上的每个commit都要打上tag。不能直接在这个分支上修改，只能从别的分支上合入。在这个项目里我们基本只从release和hotfix分支上合入，即一个可发布版本或修改完bug之后可以合入master。 ### develop 主开发分支，git flow初始化之后默认的分支就是这个。所有长期稳定的开发啊都在这条分支上。

当需要开发新功能时可以基于它创建feature，开发完成之后合并会develop。

当发行版本存在需要紧急修复的bug，基于master创建hotfix分支并且修复完成之后需要合并到develop和master分支，并且打出新的tag。

当认为版本稳定之后可以基于develop创建release分支，在release测试完成之后，release分支上的修改会合入到develop和master上，并且需要基于master分支打出一个新的tag。 ### feature 最容易理解的一种分支，当需要开发一个新功能时基于develop创建出来，开发完成之后需要合入到develop分支，然后可以删掉了。 ### release release分支基于develop创建出来，可在上面进行测试、修改bug等操作。release创建出来后不影响develop和feature分支的继续开发，比如可以继续创建feature分支开发新功能。但是一旦打了release分支之后不要从develop分支上合并新的改动到release分支。release分支完成之后需要合并到develop和master上，并且master需要打一个新的tag。完成之后这个release可以删除了。 ### hotfix 当在master上发行的一个tag上发现bug需要紧急热修复后，可基于master创建hotfix分支，在这个分支上修改bug。如果这个需要热修复多个bug，可以基于这个hotfix创建多个bugfix。hotfix修改完之后需要合并到develop和master上，并且master需要打一个新的tag。由于合并入了develop上，所以bug的修复也会进入到下一个release。 ### bugfix 任何时候发现存在bug需要修复都可以基于特定的分支(除了master外)创建bugfix分支，这一般是在平常开发使用，如果是那些发行后版本需要进行紧急修复的应该使用hotfix。比如在feature分支内碰到bug，可以基于这个feature创建bugfix分支。注意：bugfix跟hotfix不一样，完成之后合入的只是base分支。 ### support 用于保持一份平行独立的版本。比如说需要一个需要长期维护的独立版本，那么可以使用support分支。 ## git flow相关命令 关于这些命令具体对应的git基本命令可以到网上找找。 - 初始化git flow

1
git flow init
### feature相关 - 创建一个feature
1
git flow feature start <name>
阅读全文 »

发表于 分类于 ， ， 阅读次数：
本文字数： 410 阅读时长 ≈ 1 分钟

commit message规范

参考angular的commit格式 ### 格式

1
2
3
4
5
6
7
8
9
10
11
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

<类型>(<可选作用域>): <标题描述>
<空一行>
<正文>
<空一行>
<脚注>
### type 描述提交的类型
1
2
3
4
5
6
7
8
9
10
11
12
13
feat:     增加新功能(feature)
fix:      修复bug

docs:     只改动了文档相关的内容
style:    不影响代码含义的改动，例如去掉空格、改变缩进、增删分号
build:    构造工具的或者外部依赖的改动，例如webpack，npm
refactor: 代码重构时使用
revert:   执行git revert打印的message

test:     添加测试或者修改现有测试
perf:     提高性能的改动
ci:       与CI（持续集成服务）有关的改动
chore:    不修改src或者test的其余修改，例如构建过程或辅助工具的变动
### scope 描述提交影响的作用域，可使用项目名或者模块名等 ### subject 提交消息的标题 ### body 正文体 ### footer 脚注，包含Breaking Changes和Affect issues。 #### Breaking Changes breaking change即可能会产生破坏性的重要改变，比如接口改变、与上个版本不兼容等，需要在Footer以BREAKING CHANGE:开头，后面加上对变动的描述、以及变动理由和迁移方法等信息。 例子：
1
BREAKING CHANGE: refactor to use JavaScript features not available in Node 6.
#### Affect issues 针对某些issue进行描述，这里的使用与托管的平台有关。比如：github关于issue的规范。 模式：
1
KEYWORD #ISSUE-NUMBER
例子：
1
2
3
4
5
6
7
8
9
修复issue
Fix #200

关闭issue
Close #300

解决issue
resolve #400
re #500
### 关于撤销操作(revert) 描述撤销操作提交时使用以下格式(其中的hash是被撤销的commit的hash)：
1
2
revert: <subject>
This reverts commit <hash>
### 完整例子
1
2
3
4
5
6
7
8
fet(ui): 创建一个窗口

创建hello world窗口,并修改一个bug

BREAKING CHANGE: 把subsystem从console改为了window，程序入口改变了

resolve #760

阅读全文 »