git基本命令及常见处理文件问题

基本的拉取上传文件命令

0.git pull先更新文件; git status  查看文件的增删改状态
1.git clone 在线库存地址;   git clone -b  dev(远程分支)  连接
2.git add 要提交的文件或者文件夹    或者git add .(表示提交全部修改过的文件，添加到暂存区)

注：git add 只将新建的或者已更改的文件添加到索引区。（不会添加删除的文件）
3.git commit -m '备注';提交到暂存区  -m(默认为master分支)
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命令能够查看工做区和版本库里面最新版本的区别

经常使用基本命令

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命令查看之间提交的版本
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> 能够把暂存区的修改撤销掉），从新放回工做区
8.git reflog 查看命令历史，以便肯定要回到将来的哪一个版本。
9. git rm qq.html  删除文件
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能够查看全部标签
复制代码

分支及基本处理

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 merge <name>
删除本地分支：git branch -d <name>; 删除远程分支：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分支

分支管理策略

一般，合并分支时，若是可能，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 命令，把bug提交的修改“复制”到当前分支，避免重复劳动。

Feature分支

添加一个新功能时，咱们为了避免打乱主分支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  便可成功
复制代码

团队协做

1.抓取分支： 参考 https://www.liaoxuefeng.com/wiki/896043488029600/900375748016320