远程操作
git clone 【url】 --- 克隆代码到本地
git remote --- 用来操作远程仓库
git remote -v --- 显示所有远程仓库
git remote rm 【repositryName】 删除远程仓库
如图，我们可以先查看远程仓库名
git remote rename old_name new_name 修改远程仓库名
git fetch --- 获取远程仓库上更新的数据，一般和git merge配合使用
有如下场景：假设你正在开发一个新的需求，但是有人比你先上线了，此时你就要将最新的代码合并到自己的分支上，这时就用到fe t ch
git fetch origin --- 获取origin（仓库名）上更新的数据
假设上一步操作发现master分支已被更新，那么加下来我们需要执行：
git merge origin/master
来将更新到内容同步到本地
git pull --- 下载远程代码并合并
git pull === git fetch + git merge
语法格式： git pull <远程主机名> <远程分支名>:<本地分支名>
示例：
- 将远程主机 origin 的 master 分支拉取过来，与本地的 brantest 分支合并。git pull origin master:brantest
- 如果远程分支是与当前分支合并，则冒号后面的部分可以省略。git pull origin master
git push --- 将本地的分支版本上传到远程并合并。
语法格式：git push <远程主机名> <本地分支名>:<远程分支名>
如果本地分支名与远程分支名相同，可以省略冒号后的内容：git push <远程主机名> <本地分支名>
示例：
- 将本地的 master 分支推送到 origin 主机的 master 分支。git push origin master === git push origin master:master
- 删除远程master分支git push origin --delete master
提交与修改
git add --- 添加文件到暂存区
- git add . 添加所有文件 如图，我们在项目根目录下添加了src目录，并在src下添加index.js 和 style -> index.css
接下来，我们可以通过git add .来将所有有变动的文件添加到暂存区
在使用git add . 添加全部文件后，控制台提示我们“changes to be commited”，即这些变动等待提交。意味着我们已经成功将文件添加到暂存区啦！
- git add *.filtype 添加所有后缀名为filetype的文件 有时候我们不想提交所有文件，只想提交指定后缀名的文件或是指定文件名的文件，我们可以这样操作： 我们在src下新建了utils目录，其中含有两个ts文件和一个js文件
此时，我们使用git status，会提示utils目录下的内容都有变动，需要被追踪（添加到暂存区）
接下来我们使用git add *.ts 来提交所有ts文件，再使用git status 查看状态。我们发现ts文件全都被加入到暂存区了，但是js文件没有被添加进去
以此类推，我们当然也可以用 git add hello.ts 来提交指定文件名，且指定后缀的文件；前面说的git add . 其实也可以看成为 git add . 的简写，现在是不是就知道git add . 怎么来的啦？
git status 检查在上次提交之后是否有对文件进行再次修改。
git status 这个命令我们前面已经用过了～就是用来告诉你哪些文件被修改了，当前是在哪个状态（红色的是还未添加到暂存区的文件，绿色的是已经添加到暂存区但是还没提交到文件。） 我们还可以用git status -s 获取简短的描述
git diff --- 比较暂存区文件与工作区文件的差别
git commit --- 提交暂存区到本地仓库
git commit -m 【message】--- 将暂存区所有文件提交到本地仓库 git commit 【file1】 【file2】 -m 【message】 --- 将file1与file2提交到本地仓库 git commit -am 【message】 --- 不用将文件添加到暂存区，直接提交到本地仓库
git reset --- 用于回退版本，可以指定退回某一次提交的版本。
语法格式： git reset [--soft | --mixed | --hard] [HEAD]
参数说明：
--mixed为默认，不用设置，重置暂存区的文件与上一次（commit）的提交保持一致
--soft用于回退到某个版本，不会将工作区回退到上一版本
--hard撤销工作区中所有未提交的修改内容，将暂存区与工作区都回到上一次版本，并删除之前的所有信息提交。
HEAD参数说明：
HEAD ：当前版本； HEAD^：上一个版本； HEAD^^: 上上一个版本； ....... 以此类推 HEAD～0：当前版本 HEAD～1: 上一个版本 HEAD～2: 上上一个版本
例如： git reset HEAD^ --- 回退所有内容到上一个版本
git reset HEAD^ index.ts --- 将index.ts的内容回退到上一个版本
接下来尝试一下回滚操作，我们首先将之前的所有变动都已提交
使用git reset --soft HEAD^，会撤销我们此次的提交，并将暂存区回滚到提交之前到状态
使用git reset --hard HEAD^ ，会删除工作区、暂存区中所有未提交的内容，回滚到上一个版本（你写的代码都没得了，很危险！）
可以看到，咱们的目录、文件全都没得了！
git reset 【版本号】 --- 回退到指定版本
git rm --- 删除文件
git rm 【file】 --- 将文件从暂存区区和工作区删除（你写的东西都没了）
git rm --cached 【file】 --- 把文件从暂存区域移除，但仍保留在当前工作目录中
分支管理
分支在线学习教程：learngitbranching.js.org/?locale=zh_…
- git branch bugFix --- 创建名为bugFix的分支
- git checkout bugFix --- 切换到bugFix
- git checkout -b bugFix --- 创建并切换到bugFix分支
- git branch -d bugFix --- 删除bugFix分支
- git merge bugFix --- 将bugFix分支合并到当前所在分支上如图，我们当前在main分支下，切到main分支下有一下文件
现在，我们创建并切换到bugFix分支
一开始我觉得，新创建的分支应该是空的，其实不然，新建的bugFix分支也有和main分支一样的文件，但是新分支中文件的改动，不会映射到原分支
可以看到，在新建的bugFix分支上也有readme.md 现在，我们在bugFix分支上修改一些东西并提交
修改readme：
新建一些文件
提交：
我们再使用git checkout main 回到原分支，会发现新建的东西都不见了 ，这时就需要用到merge
在终端输入 git merge bugFix （将bugFix合并到当前分支，即main分支）。可以看到，终端提示我们文件有变动，说明我们成功把bugFix中的代码合并过来了
git stash
这个操作是干什么的呢？
下面看一个场景: 假设我们当前正在分支上开发支付需求，开发到一半了，老板突然说要先开发另一个住宿需求，非常急！没办法，我们只能先开发住宿需求，可是支付需求还没写好，不能提交，咋办？
这时，就用到了git stash（隐藏），即将我们尚未提交到变动隐藏起来（不影响下次提交），随时可以恢复（恢复后等你写完了再提交）
如图，我们正在index.js下开发一个需求，但是还没写完
此时，我们在终端输入git stash,就会发现我们的变动都被删除了（这里相当于index.js被删除了）
接下来我们就可以放心的开发住宿需求了，我们在another.js里编写好了住宿需求的代码，
然后使用git add . 将此次需求的改动添加到暂存区。使用git status会发现，支付需求相关代码的变动（即index.js中的变动）并没有添加到暂存区，也就是支付需求写的代码不会影响我们这次的提交！这样我们就能放心的使用commit了
提交完后，我们可以使用 git stash 将我们支付需求已经写好的代码调出来（index.js），继续开发
git rebase
git rebase 又称 变基 ，比较不好理解。我们用图说话
首先通过简单的提交节点图解感受一下rebase在干什么，两个分支master和feature，其中feature是在提交点B处从master上拉出的分支，master上有一个新提交M，feature上有两个新提交C和D。
此时切换到feature分支上，执行如下命令，相当于是想要把master分支合并到feature分支（这一步的场景就可以类比为我们在自己的分支feature上开发了一段时间了，准备从主干master上拉一下最新改动）
代码块
git checkout feature
git rebase master
下图为变基后的提交节点图，解释一下其工作原理(feature: 待变基分支、当前分支；master：基分支、目标分支)：
当在feature分支上执行git rebase master时，git会从master和featuer的共同祖先B开始提取feature分支上的修改，也就是C和D两个提交。然后将feature分支指向master分支的最新提交上，也就是M。
最后把提取的C和D接到M后面，但这个过程是删除原来的C和D，生成新的C’和D’，他们的提交内容一样，但commit id不同。feature自然最后也是指向D’
git revert
git revert 撤销 某次操作，此次操作之前和之后的commit和history都会保留，并且把这次撤销，作为一次最新的提交。那么它和git reset有什么区别？
比如，git commit链是这样的 A -> B -> C -> D ，现在我们想撤销 D 。
如果用的是git reset，如 git reset --soft HEAD^，那么操作执行后，git commit链就变成了 A -> B -> C
如果用的是git revert D ，那么操作执行后，git commit链就变成了 A -> B -> C -> D -> D' 。相当于用D’的提交来抵消了D的提交
一般用法 git revert 【commit-id】
- git revert --abort有时revert后会产生代码冲突的情况，可以通过--abort来回到指令执行之前的样子，相当于啥也没有干，回到原始的状态
- git revert -quit该指令会保留指令执行后的车祸现场
git tag
通常在软件发布的时候会打一个tag(指向某次commit的指针)，用于标注这次发布的相关信息, 这样做的好处是，将来如果这个版本出现了问题，可以通过tag迅速定位到当前版本（虽然我们也可以通过commit id进行定位，但是commit id 又臭又长！），进行错误修复。
- 创建标签 git tag v1.0v1.60就是这个tag的名称，通常以版本号命名。注意：tag是打在最近的一次Commit记录上的，比如我最近一次提交记录的Commit ID是 7fd77215642fe36e73674f604ef49a0097d3c0d3，那么执行完 git tag v1.6命令后，tag就打在了这个Commit ID上。还可以通过 git tag -a v1.0 -m “description” 来创建一个带有描述信息的tag
- 查看标签查看本地某个标签的详细信息 --- git show 【tagName】查看本地所有tag --- git tag -l查看远程所有tag --- git -ls remote --tags origin
- 删除标签删除本地tag --- git tag -d 【tagName】删除远程tag --- git push origin :refs/tags/将本地tag推到远程 --- git push origin :
- 检出标签
git checkout -b
因为 tag 本身指向的就是一个 commit，所以和根据commit id 检出分支是一个道理。
示例：
我们创建了一个调tag.js，这js文件有三个版本，每个版本都比上一个版本多了一行 console.log('this is version xxx')。再每次commit后，我们为此次提交打上对应的tag，如下图。
准备好了之后，我们来尝试使用git checkout 来切换到不同的tag上。这里我们输入 git checkout v2.0,就会将代码切换到第二次commit的内容
一篇不错的git原理Git 原理
番外篇：
vim操作：
按i可以输入内容
按shift+wq退出编辑
