Git学习笔记

安装完成设置，“自报家门”： 

git config --global user.name "Your Name"
git config --global user.email "email@example.com"

创建版本库(git仓库)：

git init

 添加文件到仓库：

git add <file>
git commit -m <message>

查看仓库当前状态，可输出被修改过但未提交的文件：

git status // 查看哪些文件被修改过
git diff // 查看修改的内容
git log // 查看每次修改的时间和内容 包含commit id、Author、Date、操作，字母q退出查看

git中用HEAD表示当前版本，HEAD^上一个版本，HEAD~100上100个版本，版本回退：

git reset --hard <commit id> // 改变HEAD指针指向

如果想回到未来，使用：

git reflog // 查看命令历史以确定版本号

工作区与暂存区：工作区包含版本库，版本库有个暂存区stage，其次git自动创建第一个分支master，指针HEAD指向master。git add实际上是将改动添加到暂存区，使用git commit一次性将所有改动提交到当前分支。

查看工作区和版本库里面最新版本的区别：

git diff HEAD -- <file>

 撤销文件在工作区的修改：

git checkout -- <file>

这里有两种情况：

一种是file自修改后还没有被放到暂存区，现在，撤销修改就回到和版本库一模一样的状态；

一种是file已经添加到暂存区后，又作了修改，现在，撤销修改就回到添加到暂存区后的状态。

如果是第二种，使用以下指令把暂存区的修改撤销掉，重新放回工作区：

git reset HEAD <file>

然后再丢弃工作区的修改：git checkout -- <file>

删除提交的文件：

本地工作区删除：

rm <file>

此时，工作区与版本库不一致，用git status查看。

1.如果确实要删除该文件，则在版本库中继续删除：

git rm <file>
git commit -m "remove file"

2.如果误删工作区文件，则用版本库里的版本替换工作区的版本：

git checkout -- <file>

查看所有分支：

git branch

创建分支：

git checkout -b dev
// -b表示新建并切换到新分支dev，相当于：
git branch dev
git checkout dev
或者使用：
git switch -c dev 
<==>
git branch dev
git switch dev

这样就可以在新分支提交代码，然后再融合到master分支上。

合并分支：

git checkout master // 切换回master分支
git merge dev // 合并

 合并分支时，加上--no-ff参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并，而fast forward合并就看不出来曾经做过合并。

git merge --no-ff -m "merge with no-ff" dev

 删除分支：

git branch -d dev

查看分支合并图：

git log --graph

Bug分支：

当你接到一个修复一个代号101的bug的任务时，很自然地，你想创建一个分支issue-101来修复它，但是当前正在dev上进行的工作还没有提交，并不是你不想提交，而是工作只进行到一半，还没法提交，预计完成还需1天时间。但是，必须在两个小时内修复该bug，怎么办？

存储工作现场：

git stash

然后切回master分支，创建新分支处理bug，修复完成后回到dev分支：git checkout dev

然后恢复现场：

一是用git stash apply恢复，但是恢复后，stash内容并不删除，你需要用git stash drop来删除；

另一种方式是用git stash pop，恢复的同时把stash内容也删了

可使用git stash list查看存储的现场。

恢复指定的现场：

一是用git stash apply恢复，但是恢复后，stash内容并不删除，你需要用git stash drop来删除；

另一种方式是用git stash pop，恢复的同时把stash内容也删了

在master分支上修复了bug后，我们要想一想，dev分支是早期从master分支分出来的，所以，这个bug其实在当前dev分支上也存在。同样的bug，要在dev上修复，我们只需要把fix bug 101这个提交所做的修改“复制”到dev分支。注意：我们只想复制fix bug 101这个提交所做的修改，并不是把整个master分支merge过来。

为了方便操作，Git专门提供了一个cherry-pick命令，让我们能复制一个特定的提交到当前分支：

git cherry-pick <commit id>

feature分支： 

开发一个新feature，最好新建一个分支；

如果要丢弃一个没有被合并过的分支，可以通过git branch -D <name>强行删除。

多人协作：https://www.liaoxuefeng.com/wiki/896043488029600/900375748016320

查看远程库的信息，远程库默认名origin：

git remote -v

推送分支：推送分支，就是把该分支上的所有本地提交推送到远程库。

git push origin master

但是，并不是一定要把本地分支往远程推送，那么，哪些分支需要推送，哪些不需要呢？

• master分支是主分支，因此要时刻与远程同步；

• dev分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步；

• bug分支只用于在本地修复bug，就没必要推到远程了，除非老板要看看你每周到底修复了几个bug；

• feature分支是否推到远程，取决于你是否和你的小伙伴合作在上面开发。

抓取分支：

当你的小伙伴从远程库clone时，默认情况下，你的小伙伴只能看到本地的master分支。不信可以用git branch命令看看：

$ git branch
* master

现在，你的小伙伴要在dev分支上开发，就必须创建远程origin的dev分支到本地，于是他用这个命令创建本地dev分支：

git checkout -b dev origin/dev

 多人协作的工作模式：

1. 首先，可以试图用git push origin <branch-name>推送自己的修改；

2. 如果推送失败，则因为远程分支比你的本地更新，需要先用git pull试图合并；

3. 如果合并有冲突，则解决冲突，并在本地提交；

4. 没有冲突或者解决掉冲突后，再用git push origin <branch-name>推送就能成功！

如果git pull提示no tracking information，则说明本地分支和远程分支的链接关系没有创建，用命令git branch --set-upstream-to <branch-name> origin/<branch-name>。