git 命令行总结

简介
Git是一个分布式的版本控制系统，与集中式的版本控制系统不同的是，每个人都工作在通过克隆建立的本地版本库中。也就是说每个人都拥有一个完整的版本库，查看提交日志、提交、创建里程碑和分支、合并分支、回退等所有操作都直接在本地完成而不需要网络连接。
对于Git仓库来说，每个人都有一个独立完整的仓库，所谓的远程仓库或是服务器仓库其实也是一个仓库，只不过这台主机24小时运行，它是一个稳定的仓库，供他人克隆、推送，也从服务器仓库中拉取别人的提交。
Git是目前世界上最先进的分布式版本控制系统，没有之一，对，没有之一!
工作流：
**工作区：**就是你在电脑上看到的目录，比如D盘的JavaScript（.git除外）为了上传方便，最好是在该文件夹下编写代码
暂存区：.git目录里面的stage文件（或者是index文件），暂存区存放的是add命令添加的文件，通过commit命令提交更改后，暂存区的内容就被提交到当前分支
**版本库(Repository)仓库：**工作区中的隐藏文件.git 其中版本库里面存了很多东西，其中最重要的就是stage或者是index文件(暂存区)，还有Git为我们自动创建了第一个分支master,以及指向master的一个指针HEAD。
pullrequest工作流程
目前使用的linke
接收需求首先创建一个个人的开发分支，然后在个人的分支上开发，需要合并的时候提交请求，通知审核人进行代码审核，避免直接合并出现不必要的问题（目前正在使用的工作模式）
个人习惯是创建一个开发分支和一个备份分支，然后不定时的在本地备份更新一份代码。
常用命令
git config --list 检查设置
git init . 初始值
git config --global user.name ‘’ 设置用户名
git config --global user.email ‘’ 设置邮箱
git help config 获取帮助
git config --global --replace-all user.name ‘用户名’ 修改用户名
git config --global --replace-all user.email ‘邮箱’ 修改邮箱
git diff 工作区与暂存区的区别 查看修改但是未暂存
git diff --cached 查看修改暂存了还未提交
(git diff --cached和git diff –staged相同作用)
git reflog 查看commit历史
git reset --soft HEAD^ 取消commit但不取消add
不删除工作空间的改动代码 ，撤销commit，不撤销git add file
git reset --hard HEAD^ 取消add（版本回退）
删除工作空间的改动代码，撤销commit且撤销add
git commit --amend 修改commit注释
其他命令
git branch -a 查看本地和远程的分支
git branch -v 查看分支最后一次的提交
git status 查看状态
git commit -a -m ‘注释’ add + commit 缩写
git restore --staged config/config.ts add后指定不commit某文件
创建、切换、删除分支
git checkout -b 分支 在本地创建并切换分支
git checkout -b 相当于 git branch dev 、git checkout dev两条命令
git checkout -b 本地分支origin/远程分支 拉取并创建本地分支
git branch 分支 创建分支
git push --set-upstream origin 分支 创建的分支推送到线上
git checkout 分支 切换分支 注：切换分支前保证是最新提交状态
git branch -d 分支 删除分支
版本回退
git log 查看commit日志
git log --oneline 一行查看commit日志
git reflog 查看commit日志（不受版本回退影响）
git reset --hard HEAD^ 回退至上个版本
git reset --hard HEAD~100 回退到100个之前的版本
git reset --hard 版本号 回退至指定版本

第一次提交
git init . 初始化
git remote add origin url 关联远程仓库
git remote -v 查看是否关联成功
git pull origin master 远程仓库的代码拉到本地
git add . 跟踪所有改动过的文件
git commit -m ‘’ 记录
git push origin 分支 上传

git reset（回退）和git revert（反做）区别
git revert是用一次新的commit来回滚之前的commit，此次提交之前的commit都会被保留；
git reset是回到某次提交，提交及之前的commit都会被保留，但是此commit id之后的修改都会被删除
git reset
git reset的作用是修改HEAD的位置，即将HEAD指向的位置改变为之前存在的某个版本，如下图所示，假设我们要回退到版本一
适用场景： 如果想恢复到之前某个提交的版本，且那个版本之后提交的版本我们都不要了，就可以用这种方法。

git revert
git revert是回退旧的提交必然会导致当前最新代码发生变化，比如之前某个提交加了一行代码，那么回退就是在相同位置减一行代码。Git不会真的把旧提交抛弃，如果直接抛弃，历史记录就追踪不到了。因此，旧提交其实是没动的，Git只是根据旧提交反着做了一遍，这才导致最新的代码发生了改变。只有把revert命令回退导致的改动重新提交，revert命令才算真的完成并生效，否则效果只相当于修改了工作树的文件而已。
注意：revert之后需要push到远程分支上其他用户才能看到回退发生的改动。
适用场景： 如果我们想撤销之前的某一版本，但是又想保留该目标版本后面的版本，记录下这整个版本变动流程，就可以用这种方法。

git merge和git rebase的区别

git merge
先说一下merge。Merge命令会保留所有commit的历史时间。每个人对代码的提交是各式各样的。尽管这些时间对于程序本身并没有任何意义。但是merge的命令初衷就是为了保留这些时间不被修改。这样也就形成了以merge时间为基准的网状历史结构。每个分支上都会继续保留各自的代码记录, 主分支上只保留merge的历史记录。子分支随时都有可能被删除。子分子删除以后，你能够看到的记录也就是，merge某branch到某branch上了。这个历史记录描述基本上是没有意义的
自动创建一个新的commit
如果合并的时候遇到冲突，仅需要修改后重新commit
优点：只处理一次冲突，记录了真实的commit情况，包括每个分支的详情
缺点：commit比较频繁，看到分支杂乱
个人推荐使用git merge
git rebase
git rebase会删除原始分支上已提交的commit
rebase 特点：会合并之前的commit历史
优点：可能会多次解决同一个地方的冲突，得到更简洁的项目历史，去掉了merge commit
缺点：如果合并出现代码问题不容易定位
git rebase 的黄金法则便是，绝不要在公共的分支上使用它。
git reset（回退）和git revert（反做）区别
git revert是用一次新的commit来回滚之前的commit，此次提交之前的commit都会被保留；
git reset是回到某次提交，提交及之前的commit都会被保留，但是此commit id之后的修改都会被删除
git reset
git reset的作用是修改HEAD的位置，即将HEAD指向的位置改变为之前存在的某个版本，如下图所示，假设我们要回退到版本一
适用场景： 如果想恢复到之前某个提交的版本，且那个版本之后提交的版本我们都不要了，就可以用这种方法。

git revert
git revert是回退旧的提交必然会导致当前最新代码发生变化，比如之前某个提交加了一行代码，那么回退就是在相同位置减一行代码。Git不会真的把旧提交抛弃，如果直接抛弃，历史记录就追踪不到了。因此，旧提交其实是没动的，Git只是根据旧提交反着做了一遍，这才导致最新的代码发生了改变。只有把revert命令回退导致的改动重新提交，revert命令才算真的完成并生效，否则效果只相当于修改了工作树的文件而已。
注意：revert之后需要push到远程分支上其他用户才能看到回退发生的改动。
适用场景： 如果我们想撤销之前的某一版本，但是又想保留该目标版本后面的版本，记录下这整个版本变动流程，就可以用这种方法。