git基本命令及常见处理文件问题
基本的拉取上传文件命令
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 更加清楚明了的查看
ps:关联远程库后，使用命令git push -u origin master第一次推送master分支的所有内容；
此后，每次本地提交后，只要有必要，就可以使用命令git push origin master推送最新修改；
Git是跟踪修改的，每次修改，如果不用git add到暂存区，那就不会加入到commit中。
用git diff HEAD – qq.html命令可以查看工作区和版本库里面最新版本的区别
常用基本命令
- git diff 提交文件之前可用此命令查看文件被修改了哪些
- git log 上传文件后 可查看提交的历史信息
git log --pretty=oneline --abbrev-commit 找到历史提交的commit id
git log --graph 查看到分支合并图。或者git log --graph --pretty=oneline --abbrev-commit - git reset --hard HEAD^ 回退到上一个版本
–hard - git reset --hard 09BH(历史版本16进制的前四位即可，git自动找) 回到指定版本
如果关闭了git窗口 可使用git reflog命令查看之间提交的版本
git rebase --onto cbe8527^ cbe8527 删除某次提交
5.cat op.html 或者git show 查看文件内容 - git checkout – qq.html 或者 git restore op.html 把qq.html文件在工作区的修改全部撤销，这里有两种情况：
(1)一种是 qq.html自修改后还没有被放到暂存区，现在，撤销修改就回到和版本库一模一样的状态；
(2)一种是 qq.htmlt已经添加到暂存区后，又作了修改，现在，撤销修改就回到添加到暂存区后的状态。 - git diff HEAD – qq.html 查看工作区和版本库里面最新版本的区别
- 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 <tagname>用于新建一个标签，默认为HEAD，也可以指定一个commit id；
命令git tag -a <tagname> -m "blablabla..."可以指定标签信息；
命令git tag可以查看所有标签
13.git commit --amend 修改最后一次提交的注释
https://www.jianshu.com/p/098d85a58bf1分支及基本处理
- git checkout -b dev 创建dev分支，然后切换到dev分支 或者 git switch -b dev
-b参数表示创建并切换
相当于这两条命令：
git branch dev
git checkout dev - git branch 查看当前分支; 查看已有的本地及远程分支： git branch -a
- 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 等不能操作文件？
分支管理策略
通常，合并分支时，如果可能，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分支上新建一个提交节点，从而完成合并
- 因为本次合并要创建一个新的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}
- 在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 命令，把bug提交的修改“复制”到当前分支，避免重复劳动。
Feature分支
添加一个新功能时，我们为了不打乱主分支master,所以在我们当前分支上（dev）新建分支
- 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/wiki/896043488029600/900375748016320