廖雪峰Git学习笔记（超级无敌详细）

1. 创建仓库

版本库又名仓库,，可以看作一个目录，在这个目录里面的所有文件都可以被Git管理起来，每个文件的修改、删除，Git都能跟踪，以便任何时刻都可以追踪历史，或者在将来某个时刻可以“还原”。

1.1初始化一个Git仓库

1. 先创建一个空目录，然后在这个目录下输入git init把它变成Git可以管理的仓库。

mkdir learn //创建一个新目录
cd  learn //打开目录
pwd  //查看当前目录的位置
git init //把这个目录变成Git可以管理的仓库

1.2 添加文件到Git仓库

1. 在当前目录即learn或者其子目录下添加一个text.txt文本

gedit text.txt  //编写文档，可以随便写点英文
git add text.txt 
 //把文件提交到仓库，-m后面是本次提交的说明,也可以不加-m "xxx"不过不推荐 
git commit -m "wrote a text file" 

出现如下页面表示成功添加，1 file changed表示1个文件被改动(新添加的text.txt文件)，2 insertion插入两行内容（text.txt的两行内容），不是这个界面请看下一步

2. 若git commit -m "wrote a text file"后出现如下界面，说明没有设置账户的默认身份，
   
   需要打开创建的git文件夹，找到里面的config文件，添加你的名字和邮箱（任意）

cd .git  //打开git
gedit config  //修改config
/*
在里面添加(你的名字和邮箱)：
[user]
	email=Your email 
	name=Your Name
*/

3. commit可以一次添加很多文件，所有一次可以add很多不同的文件，比如

git add file1.txt
git add file2.txt file3.txt
git commit -m "add 3 files."

2. 时光穿梭

2.1 版本回退

1.git log显示从最近到最远的提交日志，我们可以看到2次提交，最近是 append GPL，最早的一次是wrote a readme file。

（1）可以加入--pretty=oneline输出的信息，前面一串4cc8467为commit id（版本号）

2.HEAD表示当前版本，上一个版本就是HEAD^，上上一个版本就是HEAD^^，当然往上100个版本写100个^比较容易数不过来，所以写成HEAD~100。

3.git reset指令可以回退到任一版本。如图，我们回退到上一个版本，即把当前版本append GPL回退到上一个版本wrote a readme file。这时查看text.txt文件的内容，发现确实是上一版本wrote a readme file时的内容。

这是我们再查看使用指令 git log -- pretty=oneline，可以发现append GPL已经不见了

如果又想回到这么版 这时使用git reset --hard 4cc84(根据上面提到的版本号进行查找，版本号没必要写全，前几位就可以了，Git会自动去找。当然也不能只写前一两位，因为Git可能会找到多个版本号，就无法确定是哪一个了) 。这时再去查看text.txt中的内容，发现又回到append GPL那时候的内容了。

若不记得版本号，Git提供了一个命令git reflog用来记录你的每一次命令，可以使用它进行查询，这时可以看到append GPL的版本号开头为4cc8467。

2.2 工作区和暂存区

1.在电脑上我们所能看到的文件夹就是工作区

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

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

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

3. 修改text.txt文档，并增加一个新的文档text1.txt，然后使用指令git status查看状态。text.txt被修改了，而text1.txt还从来没有被添加过，所以它的状态是未跟踪的文件。

接着使用指令git add text.txt和git add text1.txt后再执行指令git status，两个文件已经放到了暂存区。

执行指令git commit -m "understand how stage works"，把暂存区的所有修改提交到分支master，最后执行指令git status`发现已经为空。

2.3 管理修改

1.用git diff HEAD -- text.txt命令可以查看工作区和版本库里面最新版本的区别。如图所示，工作区多了一个一句my。

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

2.4 撤销修改

1.git checkout -- file可以丢弃工作区的修改，就是让这个文件回到最近一次git commit或git add时的状态。

2.如图是我text.txt里的内容，依次执行指令添加到master分支。


进行修改，添加一个my，保存但不执行 git add提交到暂存区：

执行git checkout -- file则回到最近一次git commit


3.用命令git reset HEAD <file>可以把暂存区的修改撤销掉，重新放回工作区。

（1）如图所示内容，使用指令git add提交到缓冲区，并使用指令git status查看状态。

执行指令git reset HEAD text.txt 取消暂存的更改，再次使用git statu指令，发现未提交修改至暂存区，表示撤销成功。

4.小结

（1）当你改乱了工作区某个文件的内容，想直接丢弃工作区的修改时，用命令git checkout --file。

（2）当你不但改乱了工作区某个文件的内容，还添加到了暂存区时，想丢弃修改，分两步，第一步用命令git reset HEAD <file> 回到（1），第二步按（1）操作。

（3）已经提交了不合适的修改到版本库时，想要撤销本次提交，参考版本回退一节，不过前提是没有推送到远程库。

2.5 删除文件

1.当我们把工作区文本文件使用指令rm删除后，要想删除版本库里相应的文本文件，需要两个步骤（以text.txt做为样例）：

（1）执行指令git rm text.txt
（2）执行指令git commit -m "remove test.txt"

3. 远程仓库

3.1 添加远程仓库

1. 由于比较麻烦，所以另外写了一篇博客，请点击查看

3.2 删除远程仓库

1.可使用指令git remote -v 先查看远程仓库的信息，然后确定要删除的仓库的名字，执行指令 git remote rm <仓库名>（比如仓库名为origin，则执行指令git remote rm origin）。

注意：此处的“删除”其实是解除了本地和远程的绑定关系，并不是物理上删除了远程库。远程库本身并没有任何改动。要真正删除远程库，需要登录到GitHub，在后台页面找到删除按钮再删除。

3.3 从远程仓库克隆

1. 如图，先创建一个远程仓库，命名为myclone，打勾 Add a README file，这样创建好了就会看见一个README.md文件。
   
   

2. 在Linux中使用命令git clone https://github.com/<github用户名>/<仓库名>克隆一个本地库，如图所示。
   

3. 如何查看是否克隆完成呢？使用指令 cd myclone ,然后ls，进入myclone目录发现已经有README.md文件。然后使用指令git remove -v发现确实已经连接上了。
   

4. 分支管理

分支存在的意义就是为了方便。你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作。

4.1 创建与合并分支

1.每一次提交，Git 都会把它们串成一条时间线。这条时间线就是一个分支，这个分支为主分支，即master分支。

2.HEAD严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支。Git用master指向最新的提交，再用HEAD指向master，就能确定当前分支，以及当前分支的提交点：

每次提交，master分支都会向前移动一步。随着你不断提交，master分支的线也越来越长。
3.Git创建一个分支，只需要两步。
（1）先增加一个叫dev的指针，指向master相同的提交。
（2）然后改变HEAD的指向，把HEAD指dev。

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

4.把dev合并到master上，直接把master指向dev的当前提交。

5.合并完分支后，可以删除dev分支。删除dev分支就是把dev指针给删掉，删掉后，我们就剩下了一条master分支：

4.1.1 创建分支

1.执行指令 git checkout -b dev创建分支dev，git checkout命令加上-b参数表示创建并切换。相当于两条命令，git branch dev， git checkout dev。

然后使用git branch命令查看所有分支（当前分支前面会标一个*号）。

git checkout master 命令可以切换回master分支

2.git switch -c dev命令也可以创建并切换到新的dev分支

git switch master也可以切换回master分支

4.1.2 合并分支

1.执行命令 git merge dev，把dev分支的工作成果合并到master分支上。

Fast-forward是“快进模式”合并，也就是直接把master指向dev的当前提交，所以合并速度非常快。但这种模式下，删除分支后，会丢掉分支信息。

4.1.3 删除分支

1.执行命令git branch -d dev删除分支dev。然后执行命令git branch，发现只有master分支，删除成功。

4.1.4 小结

4.2 解决冲突

1.首先我们先来一个例子，看看冲突怎么产生

（1）执行命令git branch，查看所有分支，当前分支为master。
（2）执行命令git switch dev，切换到dev分支。然后我们修改text.txt文件，并提交到当前分支。

my name is joney
joney ?

（3）然后我们切换到master分支，修改text.txt，并提交到当前分支。

my name is joney
joney ！

现在master分支和dev分支各自都分别有新的提交

这种情况下，Git无法执行“快速合并”，只能试图把各自的修改合并起来，但这种合并就可能会有冲突，如图所示：

使用git status命令也能知道冲突文件。

直接查看readme.txt的内容，Git用<<<<<<<，=======，>>>>>>>标记出不同分支的内容

修改master分支提交的内容

再次提交后合并，发现可以合并

使用指令git log --graph --pretty=oneline --abbrev-commit查看到分支的合并情况

小结：
（1）当Git无法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交，合并完成。解决冲突就是把Git合并失败的文件手动编辑为我们希望的内容，再提交。

（2）用git log --graph命令可以看到分支合并图。

4.3 分支管理策略

1.合并分支时，若使用--no-ff参数，表示禁用Fast forward，Git就会在merge时生成一个新的commit。如图我们在分支d上提交一个文件t3.txt，然后切换到master分支，使用指令git merge --no-ff -m "merge with no-ff" d合并分支，然后使用指令git log --graph --pretty=oneline --abbrev-commit查看分支历史，发现在merge时确实产生了一个新的commit。且在使用命令git branch -d d删除分支后，提交信息仍然存在。

若使用Fast forward模式，则不存在分支信息

可以看到，不使用Fast forward模式，merge后就像这样：

2.分支策略
在实际开发中，我们应该按照几个基本原则进行分支管理：

• 首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；

• 干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；

• 你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。
  

4.4 Bug分支

如果你正在dev分支工作，而master分支有需要紧急修改的Bug，则可以这样做：

• 使用git stash把当前工作现场即dev“储藏”起来。
• git checkout master切换到master分支，git checkout -b issue-101从master上创建临时分支并切换到issue-101。
• 修改完成后，git switch master回到master分支，git merge --no-ff -m "merged bug fix 101" issue-101合并分支，最后删除issue-101分支
• git stash list可以查看刚刚“储藏”起来的工作，用git stash pop恢复的同时把stash内容也删了

git stash pop(恢复删除)=git stash apply(恢复)+git stash drop(删除)

• 如果dev分支上也有相同的Bug，则可使用git cherry-pick <commit>，把bug提交的修改“复制”到当前分支，避免重复劳动。
  
  

4.5 Feature分支

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

4.6 多人协作

1.git remote查看远程仓库，git remote -v显示更详细的信息。
2.git push origin <branch-name>把该分支上的所有本地提交推送到远程库

git push origin master
git push origin dev

3.从远程库clone时，默认情况下只能看到本地的master分支。若要在dev分支上开发，就必须创建远程origin的dev分支到本地。

 git checkout -b dev origin/dev

4.如果推送失败，则因为远程分支比你的本地更新，需要先用git pull试图合并；如果合并有冲突，则解决冲突，并在本地提交；再用git push origin <branch-name>推送就能成功！
5.如果git pull提示no tracking information，则说明本地分支和远程分支的链接关系没有创建，用命令git branch --set-upstream-to <branch-name> origin/<branch-name>。

4.7 Rebase

1.git rebase操作可以把本地未push的分叉提交历史整理成直线,操作可以把本地未push的分叉提交历史整理成直线。git rebase操作前后，最终的提交内容是一致的，但是，我们本地的commit修改内容已经变化了。