前言
本文主要介绍git
密钥生成与配置,基础命令包括clone
、add
、commit
、pull
、push
等,冲突处理,查看并回退历史版本,以及提交规范等。
密钥生成与配置
- 配置用户名和邮箱
//打开git bash 输入以下命令
//用户名,填你的名字全称 如:yaoxfly 方便识别
git config --global user.name 'yaoxfly'
//邮箱,填你的常用邮箱,代码出错时会发邮件通知你
git config --global user.email '123@qq.com'
- 生成私钥和公钥
ssh-keygen -t rsa 并按回车3下
tips:为什么按三下,是因为有提示你是否需要设置密码,如果设置了每次使用git都会用到密码,一般都是直接不写为空,直接回车就好了.
- 私钥和公钥文件名和生成路径
私钥:id_rsa
,公钥:id_rsa.pub
默认文件夹在你打开git bash
的目录,或者在你的用户目录~/.ssh
文件夹下
- 配置
复制id_rsa.pub
文件里的所有内容粘贴到需要地方,比如github
或码云的公钥配置上
tips: 在生成key
之前git config --global
姓名和邮箱一定要设置, 否则每次操作都要填写用户名和密码,不要在秘钥上设置密码,直接下一步就好。
基础
clone(克融项目)
git clone 'xxxx'
add(新增文件)
git add . // 匹配所有的文件, 提交被修改的和新建的文件,但不包括被删除的文件
git add -u // update tracked files 更新所有改变的文件,将修改的文件提交到暂存区。
git add -A // 是上面两个功能的合集(git add --all的缩写)
commit(提交)
- 提交
git commit -m "添加你的注释,一般是一些更改信息"
- 撤回提交
//仅仅是撤回commit操作,您写的代码仍然保留
git reset --soft HEAD^
push (远程提交)
- 提交
git push origin master:master
-
fatal: refusing to merge unrelated histories
拒绝合并不相关的历史解决方式,强制提交
git push origin master:master -f
- 提交简写
git push -u
tips:出现这个问题的最主要原因还是在于本地仓库和远程仓库实际上是独立的两个仓库。
pull(拉新合并)
- git pull
命令基本上就是 git fetch
和 git merge
命令的组合体,git 从指定的远程仓库中抓取内容,然后马上尝试将其合并进你所在的分支中。
- git fetch [remote-name] (拉新)
这个命令会访问远程仓库,从中拉取所有你还没有的数据。 执行完成后,你将会拥有那个远程仓库中所有分支的引用,可以随时合并或查看。
但是注意的是 git fetch
并不会自动合并或修改你当前的工作。 你必须手动将其合并入你的工作。
- git merge [remote-name] (合并)
合并分支
- 总结
使用 git pull
,命令来自动的抓取然后合并远程分支到当前分支。(相当于一次执行fetch加merge命令)更简单,更方便快捷,更舒适的工作流程。
branch(分支)
- 创建新分支
git branch newBranch
- 切换新分支
git checkout newBranch
- 合并分支
git merge newBranch
- 删除分支
git branch -D newBranch
tips:合并分支前,一定要切换到想要合并的分支上,比如主分支,再执行分支合并操作
其他命令
- 查看提交历史
git log
- 查看当前状态
git status
- 缓存删除
git rm -r --cached .
tips:应用场景,比如.gitignore忽略的文件无效的情况等
- 修改本地代码关联的远程地址
git remote set-url origin ssh://git@ip:端口/home/git/gitrepo/git.git
tips:当代码库远程迁移后,可使用当前功能
获取指定历史版本源代码
git clone http://XXXX/XX.git //克融项目
git log // 查看commit历史,并找到需要的版本
git checkout '版本号' //获取
tips:运行git log
命令 ,查看commit后跟着的哈希值就是版本号
冲突解决
- 版本分支的问题
问题描述:提交git仓库时出现:Your branch is up-to-date with 'origin/master'.
/*解决方案*/
//这时候我们就需要新建一个分支
git branch newBranch
//检查分支是否创建成功,前面的*代表的是当前你所在的工作分支
git branch
//切换到你的新分支
git checkout newBranch
//添加修改和新增的文件
git add .
//提交到本地
git commit -m "18.03.01"
//检查是否成功
git status
//然后切换到主分支
git checkout master
//将新分支提交的改动合并到主分支上(合并前一定要切换到主分支)
git merge newBranch
// push代码了
git push -u origin master
//删除这个分支
git branch -D newBranch
- 冲突导致,文件乱码
++<<<<<<< HEAD
++<<<<<<< new_branch
可直接删除掉这些乱码,保存后再提交,某些ide
可提示,并可删除这些乱码等其他智能操作,如vs code
,编码神器,我的最爱,哈哈,强推一波。
- 提示:仓库内还有未合并的文件,不能提交代码.
问题描述:committing is not possible because you have unmerged files
/*解决方案*/
//把你修改的文件一个个添加进去
git add '文件名',
//提交本地
git commit -a -m "备注信息"
//提交远程
git push -u
提交规范
- 规范说明
git提交也有规范,业内做的比较好,具有参考价值的就是Angular
的提交。
<type>(<scope>): <subject> #header
// 空一行
<body>
// 空一行
<footer>
//中文释义
<类型>[可选的作用域]: <主题> 描述
[可选的正文]
[可选的脚注]
- 主体参数
参数 | 说明 | 是否必须 |
---|---|---|
type | 提交类型 | true |
scope | 提交影响的范围 | false |
subject | 提交目的的简短描述 | false |
header | 内容 | true |
-
type有以下标识
- feat:增加新功能(feature)
- fix : 修复bug
- docs : 文档改变 (documentation)
- style : 代码格式改变
- refactor : 某个已有功能重构
- build : 改变了build工具, 如
- grunt换成了npm
- revert: 撤销上一次的 commit
- perf : 性能优化
- test : 增加测试
- ci: 与CI(持续集成服务)有关的改动
- chore:不修改src或者test的其余修改,例如构建过程或辅助工具的变动
- del:删除某个内容
tips:
- 如果type为feat和fix,则该 commit 将肯定出现在 Change log 之中。其他特殊情况(docs、chore、style、refactor、test)由你决定,要不要放入 Change log,建议是不要。
- 当一次改动包括主要type与特殊type时,统一采用主要type。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。