终端命令 command

# 当前列表
ls

# 显示列表,包括隐藏
ls -a 

# 创建文件夹
mkdir

# 创建文件
touch

# 输出文件数据
cat `file`

# 当前所在位置,路径
pwd

# 移动文件,可用来改名
mv 

# 删除
rm -r 文件夹
rm -rf 文件夹+文件
rmdir

# 跳转目录
cd 

# 打开
open

# windows 打开
explorer 

# 清屏 or ctrl + l
clear

# vscode 打开指定文件,如果没有请在vscode使用快捷键 command+shift+p 搜索 code
code `path or file`

# 或者配置 .bash_profile
alias code="/Applications/Visual\ Studio\ Code.app/Contents/Resources/app/bin/code"

配置 config

# 全局配置
git config --global user.email 'xxx@qq.com'
git config --global user.name 'xxx'

# 局部配置
git config user.email 'xx@qq.com'
git config user.name 'xxx'

忽略文件 .gitignore

匹配成功,则忽略

  • 所有空行或注释符号 # 都被 GIt 忽略
  • 匹配模式跟反斜杠 / 说明忽略目录
  • 可使用标准 glob 模式匹配
*.txt   匹配txt结尾
!a.txt  匹配不是a.txt
/vendor 匹配vendor文件夹
/vendor/*.php 匹配vendor文件夹php结尾
/vendor/**/*.php 匹配vendor文件夹中,所有文件夹中的php结尾

日志查看 Log

# 显示所有
git log

# 最近2次提交,显示文件差异
git log -p 2 

# 显示已修改文件清单
git log --name-only 

# 显示新增、修改、删除文件清单
git log --name-status 

# 显示HASH-文件名
git log --online 

基础流程

git工作流.png

# 克隆
git clone 地址

# 初始化
git init

# 状态
git status

# 移动 or 改名
git mv old new

# 删除
git rm 删除本地
git rm --cached 删除暂存

# 不小心将工作区 hd.js 删除,可通过暂存区 hd.js 恢复
git checkout hd.js

# 暂存
git add 文件/.

# 仓库
git commit -m '描述'

# 修改最后一次提交
git commit --amend

# 提交远程仓库
git push

# 查看与那个仓库关联的 
git remote -v

分支流程 Branch

大部分不会直接在 master 分支工作,要保护这个分支是最终开发完成的健康代码。

所有功能和缺陷(bug)修复都会新建分支完成,除了这个和基本流程的使用是一样的。

# 1. 新建支付功能分支
git branch pay

# 1.1切换新分支开发
git checkout pay

# 2. 创建分支并切换到新分支
git checkout -b pay

# 添加暂存
git add .

# 开发完成执行提交
git commit -m 'h5 支付功能'

# 合并分支到master
  # 切换到 master 分支
    git checkout master    

    # 切换到最新的 master
    git rebase master

  # 合并 pay 分支代码
    git merge pay

# 提交代码到 master 远程分支
git push

# 删除分支
git branch -d ask

# 删除没有合并的分支
git branch -D ask

# 删除远程分支
git push origin --delete ask
or
git push origin :ask

# 查看未合并的分支(master)
git branch --no-merged

# 查看已合并的分支(master)
git branch --merged

# 查看所有分支
git branch -a

关于分支文件冲突,需要自行打开冲突文件进行修复,再提交!

拉取分支 Pull

# 拉取 origin 主机的 ask 分支与本地的 master 分支合并
git pull origin ask:ask

# 拉取 origin 主机的 ask 分支与当前分支合并
git pull origin ask

# 如果远程分支与当前本地分支同名直接执行
git pull

版本库管理 Rest

使用 reset 恢复历史记录提交点,重置缓存区与工作目录内容

# 清空工作区和暂存区的改动
git reset --hard

# 恢复前三个版本
git reset --hard HEAD^^^

# 保留工作区的内容,把文件差异放进缓存区
git reset --soft

# 恢复指定提交版本(先通过 git log 查看版本号)
git reset --hard bsda8a8978129382231

临时暂存 Stash

当正在进行项目某个工作,里面东西比较乱,而想在其他分支进行工作,又不想提交进行了一半的工作,否则无法无法回到当前工作点。

“暂存”可获取工作目录的中间状态--也就是修改过的被追踪文件和暂存的变更--并将它保存未完结变更的堆栈中,随时可重新应用。

# 暂存
git stash

# 查看列表
git stash list

# 恢复最近的暂存
git stash apply

# 恢复指定的暂存
git stash apply stash@{2}

# 删除暂存
git stash drop stash${0}

# 恢复并删除暂存
git stash pop

标签 Tag

Git 可对某一时间点的版本打上标签,用于发布软件版本 v1.0

# 添加标签
git tag v1.0

# 列出标签
git tag

# 推送标签
git push --tags

# 删除标签
git tag -d v1.0.1

# 删除远程标签
git push origin :v1.0.1

打包发布

对 master 分支代码生成压缩包提供使用者下载使用, --prefix 指定压缩后的目录名

git archive master --prefix="dirName/" --format=zip > fileName.zip

SSH

使用 ssh 连接 github 发送指令更加安全可靠,也可避免每次输入密码的困扰。

# 生成秘钥,一直回车到结束。
ssh-keygen -t rsa

# 秘钥生成后的目录,有秘钥 id_rsa 和公钥 id_rsa.pub
cd ~/.ssh

# 向 github 添加秘钥
# 1. 在 github 的 settings 点击 SSH and GPG keys
# 2. 右上 new ssh key 按钮,添加 id_rsa.pub 公钥内容

提交规范 Commit

feat:新功能(feature)

fix:修补bug

docs:文档(documentation)

style: 格式(不影响代码运行的变动)

refactor:重构(即不是新增功能,也不是修改bug的代码变动)

test:增加测试

chore:构建过程或辅助工具的变动

工作流 Workflow

参考【阮一峰】所介绍的三种 git 工作流:

http://www.ruanyifeng.com/blog/2015/12/git-workflow.html

三种工作流程都是采用“功能驱动式开发”简称FDD,需求时开发的起点。先有需求再有 功能分支(feature branch)、补丁分支(hotfix branch)。

完成开发后,该分支合并到主分支,然后被删除。 depops.png

1. Git Flow(诞生最早)

简述:诞生最早、广泛采用的一种工作流程。

特点:项目中有两个长期分支

  1. 主分支( master)

    对外发布版本,存的都是稳定版

  2. 开发分支( develop)

    日常开发,存放最新开发板

  3. 短期分支

    功能分支(feature branch)

    补丁分支(hotfix branch)

    预发分支(release branch)

一旦开发完,就合并到 develop 或 master ,然后被删除。

网站类项目不推荐,很多网站类项目是“持续发布”,代码有变动就部署一次。这时 master 和 develop 分支差别不大,没必要维护两个长期分支。

2. Github Flow(git flow简化版)

简述:git flow 简化版,专门配合“持续发布”,相对简单,默认是当前线上的版本。也是 GIthub 使用的工作流。

只有一个长期分支(主分支 master)

  1. 根据需求,从 master 创建新的分支,不区分功能分支或补丁分支。

  2. 开发完,master 发起 Pull Request (通知请求合并,大家可评审代码,还可不断提交)

  3. Pull Request 被接受,合并 master,重新部署,原来的那个新分支被删除。

3. Gitlab flow(前两种结合体)

简述:只有一个长期分支(主分支 master),所有分支的老大,也是开发环境分支。

  1. 持续发布的项目,建议在 master 分支外,建立不同环境分支。

    1. 开发环境分支 master
    2. 预法环境分支 pre-production
    3. 生产环境分支 production
  2. 开发 > 预发 > 生产,必须是 从大到小发展。

    比如:生产环境出了 bug,这时需要新建分支,先合并到 master 确定没问题,再 cherry-pick 到 pre-production 这一步没问题,才进入 production

  3. 紧急情况才允许跳过上游,直接合并到下游分支。

  4. 版本发布

    每一个稳定版本,从 master 分支拉出一个分支,比如 2-3-stable、2-4-stable,之后只有修 bug ,才允许将代码合并到这些分支,并且此时要更新小版本号。

4. 小技巧

  1. Pull Request

    功能分支合并进 master 分支,必须通过 Pull Request(gitlab 叫 Merge Request)

    @人员/团队,引起他们注意。

  2. Protected branch

    master 分支该受到保护,不是每个人都可修改该分支,以及拥有审批 Pull Request 的权利。github/gitlab 都提供保护分支这个功能。

  3. Issue

    用于追踪 Bug 和需求管理。建议先建 Issue 在新建对应的功能分支。功能分支总是解决一个或多个 Issue。

    功能分支名称,可以与 issue 的名字保持一致,并且以 issue 的变化起首,

  4. Merge

    1. 直进式合并(fast forward),不生成单独合并节点
    2. 非直进式合并(none fast forward),会生成单独节点

    前者不利于保持 commit 信息的清晰,也不利于以后的回滚,建议采用后者(即使用 --no-ff 参数)。

    只要发生合并,就要有单独的合并节点。

  5. Squash 多个 commit

    为了便于他人阅读,也便于 cherry-pick 或撤销代码变化,在发起 Pull Request 之前,应该把多个 commit 合并成一个。(前提,该分支只有你一个人开发,且没有跟 master 合并过)

    这可采用 rebase 命令附带的 squash 操作。

软件版本命名规范

参考 【顺其自然~】 https://blog.csdn.net/fuhanghang/article/details/83504157

1. 版本阶段

  1. Base版,基础框架
  2. Alpha版,功能为主,Bug多,内部交流
  3. Beta版,消除严重 Bug,主要修改软件的UI
  4. RC版,已相当成熟,基本不存在错误 Bug,距离发行的正式版相差不多
  5. Release版,最终版本,是最终交付使用的一个版本,也叫标准版。通常取名(R)

2. 版本规范

  1. 主版本号:功能模块有较大改变,比如增加多个模块或整体架构发生变化。

    项目决定者修改

  2. 子版本号:功能有一定的增加或变化,比如增加了权限控制、自定义视图等功能。

    项目决定者修改

  3. 阶段版本号:Bug 修复或是一些小的变动,需要经常发布修订版,事件间隔不限,修复一个严重的 bug 即可发布一个修订版。

    项目经理决定是否修改。

  4. 日期版本号:用于记录修改项目的当前日期,每天对项目的修改都需要更改日记版本号。

    开发人员决定是否修改。

  5. 希腊字母版本号(beta):表名当前的软件处于哪个开发阶段,当进入另一个阶段修改此版本号。

    由项目决定是否修改。

留言

暂无评论

我要发表看法