“git使用最佳实践”

git常规操作

1、克隆
git clone http://192.168.2.174/front-end/erp.git
2、拉取远程仓库其他分支
git checkout -b [本地分支名称] origin/[远程分支名称]
3、本地新建分支并切换到该分支
git checkout -b [分支名称]
4、关联到远程仓库
git remote add origin [仓库地址]
5、本地分支推送到远程仓库
git push --set-upstream origin [远程分支名称]
git push
6、合并代码
git merge [其他分支名称]
7、取消合并（代码有冲突且不容易解决时可使用）
git merge --abort
8、拉取
git pull
9、推送
git push
10、删除本地分支
git branch -D [分支名称]
11、删除远程分支（慎用）
git push origin --delete [分支名称]
12、查看本地和远程分支
git branch -a
13、放弃本地某个文件修改（未使用 git add 缓存代码）
git checkout -- abc.vue
14、放弃本地所有文件修改（未使用 git add 缓存代码）
git checkout .
15、放弃本地某个文件修改（已使用 git add 缓存代码）
git reset HEAD abc.vue
16、放弃本地所有文件修改（已使用 git add 缓存代码）
git reset HEAD .
17、放弃本地所有文件修改（已使用 git commit（git cz））
git reset HEAD^
18、回退版本
git reset --hard HEAD^
git reset --hard commitid
19、查看当前仓库地址
git remote -v
20、修改远程分支名称（3步）
git branch -m [原分支名] [新分支名]  //修改本地分支
git push origin [远程分支名]  //删除远程分支
git push --set-upstream origin [新分支名]  //新增远程分支

git分支管理规范

git版本开发流程

代码提交规范

在没有规范的情况下，开发人员的 commit 信息是常常是随意的，这就导致 commit 信息显的很无用。可是当你在做git log、code review、编写changelog等情况时，良好的 commit 规范就显的尤为重要。

后端：
feat：    新增/修改一个页面/功能，接口联调
fix：     修复Bug，后面最好把bug的编号填到上
docs：    修改了文档 README CHANGELOG
style：   修改了页面的css样式（不改变代码逻辑）
refactor：代码重构（ 即不是新增功能，也不是修改 bug 的代码变动）
perf:     改善性能
test：    测试用例，单元测试，集成测试。
build:    变更项目构建或外部依赖（例如scopes: webpack、gulp、npm等）
ci:       更改持续集成软件的配置文件和package中的scripts命令，例如scopes: Travis, Circle等
chore：   改变构建流程，或者增加依赖库，工具(辅助工具)等变
revert：  回滚到上一个版本(代码回退)

加简要描述本次改动，请遵循下面格式: 改动的哪个方法，新增/修改/删除什么功能，

前端：
因为不同的项目本身的构建方式的不同，commitizen 支持不同适配器的扩展，从而去满足不同的构建需求的。我们选择使用cz-conventional-changelog的构建标准

安装 （全局安装）
在全局添加commitizen 的依赖 
npm install commitizen -g  // npm全局安装
npm install cz-conventional-changelog -g  // commitizen的构建标准


// 可以运行 npm ls -g -depth=0 查看是否成功安装

生成changelog.md 
npm install conventional-changelog-cli -g // 生成CHANGELOG.md 的辅助工具，只做提交不需要安装，如果需要生成变更日志则需要安装，
快捷指令 可以在package.json scripts中添加快捷指令 
"genlog": "conventional-changelog -p eslint -i CHANGELOG.md -s -r 0"  

package.json中添加配置相应的配置 commitizen才能生效 
"config": {
    "commitizen": {
      "path": "cz-conventional-changelog"
    }
  }

使用
安装并添加完后，我们便可以使用 git cz 命令替换 git commit 来使用了。我们修改一个文件并 git add 后，通过 git cz 提交message信息 
git add .
git cz

git cz进行commit操作 
Select the type of change that you're committing: (Use arrow keys)
❯ feat:     A new feature 
  fix:      A bug fix 
  docs:     Documentation only changes 
  style:    Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc) 
  refactor: A code change that neither fixes a bug nor adds a feature 
  perf:     A code change that improves performance 

( Type ) ( 必填 ) 用于说明 commit 的类别，只允许使用下面 7 个标识。 
feat：    新增/修改一个页面/功能，接口联调
fix：     修复Bug，后面最好把bug的编号填到上
docs：    修改了文档 README CHANGELOG
style：   修改了页面的css样式（不改变代码逻辑）
refactor：代码重构（ 即不是新增功能，也不是修改 bug 的代码变动）
perf:     改善性能
test：    测试用例，单元测试，集成测试。
build:    变更项目构建或外部依赖（例如scopes: webpack、gulp、npm等）
ci:       更改持续集成软件的配置文件和package中的scripts命令，例如scopes: Travis, Circle等
chore：   改变构建流程，或者增加依赖库，工具(辅助工具)等变
revert：  回滚到上一个版本(代码回退)

( Scope ) ( 选填 ) 用来说明本次Commit影响的范围，scope 用于说明 commit 影响的范围，比如页面绘制（html），接口联调（api），UI样式以及还原（css），等等，视项目不同而不同。 
? What is the scope of this change (e.g. component or file name)

( Subject ) ( 必填 ) 用来简要描述本次改动，如果规则很长，详细信息在后面的Body里给出。请遵循下面格式: 改动的哪个页面，新增/修改/删除什么功能， 
? Write a short, imperative tense description of the change (max 94 chars):
 (17) 客户维护页面，新增客户导出功能，根据搜索条件导出数据，不支持勾选导出。

( Body ) ( 选填 ) 在此做更加详尽的描述，内容里应该包含修改动机和修改前后的对比。 
? Provide a longer description of the change: (press enter to skip)

( Footer ）( 选填 ) 里的主要放置不兼容变更和Issue关闭的信息，我们项目里面如果type为fix时可以填jira上的bug编号 
? Does this change affect any open issues?

gitHooks 会执行  vue-cli-service lint 检查代码规范 在检查无误之后可以进行 pull 和 push 操作

× 观测猿

真诚赞赏，感谢认可

0.9元 1.9元 2.9元 3.9元 9.9元 任意金额

2元

使用微信扫描二维码完成支付

• ← Previous Post
• Next Post →