git使用总结(包含git commit message 和 changelog 工具的介绍)

【git的配置】

1.配置用户名和邮箱: 分为全局配置和局部配置 --system 系统配置  --global 全局配置    --local 局部配置

Git读取时:优先从local>global>system

git config --global user.name name

git config --global user.email email

2.别名的配置

使用git st 代替 git status

git config --global alias.st status

配置成功后全局的配置list中会添加 alias.st = status

3.默认选项的配置

pull.rebase

git config --global pull.rebase true

【git常用命令】

1.git clone [url]

在git clone操作中,git会默认拉去仓库master分支上的文件,

git clone -b 分支名   [url]    clone指定的分支

2.git tag 查看当前所有标签

通过-l选项进行过滤标签

git tag -l ‘v1.8.5*’   输出包含v1.8.5的小版本标签

创建标签: 通过-a选项创建一个标签,通过-m选项制定一条存储在标签中的信息,-m类似于git commit -m

git tag -a v1.4 -m ‘v1.4’

补充标签:加入在某次提交时,忘记打标签

首先通过 git log —pretty=oneline 命令查看所有提交历史

01eef37c165e08f60d1843511476ab9de62a418c (HEAD -> master, origin/master) no tag push

242921a006c7e00742d6d740dfcddd62e7407d10 (tag: v1.1) second push

2a292db3f0fd516cee21b423926600010746f49d (tag: v1.0) start study git (HEAD -> master, origin/master) no tag push

242921a006c7e00742d6d740dfcddd62e7407d10 (tag: v1.1) second push

2a292db3f0fd516cee21b423926600010746f49d (tag: v1.0) start study git

可以对最上面一条补充标签: git tag -a v1.2 01eef37c165e08f60d1843511476ab9de62a418c

推送标签: git push 操作默认时不会推送tag标签的,需要使用—tags选项专门推送tag标签

git push origin —tags     推送成功后可以在远端仓库看到刚才推送的标签

3.文件状态:

在一个本地仓库中,文件只有两种状态--已追踪和未追踪

已追踪文件:在仓库之前的版本快照中包含了文件的记录,在用户工作一段时间之后,这些文件要么事修改文件,要么事删除文件,要么事没有任何改动的文件

为追踪文件: 并不再上一次版本快照中,也不再本地暂存区,一般都是新增文件

注意: 刚clone完的项目,所有文件都是已之宗状态,并且都未修改

git status 命令事用来检索本地所有文件的更新,包括新增,修改和删除

在暂存区内,git只暂存了git add时的版本,如果此时进行commit提交,提交的也只是git add的版本,新的编辑并未添加至暂存区。因此我们在任何时候,如果对文件进行了修改,都需要通过git add命令添加至暂存区。

4.忽略文件

gitignore文件格式如下:

#表示注释会被忽略。

空行直接被忽略。

可以用正则匹配。

除去匹配的文件,在表达式前面加上取反符号(!)。

5.查看修改 git diff : 查看尚未暂存文件的修改

git diff                     查看修改后未暂存起来的文件内容。

git diff --staged      查看暂存区的修改

6.写一个完整规范的commit message

可以参照: http://www.ruanyifeng.com/blog/2016/01/commit_message_change_log.html

Type(scope): subject    (注意:冒号后面必须跟空格才能使用changelog工具)

type有下面几个类型:

Feat--新功能

Fix--修复bug

Style—代码格式

Refactor--代码重构

Chore--项目构建(修改版本号等)

scope:模块名称—代码的功能

subject: 描述信息

格式化commit message的工具:git cz(commitizen)

全局安装commitizen :  npm install -g commitizen

设置支持angular格式的commit message : commitizen init cz-conventional-changelog —save-exact

提交代码的时候使用: git cz

7.changelog: 项目迭代过程中一系列的变更记录

生成changelog

全局安装changelog: npm install -g conventional-chagelog-cli

生成所有的changelog: conventional-changelog -p angular -I CHANGELOG.md -s -r 0

在CHANGELOG.md的头部加上自从上次发布以来的变动: conventional-changelog -p angular -I CHANGELOG.md -w

为了方便使用,可以将其写入package.json的scripts字段

{

“script”: {

“Changlog”: "conventional-changelog -p angular -I CHANGELOG.md -w"

}

}

然后直接运行 npm run changelog 即可

默认情况只有feat和fix才有提交记录

8.主干和分支

git通过保存一系列不同时刻的文件快照来实现数据存储。每次在进行git提交时,都会生成一个提交对象,这个提交对象都会产生一个只想咱村去内容快照的指针,每个提交对象中都会包含一个指向上一次提交(父提交对象)的指针。

每个git仓库都有一个默认的master分支。

git branch 分支名              创建一个新的分支

git checkout 分支名           切换到指定分支

git  checkout -b 分支名     创建分支并切换到该分支

一个上线项目中,一般有多个用于运行的分支,生产环境一般是master分支,开发环境的dev分支,测试环境下的test分支,还有个人开发分支self[name]分支。

合并分支: 先切换分支再合并:

git checkout master

git merge hotfix

删除分支使用-d参数来完成,需要先checkout到别的分支,才能删除

git checkout master

git branch -d hotfix

原文地址:https://www.cnblogs.com/jasonwang2y60/p/8723425.html

时间: 2024-11-05 20:26:44

git使用总结(包含git commit message 和 changelog 工具的介绍)的相关文章

git中Please enter a commit message to explain why this merge is necessary

今天在使用git时,git pull和git merge时,经常出现如下错误信息: Please enter a commit message to explain why this merge is necessary.(请输入提交消息来解释为什么这种合并是必要的) 解决方法: 1.按“Esc”退出键 2.输入“:wq”,然后按下“Enter”键(说明:要输入英文状态下的冒号) 参考文档 :http://blog.csdn.net/ailo555/article/details/5220227

git提示Please enter a commit message to explain why this merge is necessary

Please enter a commit message to explain why this merge is necessary. 请输入提交消息来解释为什么这种合并是必要的(提交信息) git 在pull或者合并分支的时候有时会遇到这个界面.可以不管(直接下面3,4步),如果要输入解释的话就需要: 1.按键盘字母 i 进入insert模式 2.修改最上面那行黄色合并信息,可以不修改 3.按键盘左上角"Esc" 4.输入":wq",注意是冒号+wq,按回车键

Git工程实践(一)巧用commit message

摘要: 大家都知道所有的版本控制系统比如svn,git等设计的核心价值之一就是为了让代码变更有迹可循,而commit mesage的价值在于让有迹可循的代码对人类更加友好,通常一个恰如其分的commit message表达的信息往往先于代码. 背景 大家都知道所有的版本控制系统比如svn,git等设计的核心价值之一就是为了让代码变更有迹可循,而commit mesage的价值在于让有迹可循的代码对人类更加友好,通常一个恰如其分的commit message表达的信息往往先于代码. 而现实的工程实

git第四节----git commit message

@git  commit message 什么是git commit message :git commit -m '每次提交时编辑的内容' git commit message的好处:      1.提供更多可查询的信息,用于排查问题      2.过滤重要的内容      3.生成changelog     commit message组成包括header,body,footer三个部分,一般只使用header    header 包含三个部分:type,scope,subject     

git commit 时出现:please enter the commit message for your changes

每次准备提交前,先用 git status 看下,是不是都已暂存起来了,然后再运行提交命令 git commit: $ git commit 这种方式会启动文本编辑器以便输入本次提交的说明.(默认会启用 shell 的环境变量 $EDITOR 所指定的软件,一般都是 vim 或 emacs.当然也可以按照第一章介绍的方式,使用 git config --global core.editor 命令设定你喜欢的编辑软件.) 编辑器会显示类似下面的文本信息(本例选用 Vim 的屏显方式展示): # P

通过git rebase修改commit message

今天发现一个项目的git commit message中的单词拼错了,需要修改一下.但这样简单的修改,需要通过git rebase才能完成. 首先要git rebase到需要修改message的那个commit的前1个commit.假设commit id是32e0a87f,运行下面的git rebase命令: git rebase -i 32e0a87f 在git bash中运行上面的命令后,会弹出编辑框,在编辑框中会分行依次显示以pick开头的这个commit之后的所有commit messa

commitizen和cz-customizable配置git commit message

起因 团队对提交的commit message格式有约定俗称的要求,但是没有一个统一的规范,导致大家提交的commit message或多或少不太一样.因此,需要一个工具来帮助大家统一commit message的格式,也方便后续的分析和拓展. commitizen commitizen 是一个帮助规范commit message的工具.安装后的效果如下图: 安装commitizen npm install -g commitizen 安装adapter commitizen根据不同的adapt

git push 时:报missing Change-Id in commit message footer的错误

1. 一般而言,按照提示执行以下两个命令即可生成新的Change-id - gitdir=$(git rev-parse --git-dir); scp -p -P 29418 guan@192.168.84.22:hooks/commit-msg ${gitdir}/hooks/ - git commit --amend 2. 当执行完后,提交还是报missing Change-Id in commit message footer ,但是git log发现这次提交已经有了change-id

如何写好Git Commit Message

https://chris.beams.io/posts/git-commit/ The seven rules of a great Git commit message Keep in mind: This has all been said before. Separate subject from body with a blank line Limit the subject line to 50 characters Capitalize the subject line Do no