基本的拉取上传文件命令
0.git pull先更新文件/git pull origin dev; git status 查看文件的增删改状态
1.git clone 在线库存地址; git clone -b dev(远程分支) 链接
2.git add 要提交的文件或者文件夹 或者git add .(表示提交所有修改过的文件，添加到暂存区)
注：git add 只将新建的或者已更改的文件添加到索引区。（不会添加删除的文件）
3.git commit -m '备注';提交到暂存区 -m(默认为master分支) / 跳过检查提交：git commit --no-verify commit -m '注释'
3.git push ;正式提交
4.git log 查看提交的日志 或者git log --pretty=oneline 更加清楚明了的查看
5. 关联远程分支：
(1) git branch --v 查看关联关系
(2) 关联远程分支：git branch --set-upstream-to=origin/远程分支的名字 本地分支的名字
ps:关联远程库后，使用命令git push -u origin master第一次推送master分支的所有内容；
或者：git checkout -b 本地分支名字 origin/远程分支名字 创建本地分支并自动关联远程分支
此后，每次本地提交后，只要有必要，就可以使用命令git push origin master推送最新修改；Git是跟踪修改的，每次修改，如果不用git add到暂存区，那就不会加入到commit中。
用git diff HEAD -- qq.html命令可以查看工作区和版本库里面最新版本的区别
常用基本命令
1. git diff 提交文件之前可用此命令查看文件被修改了哪些
2. git log 上传文件后 可查看提交的历史信息
git log --pretty=oneline --abbrev-commit 找到历史提交的commit id
git log --graph 查看到分支合并图。或者git log --graph --pretty=oneline --abbrev-commit
3. git reset --hard HEAD^ 回退到上一个版本
--hard
4. git reset --hard 09BH(历史版本16进制的前四位即可，git自动找) 回到指定版本
如果关闭了git窗口 可使用git reflog命令查看之间提交的版本
git rebase --onto cbe8527^ cbe8527 删除某次提交
5.cat op.html 或者git show 查看文件内容
5. git checkout -- qq.html 或者 git restore op.html 把qq.html文件在工作区的修改全部撤销，这里有两种情况：
(1)一种是 qq.html自修改后还没有被放到暂存区，现在，撤销修改就回到和版本库一模一样的状态；
(2)一种是 qq.htmlt已经添加到暂存区后，又作了修改，现在，撤销修改就回到添加到暂存区后的状态。
6. git diff HEAD -- qq.html 查看工作区和版本库里面最新版本的区别
7. git reset HEAD 可以把暂存区的修改撤销掉），重新放回工作区，
git reset HEAD -- . 撤销所有
git reset HEAD -- filename 撤销特定目标
git rm -cached filepath 将文件从缓存中删除
8.git reflog 查看命令历史，以便确定要回到未来的哪个版本。
9. git rm qq.html 删除文件 git rm -r css/ 删除文件夹
10.git remote 查看远程库的信息 或用git remote -v显示更详细的信息
11.git push origin dev(分支名称) 推送对应分支
但是，并不是一定要把本地分支往远程推送，那么，哪些分支需要推送，哪些不需要呢？
master分支是主分支，因此要时刻与远程同步；
dev分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步；
bug分支只用于在本地修复bug，就没必要推到远程了，除非老板要看看你每周到底修复了几个bug；
feature分支是否推到远程，取决于你是否和你的小伙伴合作在上面开发。
12. git tag v1.0(版本号) 为项目打版本号(标签)
git push origin --tags 推送全部尚未推送到远程的本地标签
git tag -d v0.9 删除标签 先从本地删除 然后git push origin :refs/tags/v0.(删除一个远程标签)
命令git tag 用于新建一个标签，默认为HEAD，也可以指定一个commit id；
命令git tag -a -m "blablabla..."可以指定标签信息；
命令git tag可以查看所有标签
13.git commit --amend 修改最后一次提交的注释
https://www.jianshu.com/p/098d85a58bf1 分支及基本处理
1. git checkout -b dev 创建dev分支，然后切换到dev分支 或者 git switch -b dev
-b参数表示创建并切换
相当于这两条命令：
git branch dev
git checkout dev
2. git branch 查看当前分支; 查看已有的本地及远程分支： git branch -a
3. git merge dev 将子分支合并到主分支master,合并后，查看主分支，和子分支内容一样
Fast-forward信息，Git告诉我们，这次合并是“快进模式”，也就是直接把master指向dev的当前提交，所以合并速度非常快。
总结:
Git鼓励大量使用分支：
查看分支：git branch
创建分支：git branch
切换分支：git checkout 或者git switch
创建+切换分支：git checkout -b 或者git switch -c
拉去远程分支：git fetch origin dev（dev为远程仓库的分支名）
合并某分支到当前分支：git merge
删除本地分支：git branch -d ; 删除远程分支：git push origin --delete dev
处理常见问题
1.本地git rm file 后远程仓库还有该文件？
$ git add -u 只会处理已修改或者已删除的文件，但是不会处理新建的文件
$ git commit -m "delete test"
$ git push
2.处理常见合并分支冲突
图上意思：
编码qe.html
冲突(内容):在q .html中合并冲突
自动合并失败;修复冲突，然后提交结果。
Git告诉我们，qe.html文件存在冲突，必须手动解决冲突后再提交。git status也可以告诉我们冲突的文件；
(1)git log --graph --pretty=oneline --abbrev-commit 看到分支的合并情况
(2)把Git合并失败的文件手动编辑为我们希望的内容，再提交。
(3)删除feature1分支
3.git add 等不能操作文件？
4.Git操作的过程中突然显示：
Another git process semms to be running in this repository, e.g. an editor opened by ‘git commit’. Please make sure all processes are terminated then try again. If it still fails, a git process remove the file manually to continue…翻译过来就是git被另外一个程序占用，重启机器也不能够解决。
原因在于Git在使用过程中遭遇了奔溃，部分被上锁资源没有被释放导致的。
解决方案：进入项目文件夹下的 .git文件中（显示隐藏文件夹或rm .git/index.lock）删除index.lock文件即可。
git commit 时 报错处理
提示：husky > pre-commit (node v12.18.3) ‼ Some of your tasks use `git add` command. Please remove it from the config since all modifications made by tasks will be automatically added to the git commit index.
解决：删除或重命名 .git > hooks > pre-commit 文件即可
进入hooks文件夹，并找到pre-commit文件，这就是commit失败的根源所在了。
该文件所起到的作用是：
pre-commit(客户端)钩子，它会在Git键入提交信息前运行做代码风格检查。
如果代码不符合相应规则，则报错。
我们将该文件删除之后，再进行commit，发现就能成功提交了。
- git merge 分支 出现 warning: could not open directory ‘xxx‘: Permission denied...
解决：这种错误说明无权限操作文件，关闭掉编辑器及代码运行器即可
分支管理策略
通常，合并分支时，如果可能，Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。
如果要强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。
下面展示一下--no-ff方式的git merge：
1.创建并切换分支
git switch -c dev
2. 修改文件并提交一个新的commit
git add qe.html
git commit -m 'change qe.html'
3.切换回master主分支
git switch master
4. 准备合并dev分支，请注意--no-ff参数，表示禁用Fast forward：
$ git merge --no-ff -m "merge with no-ff" dev 这种合并方法会在master分支上新建一个提交节点，从而完成合并
5. 因为本次合并要创建一个新的commit，所以加上-m参数，把commit描述 写进去。
合并后，我们用git log看看分支历史：
$ git log --graph --pretty=oneline --abbrev-commit
分支策略
在实际开发中，我们应该按照几个基本原则进行分支管理：
首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；
那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；
你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。
合并分支时，加上--no-ff参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并，而fast forward合并就看不出来曾经做过合并。
Bug分支
团队协作中，bug是连绵不断的，所以，每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。
如果现在有个bug,我们来操作下：。
1.git stash 先把你当前分支的内容存贮起来，等以后恢复现场后继续工作;
2.git switch master 切换到主分支，准备创建一个bug分支(issue-101);
3.git switch -c issue-101 创建一个bug分支(issue-101);
4. git add qe.html
git commit -m "fix bug 101" 修改bug并提交
5.修复完成后，切换到master分支，并完成合并，最后删除issue-101分支：
git switch master;
git merge --no-ff -m "merged bug fix 101" issue-101
git branch -d issue-101
6.bug已修复，现在，是时候接着回到dev分支干活
git switch dev
git stash list 查看之前存贮的内容：
stash@{0}: WIP on dev: f52c633 add merge
7. 现在需要恢复一下存贮的内容，恢复有2种方法：
（1）用git stash apply恢复，但是恢复后，stash内容并不删除，你需要用git stash drop来删除
（2）用git stash pop，恢复的同时把stash内容也删了
再用git stash list查看，就看不到任何stash内容了
你可以多次stash，恢复的时候，先用git stash list查看，然后恢复指定的stash，用命令：
git stash apply stash@{0}
8. 在master分支上修复了bug后，我们要想一想，dev分支是早期从master分支分出来的，所以，这个bug其实在当前dev分支上也存在。
那怎么在dev分支上修复同样的bug？重复操作一次，提交不就行了？
同样的bug，要在dev上修复，我们只需要把4c805e2 fix bug 101这个提交所做的修改“复制”到dev分支。
注意：我们只想复制4c805e2 fix bug 101这个提交所做的修改，并不是把整个master分支merge过来。
为了方便操作，Git专门提供了一个cherry-pick命令，让我们能复制一个特定的提交到当前分支：
git branch
* dev
master
$ git cherry-pick 4c805e2
[master 1d4b803] fix bug 101
1 file changed, 1 insertion(+), 1 deletion(-)
Git自动给dev分支做了一次提交，注意这次提交的commit是1d4b803，它并不同于master的4c805e2，因为这两个commit只是改动相同，但确实是两个不同的commit。用git cherry-pick，我们就不需要在dev分支上手动再把修bug的过程重复一遍。
总结：
修复bug时，我们会通过创建新的bug分支进行修复，然后合并，最后删除；
当手头工作没有完成时，先把工作现场git stash一下，然后去修复bug，修复后，再git stash pop，回到工作现场；
在master分支上修复的bug，想要合并到当前dev分支，可以用git cherry-pick Feature分支
添加一个新功能时，我们为了不打乱主分支master,所以在我们当前分支上（dev）新建分支
1. git switch -c feature-1 新建分支写功能
2.git add
3.git commit -m 'feature-1'
4.切回dev,准备合并
git switch dev
合并时如果该功能不适用，需要删除，怎么操作？
如下：
git branch -d feature-1
报错：error: The branch 'feature-1' is not fully merged.
If you are sure you want to delete it, run 'git branch -D feature-vulcan'.
销毁失败。Git友情提醒，feature-1分支还没有被合并，如果删除，将丢失掉修改，如果要强行删除，需要使用大写的-D参数。。
现在我们强行删除：
git branch -D feature-1 即可成功 团队协作
1.抓取分支：
参考 https://www.liaoxuefeng.com/w...
