Git学习笔记_gitcola教程

Git

文章是学习廖雪峰老师的Git教程做的学习笔记。

创建版本库:

git init
1

配置账号密码:

#某个版本库
git config user.name 'xxx';
git config user.email 'xxx';
#全局
git config -global user.name 'xxx';
git config -global user.email 'xxx';
1
2
3
4
5
6

添加文件:

git add <fileName>
1

查看差异:

git diff
1

查看状态:

查看哪些文件被更改

git status
1

查看提交日志：

#多行显示
git log
#单行显示
git log --pretty=oneline
1
2
3
4

版本回退：

向前

#HEAD^代表回退一个版本  
#HEAD^^代表回退两个版本
git reset --hard HEAD^
#HEAD~100 代表回退100个版本
git reset --hard HEAD~100
1
2
3
4
5

向后

#5d644代表版本commitId
git reset --hard 5d644
1
2

原理:

Git在内部有个指向当前版本的HEAD指针，当你回退版本的时候，Git仅仅是把HEAD从指向append GPL

所以你让HEAD指向哪个版本号，你就把当前版本定位在哪。

回退到了某个版本，关掉了电脑，第二天早上就后悔了，想恢复到新版本怎么办？找不到新版本的commit id怎么办？

命令记录：

#查看记录你的每一次
git reflog
1
2

版本库(Repository)和暂存区(stage)：

工作区有一个隐藏目录.git，这个不算工作区，而是Git的版本库。

Git的版本库里存了很多东西，其中最重要的就是称为stage（或者叫index）的暂存区，还有Git为我们自动创建的第一个分支master，以及指向master的一个指针叫HEAD。

git add命令实际上就是把要提交的所有修改放到暂存区（Stage），然后，执行git commit就可以一次性把暂存区的所有修改提交到分支。

一旦提交后，如果你又没有对工作区做任何修改，那么工作区就是“干净”的

可以使用git stat：us查看

管理修改

Git跟踪并管理的是修改，而非文件。新增了一行，这就是一个修改，删除了一行，也是一个修改，更改了某些字符，也是一个修改，删了一些又加了一些，也是一个修改，甚至创建一个新文件，也算一个修改。

第一次修改 -> git add -> 第二次修改 -> git commit

Git管理的是修改，当你用git add命令后，在工作区的第一次修改被放入暂存区，准备提交，但是，在工作区的第二次修改并没有放入暂存区，所以，git commit只负责把暂存区的修改提交了，也就是第一次的修改被提交了，第二次的修改不会被提交。

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

git diff HEAD -- test.txt
1

理解了Git是如何跟踪修改的，每次修改，如果不用git add到暂存区，那就不会加入到commit中。

撤销修改：

git checkout的意思就是，把文件文件在工作区的修改全部撤销。

git checkout -- 文件名
1

这里有两种情况：

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

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

就是让这个文件回到最近一次git commit或git add时的状态。

撤销暂存区：

git reset HEAD 文件名
1

git reset命令既可以回退版本，也可以把暂存区的修改回退到工作区。当我们用HEAD时，表示最新的版本。

此时文件已经从暂存区撤销了，但是在工作区有修改。再使用git checkout --文件名撤销掉工作区的修改。

删除文件：

Git中，删除也是一个修改操作。一般情况下，通常直接在文件管理器中把没用的文件删了，或者用rm命令删了，这个时候，Git知道你删除了文件，因此，工作区和版本库就不一致了，git status命令会立刻告诉你哪些文件被删除了。

在有两个选择，一是确实要从版本库中删除该文件，那就用命令git rm删掉，并且git commit；

如果commit之后发现误删了。那么可以使用git reset --hard HEAD^回退一个版本。

如果删除之后发现误删了，那可以直接使用git checkout 文件名撤销。

从来没有被添加到版本库就被删除的文件，是无法恢复的！

远程仓库：

创建SSH Key:

$ ssh-keygen -t rsa -C "邮箱@email.com"
1

添加SSH key到git服务器。将id_rsa_pub的内容粘贴到git服务器的sshkey里面

添加远程仓库：

将本地的仓库关联至远程仓库：

$ git remote add origin 地址	
1

远程库的名字默认是origin；

推送：

把本地库的内容推送到远程，用git push命令，实际上是把当前分支master推送到远程。

由于远程库是空的，我们第一次推送master分支时，加上了-u参数，Git不但会把本地的master分支内容推送的远程新的master分支，还会把本地的master分支和远程的master分支关联起来，在以后的推送或者拉取时就可以简化命令。

git push -u origin 远程分支名称
1

只要本地作了提交，就可以通过命令;

git push origin master
1

把本地master分支的最新修改推送至git服务器；

从远程仓库克隆：

用命令git clone克隆一个本地库：

git clone 地址
1

分支管理：

分支管理的实际作用：

假设准备开发一个新功能，但是需要两周才能完成，第一周写了50%的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交，又存在丢失每天进度的巨大风险。

Git的分支是与众不同的，无论创建、切换和删除分支，Git在1秒钟之内就能完成！无论你的版本库是1个文件还是1万个文件。

每次提交，Git都把它们串成一条时间线，这条时间线就是一个分支。截止到目前，只有一条时间线，在Git里，这个分支叫主分支，即master分支。HEAD严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支。

一开始的时候，master分支是一条线，Git用master指向最新的提交，再用HEAD指向master，就能确定当前分支，以及当前分支的提交点；

每次提交，master分支都会向前移动一步，这样，随着你不断提交，master分支的线也越来越长。

当我们创建新的分支，例如dev时，Git新建了一个指针叫dev，指向master相同的提交，再把HEAD指向dev，就表示当前分支在dev上。

Git创建一个分支很快，因为除了增加一个dev指针，改改HEAD的指向，工作区的文件都没有任何变化！

切换分支后，对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev指针往前移动一步，而master指针不变。

如我们在dev上的工作完成了，就可以把dev合并到master上。Git怎么合并呢？最简单的方法，就是直接把master指向dev的当前提交，就完成了合并。所以Git合并分支也很快！就改改指针，工作区内容也不变！合并完分支后，甚至可以删除dev分支。删除dev分支就是把dev指针给删掉，删掉后，我们就剩下了一条master分支：

创建分支：

git checkout -b dev
1

git checkout命令加上-b参数表示创建并切换，相当于以下两条命令：

git branch dev
git checkout dev
1
2

查看当前分支：

git branch
1

git branch命令会列出所有分支，当前分支前面会标一个*号。然后，我们就可以在dev分支上正常提交。

切换回主分支：

任务完成后切换回主分支。

git checkout master
1

分支合并到master上：

git merge命令用于合并指定分支到当前分支。

git merge dev
1

合并完成后，就可以放心地删除dev分支了。

git branch -d dev
1

switch:

切换分支使用git checkout <branch>，而前面讲过的撤销修改则是git checkout -- <file>，同一个命令，实际上，切换分支这个动作，用switch更科学。因此，最新版本的Git提供了新的git switch命令来切换分支。

创建并切换到新的dev分支，可以使用：

git switch -c dev
1

直接切换到已有的master分支，可以使用：

git switch master
1

使用git switch命令，比git checkout要更容易理解。

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如果文件存在冲突，必须手动解决冲突后再提交。git status也可以告诉我们冲突的文件；

Git用<<<<<<<，=======，>>>>>>>标记出不同分支的内容。

带参数的git log也可以看到分支的合并情况：

git log --graph --pretty=oneline --abbrev-commit
1

分支管理策略：

合并分支时，如果可能，Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。如果要强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。

git merge --no-f -m'消息' 分支名
1

使用git log --graph可以查看分支状态

git log --graph --pretty=oneline
1

分支策略:

master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；

BUG分支：

软件开发中，bug就像家常便饭一样。有了bug就需要修复，在Git中，由于分支是如此的强大，所以，每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。

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

为此Git提供了一个stash功能，可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作：

git stash
1

储藏之后就可以切回主分支，新建一个bug分支来解决bug了，解决完之后，接着到主分支就要回来接着干活了。

使用git status查看，发现工作区是干净的。那么刚刚的修改去哪了呢。

用git stash list命令查看；

git stash list
1

工作现场还在，Git把stash内容存在某个地方了，但是需要恢复一下，有两个办法：

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

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

$ git stash pop
1

命令之后，使用git status 发现工作区的东西就回来了。

再用git stash list查看。发现已经没有了。

在master分支上修复了bug后，dev分支是早期从master分支分出来的，所以，这个bug其实在当前dev分支上也存在。那怎么在dev分支上修复同样的bug？

同样的bug，要在dev上修复，我们只需要把修改bug这个提交所做的修改“复制”到dev分支。注意：我们只想复制修改bug这个提交所做的修改，并不是把整个master分支merge过来。

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

git cherry-pick commit的id
1

Git自动给dev分支做了一次提交，注意这次提交的commit是修改bug，它并不同于master的修改bug，因为这两个commit只是改动相同，但确实是两个不同的commit。用git cherry-pick，我们就不需要在dev分支上手动再把修bug的过程重复一遍。

既然可以在master分支上修复bug后，在dev分支上可以“重放”这个修复过程，那么直接在dev分支上修复bug，然后在master分支上“重放”行不行？当然可以，不过你仍然需要git stash命令保存现场，才能从dev分支切换到master分支。

Feature分支:

软件开发中，总有无穷无尽的新的功能要不断添加进来。

添加一个新功能时，肯定不希望因为一些实验性质的代码，把主分支搞乱了，所以，每添加一个新功能，最好新建一个feature分支，在上面开发，完成后，合并，最后，删除该feature分支。

模拟流程：

git switch -c feature
#开发代码

#切回dev，准备合并：
$ git switch dev
1
2
3
4
5

正常情况下，feature分支和bug分支是类似的，合并，然后删除。但是需求更改新功能必须取消！虽然白干了，但是这个包含机密资料的分支还是必须就地销毁；

$ git branch -d feature
1

销毁失败。Git提醒，feature-vulcan分支还没有被合并，如果删除，将丢失掉修改，如果要强行删除，需要使用大写的-D参数。如果要丢弃一个没有被合并过的分支，可以通过git branch -D <name>强行删除。

多人协作：

从远程仓库克隆时，实际上Git自动把本地的master分支和远程的master分支对应起来了，并且，远程仓库的默认名称是origin。

要查看远程库的信息，用git remote：

git remote
1

用git remote -v显示更详细的信息：

git remote -v
1

推送分支:

推送分支，就是把该分支上的所有本地提交推送到远程库。推送时，要指定本地分支，这样，Git就会把该分支推送到远程库对应的远程分支上：

 git push origin master
1

如果要推送其他分支，比如dev，就改成：

git push orgin dev
1

抓取分支:

多人协作时，大家都会往master和dev分支上推送各自的修改。

当你的小伙伴从远程库clone时，默认情况下，你的小伙伴只能看到本地的master分支。可以使用git branch查看，现在，你的小伙伴要在dev分支上开发，就必须创建远程origin的dev分支到本地。可以用这个命令拉取远程dev并且创建本地dev分支。

git checkout -b dev origin/dev
1

这样就可以在dev上继续修改，然后，时不时地把dev分支push到远程；

多人协作的工作模式通常是这样：

• 首先，可以试图用git push origin <branch-name>推送自己的修改；
• 如果推送失败，则因为远程分支比你的本地更新，需要先用git pull试图合并；
• 如果合并有冲突，则解决冲突，并在本地提交；
• 没有冲突或者解决掉冲突后，再用git push origin <branch-name>推送就能成功！

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

这就是多人协作的工作模式，一旦熟悉了，就非常简单。

• 查看远程库信息，使用git remote -v；
• 本地新建的分支如果不推送到远程，对其他人就是不可见的；
• 从本地推送分支，使用git push origin branch-name，如果推送失败，先用git pull抓取远程的新提交；
• 在本地创建和远程分支对应的分支，使用git checkout -b branch-name origin/branch-name，本地和远程分支的名称最好一致；
• 建立本地分支和远程分支的关联，使用git branch --set-upstream branch-name origin/branch-name；
• 从远程抓取分支，使用git pull，如果有冲突，要先处理冲突。

错误：

如我在Github新建一个仓库，写了License，然后把本地一个写了很久仓库上传。这时会发现 github 的仓库和本地的没有一个共同的 commit 所以 git 不让提交，认为是写错了 origin ，如果开发者确定是这个 origin 就可以使用 --allow-unrelated-histories 告诉 git 自己确定

遇到无法提交的问题，一般先pull 也就是使用 git pull origin master 这里的 origin 就是仓库，而 master 就是需要上传的分支，因为两个仓库不同，发现 git 输出 refusing to merge unrelated histories 无法 pull 内容

因为他们是两个不同的项目，要把两个不同的项目合并，git需要添加一句代码，在 git pull 之后，这句代码是在git 2.9.2版本发生的，最新的版本需要添加 --allow-unrelated-histories 告诉 git 允许不相关历史合并

假如我们的源是origin，分支是master，那么我们需要这样写git pull origin master --allow-unrelated-histories 如果有设置了默认上传分支就可以用下面代码

git pull --allow-unrelated-histories
1

这个方法只解决因为两个仓库有不同的开始点，也就是两个仓库没有共同的 commit 出现的无法提交。如果使用本文的方法还无法提交，需要看一下是不是发生了冲突，解决冲突再提交

Rebase:

人在同一个分支上协作时，很容易出现冲突。即使没有冲突，后push的童鞋不得不先pull，在本地合并，然后才能push成功。

查看日志：

git log --graph --pretty=oneline
1

日志看上去很乱，有强迫症的童鞋会问：为什么Git的提交历史不能是一条干净的直线？

Git有一种称为rebase的操作，当本地比远程快，并且远程已经有过提交了。我们推送时会报错，需要我们拉取之后提交，这样的话分叉就会变得很多。提交历史分叉了。

• 拉取远程commit
  • 本地commit1
  • 本地commit2
• 之前的远程commit
• 最初

这个时候，git rebase就派上了用场。原本分叉的提交现在变成一条直线了。

• 本地commit1
• 本地commit2
• 拉取远程commit
• 之前的远程commit
• 最初

原理是:

Git把我们本地的提交“挪动”了位置，放到了远程commit之后，这样，整个提交历史就成了一条直线。rebase操作前后，最终的提交内容是一致的，但是，我们本地的commit修改内容已经变化了，它们的修改不再基于最初，而是基于远程commit，但最后的提交内容是一致的。

这就是rebase操作的特点：把分叉的提交历史“整理”成一条直线，看上去更直观。缺点是本地的分叉提交已经被修改过了。

标签：

Git的标签虽然是版本库的快照，但其实它就是指向某个commit的指针（跟分支很像对不对？但是分支可以移动，标签不能移动），所以，创建和删除标签都是瞬间完成的。

Git有commit，为什么还要引入tag？

commitId不容易记。

在Git中打标签非常简单，首先，切换到需要打标签的分支上；

git tag v1.0
1

对指定提交打标签，敲入命令：

$ git tag tagName commitId
1

标签不是按时间顺序列出，而是按字母排序的。

可以用git show <tagname>查看标签信息：

git show tagName
1

还可以创建带有说明的标签，用-a指定标签名，-m指定说明文字：

git tag -a v1.0 -m'我是v1.0的说明文字' commmitId
1

删除tag:

git tag -d v1.0
1

因为创建的标签都只存储在本地，不会自动推送到远程。所以，打错的标签可以在本地安全删除。

如果要推送某个标签到远程，使用命令git push origin <tagname>

git push origin v1.0
1

一次性推送全部尚未推送到远程的本地标签：

git push origin --tags
1

如果标签已经推送到远程，要删除远程标签就麻烦一点，先从本地删除：

 git tag -d v1.0
1

然后，从远程删除。删除命令也是push，但是格式如下：

git push origin :refs/tags/v1.0
1