<h2>根本的拉取上传文件命令</h2>
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命令能够查看工作区和版本库外面最新版本的区别
<h2>罕用根本命令</h2>
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^ 回退到上一个版本 --hard4. 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 <file> 能够把暂存区的批改撤销掉），从新放回工作区， 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 <tagname>用于新建一个标签，默认为HEAD，也能够指定一个commit id； 命令git tag -a <tagname> -m "blablabla..."能够指定标签信息； 命令git tag能够查看所有标签 13.git commit --amend 批改最初一次提交的正文 https://www.jianshu.com/p/098d85a58bf1<h2>分支及根本解决</h2>
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 <name>切换分支：git checkout <name>或者git switch <name>创立+切换分支：git checkout -b <name>或者git switch -c <name>拉去近程分支：git fetch origin dev（dev为近程仓库的分支名）合并某分支到以后分支：git merge <name>删除本地分支：git branch -d <name>; 删除近程分支：git push origin --delete dev<h2>解决常见问题</h2>
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...
解决：这种谬误阐明无权限操作文件，敞开掉编辑器及代码运行器即可
<h2>分支管理策略</h2>
通常，合并分支时，如果可能，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合并就看不出来已经做过合并。
<h2>Bug分支</h2>
团队合作中，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 <commit>命令，把bug提交的批改“复制”到以后分支，防止重复劳动。
<h2>Feature分支</h2>
增加一个新性能时，咱们为了不打乱主分支master,所以在咱们以后分支上（dev）新建分支
1. git switch -c feature-1 新建分支写性能2.git add <file>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 即可胜利<h2>团队合作</h2>
1.抓取分支：
参考 https://www.liaoxuefeng.com/w...