Git的常见用法

1.git init 初始化git生成git仓库

生成.git文件记录所有变更行为

2.git add <filename> 添文件到暂存区

git add .加入所有文件到暂存区

3.git commit -m ‘message’提交文件到本地仓库

git commit规范:

feat: 新功能
fix: 修改bug
docs: 修改文档
style: 格式化代码结构（不影响代码运行的变动)
perf: 性能优化
refactor: 重构（即不是新增功能，也不是修改bug的代码变动，比如重命名变量）
chore: 构建过程或辅助工具的变动（不会影响代码运行）
revert: 回滚到上一个版本。
test: 增加测试。
merge: 代码合并。

4.git reset 回退版本

4.1.git reset <filename> 将commit后unmodified的文件变更为modified

4.2.git reset <commitID> 回到此comiitID提交时的状态

git reset的三种模式 –mixed 、**–soft、–hard**
在本地，git会分三个区：工作区、暂存区、本地库

–mixed：保留变更且变更内容处于modified

git reset --mixed xxx
#移动本地库HEAD指针
#重置暂存区
#不仅移动了本地库的指针，同时还把暂存区的代码也做了移动。也就是说你上次添加到暂存区的代码，现在变成了红色，即未做【add】操作。如果不写--mixed，默认也是此参数

–soft：保留变更且变更内容处于staged

git reset --soft xxx
#仅仅移动本地库HEAD指针
#仅仅移动本地库HEAD指针，而暂存区和你本地的代码是没有做任何改变的。但是这个时候你上次提交到本地库的代码状态是绿色的，即你未做【commit】操作

–hard：不保留所有变更

git reset --hard xxx
#移动本地库HEAD指针
#重置暂存区
#重置工作区
#不仅移动了本地库的指针，同时还把暂存区的代码也做了移动，同时你本地的代码就是你回退的版本代码

5.git branch 分支

5.1.git checkout -b <新分支><模板分支> 以模板分支为模板，切一个新分支

如果模板不填，则以当前分支为模板

5.2.git checkout -b <新分支> origin <模板分支> 以origin远端仓库模板分支为模板，切一个新分支

5.3.git branch 查看我们当前所处的分支

5.4.git branch <branchName> 切换分支

git merge <branchName> 合并分支变更

注意是是合并变更不是内容

6.git远程仓库

6.1.git push -set-upstream origin <branchName> 将远端origin分支作为本地分支的上流分支

如果我们的本地分支是新切的，即没有设置上流分支，得先执行git push -set-upstream origin <branchName>设置上流分支，执行后远程仓库会新建一个<branchName>分支，git push（git push -u origin branch）就可以顺利将本地变更推送至远端

6.2.git fetch 拉取远端仓库信息：获知远程仓库的分支

如果是fetch下来的分支，自己再git checkout创建相应分支，可以不用设置上流分支-set-upstream来连接远端

6.3 git remote add origin +远程仓库地址

6.4 git remote set-url origin +更改远程仓库地址

6.5 git remote -v 查看挂载是否成功

7.git pull 相当于先fetch再自动merge

当自己fetch的远端分支被修改后，想将变更代码再次fetch到本地再merge合并，可以用git pull快速实现

8.git log/status/reflog 查看日志/状态/操作记录

8.1.git log 查看git日志

可以看见什么人在什么时间提交了一个什么样的commit，还能查看到每一个commit生成的属于自己的唯一哈希值，可以理解为commit的身份证

8.2.git status 查看git状态

红色字体代表有更新，再通过add后，可变绿

8.3.git reflog 查看所有的操作记录

方便查看commitID的哈希值，虽然只有前7位但已经保证唯一性，想要回到当前分支有更快的方法那就是git pull

9.文件状态 Untracked Unmodified Modified Staged

Untracked未追踪的 Unmodified未修改的 Modified修改过的 Staged暂存状态

1.没有被add过的文件叫untracked
2.add之后文件处于staged状态等待commit
3.commit之后文件处于unmodified
4.当unmodified的文件被修改则会变为modified状态
(但commit想要成功，此文件必须是staged的状态，所以更改过的文件需要重新add，使之从modified状态变更为staged)
5.modified之后的文件add之后将继续变为staged状态
6.unmodifed的文件如果不再需要了，可以remove它不再追踪，使之变为untracked状态

10.git alias 设置命令别名

找到git的etc安装目录，打开gitconfig，设置自己的alias

11.git rebase 变基

rebase的原理是枚举变更的commit，依次变基
rebase就是重新排列base，而base就是指commit
git rebase 基，出现冲突解决冲突后将变更add进暂存区，然后执行git rebase --continue继续下一个commit节点的rebase，最后查看log会发现顺序已经变12534

12.git 分支命名规范

git 分支分为集成分支、功能分支和修复分支，分别命名为 develop、feature 和 hotfix，均为单数，不可使用 features、future、hotfixes、hotfixs 等错误名称。

1.git主分支(master)。它是自动建立，用于发布重大版本更新

2.git开发主分支(develop)。日常开发在此分支上进行

3.git临时性分支：用于应对一些特定目的的版本开发(验证OK后，应该删除此分支)，主要有： 　

功能（feature）分支：它是为了开发某种特定功能，从Develop分支上面分出来的。开发完成后，要再并入Develop。可以采用feature-的形式命名。

预发布（release）分支：指发布正式版本之前（即合并到Master分支之前），我们可能需要有一个预发布的版本进行测试。预发布分支是从Develop分支上面分出来的，预发布结束以后，必须合并进Develop和Master分支。它的命名，可以采用release-的形式

修补bug（hotfix）分支：软件正式发布以后，难免会出现bug。这时就需要创建一个分支，进行bug修补。修补bug分支是从Master分支上面分出来的。修补结束以后，再合并进Master和Develop分支。它的命名，可以采用hotfix-***的形式。

注意事项： 一个分支尽量开发一个功能模块，不要多个功能模块在一个分支上开发。 feature 分支在申请合并之前，最好是先 pull 一下 develop 主分支下来，看一下有没有冲突，如果有就先解决冲突后再申请合并。

13.git中commit是最重要的

所有的概念都是围绕它展开的，比如分支是commit序列的集合载体，而在执行merge的时候也是针对一个个commit进行合并，执行reset时也是回滚至某个commit，而rebase，它的rebase指的就是commit

参考：https://www.bilibili.com/video/BV1BE411g7SV/?spm_id_from=333.999.0.0&vd_source=d6fd1d657869eff32e2a7ad32e7d535d