共计 6287 个字符，预计需要花费 16 分钟才能阅读完成。
<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^ 回退到上一个版本
--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 <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…