常见Git操作
查看所有配置:
git config -l
查看系统配置:
git config --system --list
查看用户(全局)配置:
git config --global --list
查看HEAD的移动记录:
git reflog
查看提交历史:
git log
恢复到某个特定的提交节点:
git reset --hard 提交的哈希值
添加到暂存区:
git add .
取消暂存文件:
git restore --staged <文件名> // 取消单个文件
git restore --staged <文件1> <文件2> … // 取消暂存多个文件
git restore --staged . // 取消所有暂存文件
提交到本地仓库:
git commit –m “提交日志”
推送 master 分支:
git push origin/master
从 master 分支上创建并切换到 dev 分支:
git checkout –b dev master
推送到远程(git push origin 本地仓库:远程仓库):
git push origin dev:dev
切换到 dev 分支:
git checkout dev
删除本地名为“dev”的分支:
git branch -d dev
将名为“dev”的分支重命名为“develop”:
git branch -m dev develop
删除远程 dev 分支:
git push origin -d dev
从 dev 分支上创建 feature 分支:
git checkout –b feature/0.1.0-pages dev
合并 feature 分支到 release 分支:
git checkout release/0.1.0
git merge --no-ff feature
删除本地 feature 分支:
git branch –d feature/0.1.0-pages
删除远程 feature 分支:
git push origin/feature/0.1.0-pages
从 dev 分支上创建 release 分支:
git checkout –b release/0.1.0 dev
切换到 release 分支:
git checkout release/0.1.0
提交本地修改:
git add .
git commit –m “提交日志”
修改最近的提交信息:
git commit --amend -m “修改了提交信息”
推送 release 分支:
git push origin/release/0.1.0
在 master 分支上创建标签:
git tag v0.1.0
查看分支是基于哪个分支创建的
git reflog show 分支名
将dev分支rebase到master:
git checkout master // 切换到master
git pull // 更新
git checkout dev // 切换到dev
git rebase master // 变基
如遇冲突,手动解决,之后
git add 文件名
git rebase --continue
git push -f // 最后推送远程
假设有两个分支f1、f2,将f1分支的提交a,拷贝一份到分支f2:
git checkout f2
git cherry-pick a
重置本地分支为远程分支:
git reset --hard origin/分支名
Git提交规范
每次提交,Commit message 都包括三个部分:Header,Body 和 Footer。
<type>(<scope>): <subject>
// 空一行
<body>
// 空一行
<footer>
其中,Header 是必需的,Body 和 Footer 可以省略。 Header部分只有一行,包括三个字段:type(必需)、scope(可选)和subject(必需)。
type
commit 的类别,主要有以下几种
feat : 新功能
fix : 修复bug
docs : 文档改变
style : 代码格式改变
refactor : 某个已有功能重构
perf : 性能优化
test : 增加测试
build : 改变了build工具 如 grunt换成了 npm
revert : 撤销上一次的 commit
chore : 构建过程或辅助工具的变动
scope
用于说明 commit 影响的范围,比如数据层、控制层、视图层等等,视项目不同而不同
subject
commit 的简短描述,不超过50个字符
工作流程图
Workspace:工作区
Index / Stage:暂存区
Repository:仓库区(或本地仓库)
Remote:远程仓库
代码管理过程
(注意:每家公司可能不一样)
一般有以下几个分支:
master 主分支 发布正式环境
preview 预发分支 发布预生产环境
test 测试分支 发布测试环境
feature/xxxx 功能开发分支
hotfix/xxxx 热修复分支 修复正式环境的bug
流程:
- 从 master 签出功能分支 feature/xxxx:
git checkout -b feature/xxxx master - 在 feature/xxxx 上开发
- 开发完合并到test,部署到测试环境:
git checkout test// 切换
git pull // 拉取更新
git merge feature/xxxx // 合并
git push //推到远程 - 测试环境没问题,test合并到preview,部署预发环境
git checkout preview
git pull
git merge test
git push - 预发环境没问题,preview合并到master
git checkout master
git pull
git merge preview
git push - 在master打tag,将tag部署生产环境,如果生产环境有问题影响较大则切换上一个tag
生产环境bug修复:
- 从master签出hotfix/xxxx分支进行修复
- 修复后操作同常规流程test>preview>master
git fetch 和git pull区别
一句话:git pull = git fetch + git merge
git fetch:只会拉取远程仓库中的所有分支的最新状态,但它不会自动合并这些变化到你的当前工作分支
1、目的不同
git fetch:从远程获取最新版本到本地,但不会自动 merge,用于从远程跟踪分支下载和查看其他人完成的最新提交,但不将这些提交合并到本地存储库中。它从远程存储库中获取更改并将其存储在本地存储库中。
git pull:从远程获取最新版本并 merge 到本地,它会自动将提交合并到您的本地存储库中,而无需查看提交。
2、用途不同
git fetch:Fetch 只是通过将提交从远程存储库传输到本地存储库来使远程存储库的本地副本保持最新。将提交导入到本地分支将允许您跟上其他人所做的更改。
git pull:Pull 将更改引入本地代码存储库,以使用远程存储库更新本地存储库。
rebase和merge的区别
rebase:将分支的提交信息转移拼接到目标分支的最新提交之后;最终形成一条直线的提交记录
merge:将两个分支的最新提交点进行一次合并,形成一个新的提交点,会保留源分支的提交信息;最终形成树状的提交记录
rebase示例:
原先
f1分支领先两个提交点(f14、f15), 在f1分支执行git rebase master后:
f1分支所有提交点(f13、f14、f15)会移动到master分支的最新提交点(m5)之后
merge示例:
原先
在master分支执行git merge f1 后
可见使用merge 会保留f1分叉,在master上生成一个新的合并提交点
环境配置
配置用户名和邮箱(用于git识别你的身份)
git config --global user.name “自己的用户名”
git config --global user.emal “自己的邮箱”
输入后没有报错即代表设置成功
通过git config -l 检查一下是否配置成功 至此git安装及配置全部完成。