Git&Github基础介绍
一、Git
1.什么是git
分布式版本控制系统(DVCS)
-
分布式:不需要联网,在自己的机器上就可以使用
-
版本控制:记录、管理、回溯文件的修改文件
官网
git模型
工作区 暂存区 本地仓库 远程仓库
图片来源(转载)
2.git基础配置
-
创建一个本地git版本库
-
通过git init指令
-
git init:让当前文件夹变成git仓库(创建.git文件夹)
-
git init folder:创建一个新的文件夹并初始化为git仓库
-
-
-
git账号配置
-
why?多人合作区分用户->让github能识别出你
-
全局配置
git config --global user.name "name" git config --global user.email "email"
-
针对某一版本库专门设置
不加–global即可
-
3.git基础用法
补充命令基础知识
(1)
(2)
(3)cat(英文全拼:concatenate)命令用于连接文件并打印到标准输出设备上。
(1)文件暂存
-
暂存区:已经修改、等待后续提交的文件
-
将文件加入暂存区:
-
git add file/folder
-
只会添加修改过的文件
-
关于警告:(4 条消息) git如何避免”warning: LF will be replaced by CRLF“提示? - 知乎 (zhihu.com))
- 删除文件的几种情况
- 只在本地删除版本库中不存在的文件:rm
- 同时删除本地和版本库中的文件:
git rm
先rm再add - 将一个已暂存的新文件取消暂存:
git rm --cached
-
重命名文件:
git mv
(等价于mv + git rm + git add->现在本地重命名,remove旧的,add新的) -
查看当前工作区和暂存区状态:
git status
-
文件三个类别:未跟踪(Untracked)、已跟踪(Tracked)、被忽略(Ignored)
关于.gitignore:
-
名为.gitignore的文件中规定忽略哪些文件。
-
语法:
- #开头的行为注释
- *通配多个字符,**通配中间目录(有或无)就比如:“✳.c”意为忽略所有.c后缀的文件;a/✳✳/b匹配a/x/b、a/b、a/x/y/b等
- /开头只匹配根目录,否则匹配所有目录
- !取消忽略
- …
-
git check-ignore -v file
查看某个文件是否被忽略,以及忽略的规则
-
-
(2)提交更改
-
将暂存区内容提交到本地仓库,生成一个新的版本,也就是最开始那个模块那儿的中间的左右两部分之间的提交
- git commit:默认编辑器编辑提交信息
- git commit -m “message”
- -a (–all)自动暂存所有更改的文件
-
查看提交历史:
git log
--oneline
:每一个提交一行--graph
:显示分支结构-p
:显示详细的修改内容
-
每个提交都有一个唯一的sha-1标识符(40位十六进制数)
git show id
:显示提交详细信息(id在不重复的前提下只写前几位)
-
检出之前的某一版本
git checkout id
(记得切回master分支)
-
关于commit message:
-
记录更改的原因或内容,方便回溯版本
-
Angular规范
<type>([scope]):<summary> [body] [footer]
- type:更改类型(init(初始化)/build(构建项目)/fix(修改问题)/feat(新特性)/docs(文档修改)/refactor(代码重构)/test(测试用例修改)/style(代码格式修改,注意不是css修改)/chore(其他修改,比如依赖管理)/…)
- 重大更改可以写BREAKING CHANGE或DEPRECATED
- scope:影响范围(可选):比如route、component、utils、build等
- summary:更改的简要描述
- body:详细描述
- footer:解决了issue了可以写 Fixes #id或Closes #id
-
-
版本:
-
创建标签:
- 轻量标签:
git tag tag id
(id可选,默认为head) - 附注标签:
git tag -a tag -m "message" id
- 轻量标签:
-
查看标签
git tag
-
-
detached HEAD 问题
-
什么是HEAD:当前工作区在提交历史中的指针
-
什么是detached HEAD:HEAD 指向某个历史提交,而不是某个分支
-
什么情形会出现detached HEAD
git checkout id
此后的修改不会出现在任何分支- 切换回master之后会出现一条不属于任何分支的提交,相当于修改会丢失
-
如何解决:在刚刚进入的那个id版本里
git checkout -b detached(分支名)
-
(3)分支
-
创建分支:
git branch name
:基于当前HEADgit branch name id
:基于id提交
-
查看分支:
git branch
(带 -a 显示远程分支)git show-branch
(更详细)
-
切换分支
git checkout name
git checkout -b name
:创建并切换
-
内容比较
git diff branch1 branch2
:比较这两个分支git diff branch
:比较工作区和分支git diff
:比较工作区和暂存区
-
定位提交
- 分支名:跟HEAD一样,也是一个指针(实际上叫引用ref)
- 可以基于ref使用~或^定位父提交
- 表示第一个父提交,2表示第二个父提交的第一个父提交
- 表示第一个父提交,2表示第二个父提交
(4)合并
-
将多个分支的更改都合并到当前分支:
git merge branch1 branch2...
几种merge的情况:
-
当前分支只比被合并分支多提交:already up-to-date
-
被合并分支只比当前分支多提交:fast-forward
-
都有新的提交:产生一个merge commit
-
有冲突需要手动解决冲突(add后再次commit生成merge commit)
有冲突版:在master添加line7,在conflict分支添加line7_conflict
可选择多种解决办法,然后正常提交即可
-
实际上,在github上一般通过PR完成,两种特殊的merge方法:
-
squash merge:将目的分支多出的所有提交压缩为一个新提交并入当前分支(保留了代码层面的修改但是目的分支上会丢失这个更改的记录,简单说就是代码改了但记录丢了)
-
rebase:变基
-
命令行直接rebase会将当前分支接到目标分支后
- 这种情况会导致提交历史更改,同步会有冲突,合作时不推荐(要是远程有人还想继续在当前分支继续提交的话就会找不到这个版本了,因为接到了目标分支后名字会改。但是这样的好处是提交记录就会是链状了而不会出现多条链)
-
通过github PR rebase merge 会将目标分支接到当前分支后
-
-
-
-
4.git进阶用法
(1)修改历史记录
*如果项目已公开且有其他人协作,就不应该去修改历史
-
不算是修改的修改:
git revert id
- 生成一个新的提交,将目标提交的更改撤销
- 历史的所有提交都不会更改
-
修改最新提交的提交信息:
git commit --amend
- 会弹出编辑器编辑提交信息(用-m直接写也可以)
- 只会修改最新提交的提交信息
- 本质上修改了提交历史记录,不建议在协作时使用
-
回到之前某一提交的状态:
git reset id
- –soft:只修改HEAD指针,不修改暂存区和工作区
- –mixed:修改HEAD指针和暂存区,不修改工作区(默认)
- –hard:修改HEAD指针、暂存区和工作区(完全回退)
-
rebase用在同一条分支上可以修改提交历史
git rebase -i id
:交互式rebase,可以修改id分支后的所有历史提交- 会弹出编辑器,
- pick:保留该提交
- edit:保留该提交但会进入修改状态
- squash:将该提交和上一个提价合并
- drop/删除整行:删除该提交
(2)远程版本库
远程版本库也是一个普通的git版本库
-
git clone src dest
将远程版本可以克隆到本地 -
git push
将本地的提交推送到远程版本库(无法直接push到远程版本库检出的分支中因此远程一般使用裸版本库–bare) -
git pull
将远程版本库的提交拉取到本地(包含git fetch和git merge两个操作)
(3)子模块
添加为子模块:
(4)git结构
- .git/hooks:钩子脚本,在特定操作时自动执行
- info、logs不重要,存放信息日志
- .git/objects:
- 文件名是对象的sha1
- 通过
git cat-file -p id
可查看对象内容(-t查看类型) - 对象类型:commit tree blob
(5)分支
HEAD:指针,指向当前最新提交id
refs:存放各种ref指针
heads:存放本地分支指针
remotes:… 远程…
tags:存放标签指针
- 缩写:
- master->refs/heads/master
- origin/master->refs/remote/origin/master
二、GitHub基本操作
-
issue:反馈bug、提出新功能、寻求帮助;建议使用markdown语法,遵守规范;自己开的issue解决后及时关闭
-
discussion:新开功能,类似帖子/社区,比issue范围广、更随意
-
用户a的repo,要先fork下来->变成用户b的repo
- 对于他人的repo是不能直接push的,向其中添加更改都要通过Pull Request(PR)
- 如果是解决了某个issue的bug,描述最好写成fix/close #issue_number,这样在自动链接PR merge之后会自动关闭issue
- 一个PR最好就是一种修改,多个修改分多次PR
-
对于自己有权限修改的项目也建议通过pr修改,更清晰一点(不必fork)
-
开PR之后merge之前不要随意删除源分支,也不要继续向其中添加无关修改
来自b站一个讲解视频做的笔记如有侵权请及时联系