最浅显易懂Git教程的读书笔记(附下载链接)

作者: wg689 | 来源:发表于2016-10-27 21:02 被阅读500次

这个是广大网友评为最浅显易懂Git教程的读书笔记, 这个PDF文档CSDN可以免积分下载.建议大家看看这个文档,这个文档内容不多不少,值得推荐,不讲SVN和git 的区别,直奔主题.
史上最浅显易懂的gif教程下载链接

创建版本库

什么是版本库呢？版本库⼜名仓库，英⽂名repository，你可以简单理解成⼀个目录，这个目录里面的所有文件都可以被Git管理起来，每个⽂件的修改、删除，Git都能跟踪，以便任何时刻都可以追踪历史，或者在将来某个时刻可以“还原”。所以，创建一个版本库非常简单，⾸先，选择一个合适的地方，创建一个空目录：

wanggangdeMacBook-Pro:~ wanggang$ mkdir learngit
mkdir: learngit: File exists
wanggangdeMacBook-Pro:~ wanggang$ cd learngit
wanggangdeMacBook-Pro:learngit wanggang$ pwd
/Users/wanggang/learngit
wanggangdeMacBook-Pro:learngit wanggang$

第二步，通过git init命令把这个目录变成Git可以管理的仓库：

wanggangdeMacBook-Pro:learngit wanggang$ git init
Reinitialized existing Git repository in /Users/wanggang/learngit/.git/
wanggangdeMacBook-Pro:learngit wanggang$

把⽂件添加到版本库

所有的版本控制系统，其实只能跟踪文本文件的改动，比如TXT⽂件，网页，所有的程序代码等等，Git也不例外。(版本控制不是啥都能管理)

wanggangdeMacBook-Pro:learngit wanggang$ git commit -m "wrote a readme file"
On branch master
nothing to commit, working directory clean

没有东西可以提交,是因为已经提交了

小结

现在总结一下学的两点内容：
初始化一个Git仓库，使⽤用git init命令。
添加⽂文件到Git仓库，分两步：
• 第一步，使⽤用命令git add ，注意，可反复多次使用，添加多个文件；
• 第二步，使⽤用命令git commit，完成。

时光机穿梭篇

我们已经成功地添加并提交了一个readme.md文件，现在，是时候继续工作了，于是，我们继续修改readme.md⽂件，改成如下内容：

Git is a distributed version control system.
Git is free software.```
现在，运⾏行git status命令看看结果：

wanggangdeMacBook-Pro:learngit wanggang$ git status
On branch master
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)

modified:   readme.md

no changes added to commit (use "git add" and/or "git commit -a")

``git status``命令可以让我们时刻掌握仓库当前的状态，上面的命令告诉我们，readme.txt被改过了，但还没有准备提交的修改。
虽然Git告诉我们readme.md被修改了，但如果能看看具体修改了什么内容，自然是很好的。需要⽤用``git diff``这个命令看看

wanggangdeMacBook-Pro:learngit wanggang$ git diff
diff --git a/readme.md b/readme.md
index ffb8757..8fd0008 100644
--- a/readme.md
+++ b/readme.md
@@ -1,3 +1,7 @@
Git is a version control system.
Git is free software
second

+Git is a distributed version control system.
+Git is free software.
\\\\\\\\ No newline at end of file
wanggangdeMacBook-Pro:learngit wanggang$

   "+" 代表增加了,
添加和查看命令

wanggangdeMacBook-Pro:learngit wanggang$ git add readme.md
wanggangdeMacBook-Pro:learngit wanggang$ git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)

modified:   readme.md

wanggangdeMacBook-Pro:learngit wanggang$

提交命令``git commit -m "add distributed"``

wanggangdeMacBook-Pro:learngit wanggang$ git commit -m "add distributed"
[master c9ce0cc] add distributed
1 file changed, 4 insertions(+)
wanggangdeMacBook-Pro:learngit wanggang$

执行git status,告诉在分支上,没有什么可以提交了,⽽且，⼯作目录是干净（working directory
clean）的。

wanggangdeMacBook-Pro:learngit wanggang$ git status
On branch master
nothing to commit, working directory clean

##⼩结

>• 要随时掌握工作区的状态，使⽤用git status命令。
• 如果git status告诉你有文件被修改过，用git diff可以查看修改内容。

#版本回退
现在，你已经学会了修改文件，然后把修改提交到Git版本库，现在，再练习一次，修改readme.txt⽂文件如下：

Git is a distributed version control system.
Git is free software distributed under the GPL.```
然后尝试提交：

wanggangdeMacBook-Pro:learngit wanggang$ git add readme.md
wanggangdeMacBook-Pro:learngit wanggang$ git commit -m "append GPL"
[master 9a3a214] append GPL
 1 file changed, 3 insertions(+), 1 deletion(-)
wanggangdeMacBook-Pro:learngit wanggang$

git log命令查看提交日志,最近三次的

wanggangdeMacBook-Pro:learngit wanggang$ git log
commit 9a3a214e5d3a2161025b4c3a5555770240bbdb17
Author: wg689 <596201463@qq.com>
Date:   Thu Oct 27 15:04:25 2016 +0800

    append GPL

commit c9ce0cc9a33c89a7484b65ff15d677ec26427d3d
Author: wg689 <596201463@qq.com>
Date:   Thu Oct 27 14:58:57 2016 +0800

    add distributed

commit 2655435b11464bb99561a5cfb3e9dea879824178
Author: wg689 <596201463@qq.com>
Date:   Wed Oct 26 17:17:41 2016 +0800

    add distributed

commit 668d6ddb994231947d1fa5b199c61eda1d2fbca0
Author: hjl_wg <wanggang@wanggangdeMacBook-Pro.local>
Date:   Wed Oct 26 17:04:29 2016 +0800

    wrote a readme fiel
:

如果嫌输出信息太多，看得眼花缭乱的，可以试试加上
--pretty=oneline参数：

wanggangdeMacBook-Pro:learngit wanggang$ git log --pretty=oneline
9a3a214e5d3a2161025b4c3a5555770240bbdb17 append GPL
c9ce0cc9a33c89a7484b65ff15d677ec26427d3d add distributed
2655435b11464bb99561a5cfb3e9dea879824178 add distributed
668d6ddb994231947d1fa5b199c61eda1d2fbca0 wrote a readme fiel

好了，现在我们启动时光穿梭机，准备把readme.md回退到上⼀个版本，也就是“add distributed”的那个版本，怎么做呢？
首先，Git必须知道当前版本是哪个版本，在Git中，用HEAD表⽰当前版本，也就是最新的提交“ 3628164...882e1e0”（注意我的提交ID和你的肯定不一样），上一个版本就是HEAD^{，上上一个版本就是HEAD}^，当然往上100 个版本写100个^⽐比较容易数不过来，所以写成HEAD~100。现在，我们要把当前版本“append GPL”回退到上⼀个版本“add distributed”，就可以使⽤用git reset命令：git reset --hard HEAD^

wanggangdeMacBook-Pro:learngit wanggang$ git reset --hard HEAD^
HEAD is now at c9ce0cc add distributed
wanggangdeMacBook-Pro:learngit wanggang$ git log --pretty=oneline
c9ce0cc9a33c89a7484b65ff15d677ec26427d3d add distributed
2655435b11464bb99561a5cfb3e9dea879824178 add distributed
668d6ddb994231947d1fa5b199c61eda1d2fbca0 wrote a readme fiel

和上文比较知道回退版本成功.
3628164...”，于是就可以指定回到未来的某个版本：

$ git reset --hard 9a3a214e5d
HEAD is now at 3628164 append GPL

版本号没必要写全，前几位就可以了，Git会⾃动去找。当然也不能只写前一两位，因为Git可能会找到多个版本号，就⽆法确定是哪一个了。使用回到某一个版本可以回到任意版本.

wanggangdeMacBook-Pro:learngit wanggang$ git log --pretty=oneline
9a3a214e5d3a2161025b4c3a5555770240bbdb17 append GPL
c9ce0cc9a33c89a7484b65ff15d677ec26427d3d add distributed
2655435b11464bb99561a5cfb3e9dea879824178 add distributed
668d6ddb994231947d1fa5b199c61eda1d2fbca0 wrote a readme fiel

Git的版本回退速度非常快，因为Git在内部有个指向当前版本的HEAD指针，当你回退版本的时候，Git仅仅是把HEAD从指向“append GPL”改一下：
git reflog 会记录最近的每一次id

wanggangdeMacBook-Pro:learngit wanggang$ git reflog
9a3a214 HEAD@{0}: reset: moving to 9a3a214e5d
c9ce0cc HEAD@{1}: reset: moving to HEAD^
9a3a214 HEAD@{2}: commit: append GPL
c9ce0cc HEAD@{3}: commit: add distributed
2655435 HEAD@{4}: commit: add distributed
668d6dd HEAD@{5}: commit (initial): wrote a readme fiel
wanggangdeMacBook-Pro:learngit wanggang$

⼩结

现在总结⼀一下：
• HEAD指向的版本就是当前版本，因此，Git允许我们在版本的历史之间穿梭，使⽤命令git reset --hard commit_id。
• 穿梭前，用git log可以查看提交历史，以便确定要回退到哪个版本。
• 要重返未来，用git reflog查看命令历史，以便确定要回到未来的哪个版本。

工作区和暂存区

Git和其他版本控制系统如SVN的⼀个不同之处就是有暂存区的概念。
先来看名词解释。
工作区（Working Directory）：就是你在电脑⾥里能看到的目录，⽐如我的learngit文件夹

就是⼀个⼯作区：
版本库（Repository）：工作区有一个隐藏目录“.git”，这个不算工作区，⽽是Git的版本库。
Git的版本库⾥里存了很多东西，其中最重要的就是称为stage（或者叫index）的暂存区，还有Git为我们自动创建的第一个分支master，以及指向master的⼀个指针叫HEAD。

分⽀和HEAD的概念我们以后再讲。
前面讲了我们把⽂件往Git版本库里添加的时候，是分两步执行的：
第一步是用“git add”把文件添加进去，实际上就是把文件修改添加到暂存区；
第二步是用“git commit”提交更改，实际上就是把暂存区的所有内容提交到当前分支。
因为我们创建Git版本库时，Git⾃动为我们创建了唯一个master分支，所以，现在，
commit就是往master分支上提交更改。
你可以简单理解为，需要提交的⽂件修改通通放到暂存区，然后，一次性提交暂存区的所有修改。

小结

暂存区是Git非常重要的概念，弄明⽩了暂存区，就弄明白了Git的很多操作到底干了什么。
没弄明白暂存区是怎么回事的童鞋，请向上滚动⻚面，再看一次。

撤销修改,撤销没有add 的修改

wanggangdeMacBook-Pro:learngit wanggang$ git checkout -- readme.md

命令git checkout -- readme.txt意思就是，把readme.txt文件在工作区的修改全部撤销，这
⾥里有两种情况：

一种是readme.txt自修改后还没有被放到暂存区，现在，撤销修改就回到和版本库一模一样的状态；
一种是readme.txt已经添加到暂存区后，又作了修改，现在，撤销修改就回到添加到暂存区后的状态。
总之，就是让这个⽂件回到最近一次git commit或git add时的状态。

小结

场景1：当你改乱了工作区某个⽂件的内容，想直接丢弃工作区的修改时，用命令gitcheckout -- file。

场景2：当你不但改乱了⼯作区某个⽂件的内容，还添加到了暂存区时，想丢弃修改，分两
步，第⼀步⽤用命令git reset HEAD file，就回到了场景1，第二步按场景1操作。

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

删除文件

wanggangdeMacBook-Pro:learngit wanggang$ rm test.md
wanggangdeMacBook-Pro:learngit wanggang$ git status
On branch master
Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    deleted:    test.md

no changes added to commit (use "git add" and/or "git commit -a")
wanggangdeMacBook-Pro:learngit wanggang$ git rm test.md
rm 'test.md'
wanggangdeMacBook-Pro:learngit wanggang$ git commit -m "remove test.md"
[master 67a3a8a] remove test.md
 1 file changed, 9 deletions(-)
 delete mode 100644 test.md
wanggangdeMacBook-Pro:learngit wanggang$ git status
On branch master
nothing to commit, working directory clean
wanggangdeMacBook-Pro:learngit wanggang$ git checkout -- test.md
error: pathspec 'test.md' did not match any file(s) known to git.
wanggangdeMacBook-Pro:learngit wanggang$

小结

命令git rm用于删除一个⽂件。如果一个⽂件已经被提交到版本库，那么你永远不用担心误删，但是要小心，你只能恢复文件到最新版本，你会丢失最近一次提交后你修改的内容

远程仓库

为什么GitHub需要SSH Key呢？因为GitHub需要识别出你推送的提交确实是你推送的，⽽不是别⼈人冒充的，⽽Git⽀支持SSH协议，所以，GitHub只要知道了你的公钥，就可以确认只有你自⼰才能推送。当然，GitHub允许你添加多个Key。假定你有若干电脑，你一会⼉在公司提交，一会儿在家里提交，只要把每台电脑的Key都添加到GitHub,就可以在每台电脑上往GitHub推送了。

分支

分⽀在实际中有什么⽤呢？假设你准备开发一个新功能，但是需要两周才能完成，第一周你写了50%的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再⼀次提交，⼜存在丢失每天进度的巨⼤⻛险。现在有了分支，就不⽤用怕了。你创建了一个属于你⾃己的分⽀，别⼈看不到，还继续在原来的分支上正常⼯作，⽽你在⾃己的分⽀上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分⽀上，这样，既安全，⼜不影响别⼈工作。其他版本控制系统如SVN等都有分支管理，但是用过之后你会发现，这些版本控制系统创建和切换分⽀比蜗⽜牛还慢，简直让⼈无法忍受，结果分支功能成了摆设，大家都不去⽤。
但Git的分⽀是与众不同的，无论创建、切换和删除分支，Git在1秒钟之内就能完成！无论你的版本库是1个文件还是1万个文件。

创建与合并分支

截⽌到目前，只有⼀条时间线，在Git里，这个分支叫主分支，即 master分⽀。HEAD严格来说不是指向提交，⽽是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支。

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

Snip20161027_21.png

每次提交，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分⽀,

真是太神奇了，你看得出来有些提交是通过分支完成的吗？
下⾯开始实战。
首先，我们创建dev分支，然后切换到dev分支：

wanggangdeMacBook-Pro:learngit wanggang$ git checkout -b dev
Switched to a new branch 'dev'

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

$ git branch dev
$ git checkout dev
Switched to branch 'dev'

然后，用git branch命令查看当前分支：

wanggangdeMacBook-Pro:learngit wanggang$ git branch
* dev
  master

git branch命令会列出所有分支，当前分支前面会标一个*号。

wanggangdeMacBook-Pro:learngit wanggang$ git add readme.md
wanggangdeMacBook-Pro:learngit wanggang$ git commit -m "branch master"
[dev 565ba8c] branch master
 1 file changed, 2 insertions(+), 1 deletion(-)
wanggangdeMacBook-Pro:learngit wanggang$

现在，dev分支的⼯作完成，我们就可以切换回master分支：

wanggangdeMacBook-Pro:learngit wanggang$ git checkout master
Switched to branch 'master'
wanggangdeMacBook-Pro:learngit wanggang$

切换回master分⽀后，再查看⼀个readme.txt⽂件，刚才添加的内容不见了！因为那个提
交是在dev分⽀上，⽽master分⽀此刻的提交点并没有变：

现在，我们把dev分支的工作成果合并到master分支上：

wanggangdeMacBook-Pro:learngit wanggang$ git merge dev
Updating 67a3a8a..565ba8c
Fast-forward
 readme.md | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
wanggangdeMacBook-Pro:learngit wanggang$

git merge命令⽤用于合并指定分⽀到当前分支。合并后，再查看readme.txt的内容，就可以看到，和dev分支的最新提交是完全⼀样的。
注意到上面的Fast-forward信息，Git告诉我们，这次合并是“快进模式”，也就是直接把
master指向dev的当前提交，所以合并速度⾮非常快。
当然，也不是每次合并都能Fast-forward，我们后⾯面会将其他⽅式的合并。
合并完成后，就可以放心地删除dev分支了,删除后，查看branch，就只剩下master分支了：

wanggangdeMacBook-Pro:learngit wanggang$ git branch -d dev
Deleted branch dev (was 565ba8c).
wanggangdeMacBook-Pro:learngit wanggang$ git branch
* master

因为创建、合并和删除分⽀非常快，所以Git⿎鼓励你使用分支完成某个任务，合并后再删掉
分⽀，这和直接在master分⽀上⼯作效果是一样的，但过程更安全。

小结

Git⿎鼓励⼤大量使⽤用分支：

查看分⽀：git branch
创建分⽀：git branch name
切换分⽀：git checkout name
创建+切换分支：git checkout -b name
合并某分⽀到当前分支：git merge name
删除分⽀：git branch -d name

解决冲突

⼈生不如意之事⼗之八九，合并分⽀往往也不是⼀帆风顺的。准备新的feature1分支，继续我们的新分支开发：

$ git checkout -b feature1
Switched to a new branch 'feature1'

修改readme.txt最后一行，改为：
Creating a new branch is quick AND simple.
在feature1分支上提交：

$ git add readme.txt
$ git commit -m "AND simple"
[feature1 75a857c] AND simple
1 file changed, 1 insertion(+), 1 deletion(-)

切换到master分支：

$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 1 commit.

现在，master分支和feature1分支各自都分别有新的提交，变成了这样：

Snip20161027_28.png

这种情况下，Git⽆法执⾏“快速合并”，只能试图把各自的修改合并起来，但这种合并就可能会有冲突，我们试试看：

wanggangdeMacBook-Pro:learngit wanggang$ git merge feature1
Auto-merging readme.md
CONFLICT (content): Merge conflict in readme.md
Automatic merge failed; fix conflicts and then commit the result.
wanggangdeMacBook-Pro:learngit wanggang$

使用git status 查看

wanggangdeMacBook-Pro:learngit wanggang$ git status
On branch master
You have unmerged paths.
  (fix conflicts and run "git commit")

Unmerged paths:
  (use "git add <file>..." to mark resolution)

    both modified:   readme.md

no changes added to commit (use "git add" and/or "git commit -a")
wanggangdeMacBook-Pro:learngit wanggang$

手动解决冲突,重新add 和commit

wanggangdeMacBook-Pro:learngit wanggang$ git add readme.md
wanggangdeMacBook-Pro:learngit wanggang$ git commit -m "conflict fixed"
[master edce57e] conflict fixed
wanggangdeMacBook-Pro:learngit wanggang$

现在，master分⽀和feature1分⽀变成了下图所⽰：

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

*   edce57e conflict fixed
|\\\\\\\\\\\\\\\\  
| * 7c57d7e and simple
* | 5b95acb & simple
|/  
* 565ba8c branch master
* 67a3a8a remove test.md
* e3b271f add text.md
* 9a3a214 append GPL
* c9ce0cc add distributed
* 2655435 add distributed
* 668d6dd wrote a readme fiel
wanggangdeMacBook-Pro:learngit wanggang$

现在，删除feature1分支：并且查看分支

wanggangdeMacBook-Pro:learngit wanggang$ git branch -d feature1
Deleted branch feature1 (was 7c57d7e).
wanggangdeMacBook-Pro:learngit wanggang$ git branch
* master

小结

当Git⽆法⾃动合并分⽀时，就必须首先解决冲突。解决冲突后，再提交，合并完成。用git log --graph命令可以看到分支合并图。

分支管理策略

通常，合并分⽀时，如果可能，Git会⽤用“Fast forward”模式，但这种模式下，删除分⽀后，会丢掉分支信息。如果要强制禁⽤用“Fast forward”模式，Git就会在merge时⽣生成一个新的commit，这样，从分⽀历史上就可以看出分支信息。
下⾯我们实战一下--no-ff⽅方式的merge：
首先，仍然创建并切换dev分支：

wanggangdeMacBook-Pro:learngit wanggang$ git checkout -b dev
Switched to a new branch 'dev'
wanggangdeMacBook-Pro:learngit wanggang$

修改readme.txt文件，并提交⼀个新的commit：

wanggangdeMacBook-Pro:learngit wanggang$ git add readme.md
wanggangdeMacBook-Pro:learngit wanggang$ git commit -m "add merge"
[dev bdda8f5] add merge
 1 file changed, 1 insertion(+)

现在，我们切换回master：

wanggangdeMacBook-Pro:learngit wanggang$ git checkout master
Switched to branch 'master'

准备合并dev分⽀，请注意--no-ff参数，表⽰示禁用“Fast forward”：

wanggangdeMacBook-Pro:learngit wanggang$ git merge --no-ff -m "merge with no-ff" dev
Merge made by the 'recursive' strategy.
 readme.md | 1 +
 1 file changed, 1 insertion(+)

因为本次合并要创建一个新的commit，所以加上-m参数，把commit描述写进去。
合并后，我们⽤git log看看分支历史：

wanggangdeMacBook-Pro:learngit wanggang$ git log --graph --pretty=oneline --abbrev-commit
*   f76bb6f merge with no-ff
|\\\\\\\\\\\\\\\\  
| * bdda8f5 add merge
|/  
*   edce57e conflict fixed
|\\\\\\\\\\\\\\\\  
| * 7c57d7e and simple
* | 5b95acb & simple
|/  
* 565ba8c branch master
* 67a3a8a remove test.md
* e3b271f add text.md
* 9a3a214 append GPL
* c9ce0cc add distributed
* 2655435 add distributed
* 668d6dd wrote a readme fiel

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

Snip20161027_30.png

分支策略

在实际开发中，我们应该按照⼏个基本原则进⾏分⽀管理：
⾸先，master分支应该是⾮常稳定的，也就是仅⽤用来发布新版本，平时不能在上⾯干活；
那在哪干活呢？干活都在dev分⽀上，也就是说，dev分支是不稳定的，到某个时候，比如
1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；
你和你的⼩伙伴们每个⼈都在dev分⽀上干活，每个人都有自己的支，时不时地往dev分
⽀上合并就可以了。所以，团队合作的分支看起来就像这样：

小结

Git分⽀⼗分强⼤，在团队开发中应该充分应⽤用。
合并分支时，加上--no-ff参数就可以⽤用普通模式合并，合并后的历史有分支，能看出来曾经
做过合并，⽽而fast forward合并就看不出来曾经做过合并。

bug 分支

软件开发中，bug就像家常便饭⼀一样。有了bug就需要修复，在Git中，由于分支是如此的强⼤，所以，每个bug都可以通过⼀一个新的临时分支来修复，修复后，合并分支，然后将临
时分支删除。当你接到⼀个修复一个代号101的bug的任务时，很⾃然地，你想创建⼀个分⽀支issue -101来
修复它，但是，等等，当前正在dev上进⾏行的工作还没有提交.修改了仓库,git stash 暂存起来

wanggangdeMacBook-Pro:learngit wanggang$ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   readme.md

no changes added to commit (use "git add" and/or "git commit -a")
wanggangdeMacBook-Pro:learngit wanggang$ git stash
Saved working directory and index state WIP on master: f76bb6f merge with no-ff
HEAD is now at f76bb6f merge with no-ff
wanggangdeMacBook-Pro:learngit wanggang$

现在，用git status查看⼯作区，就是干净的（除⾮有没有被Git管理的文件），因此可以放⼼地创建分支来修复bug。
⾸先确定要在哪个分⽀上修复bug，假定需要在master分支上修复，就从master创建临时分支：

wanggangdeMacBook-Pro:learngit wanggang$ git checkout master
Already on 'master'
wanggangdeMacBook-Pro:learngit wanggang$ git checkout -b issue-101
Switched to a new branch 'issue-101'

现在修复bug，需要把“Git is free software ...”改为“Git is a free software ...”，然后
提交：

feature 分支

软件开发中，总有⽆穷无尽的新的功能要不断添加进来。
添加一个新功能时，你肯定不希望因为一些实验性质的代码，把主分支搞乱了，所以，每添加一个新功能，最好新建一个feature分⽀，在上面开发，完成后，合并，最后，删除该feature分⽀支。现在，你终于接到了⼀个新任务：开发代号为Vulcan的新功能，该功能计划⽤用于下⼀代星际⻜飞船。于是准备开发：

wanggangdeMacBook-Pro:learngit wanggang$ git checkout -b feature-vulcan
M   readme.md
Switched to a new branch 'feature-vulcan'

小结

开发⼀个新feature，最好新建⼀一个分支；
如果要丢弃⼀一个没有被合并过的分⽀，可以通过git branch -D name强⾏删除。

多人协作

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

忽略特殊⽂文件

有些时候，你必须把某些⽂件放到Git⼯作⽬录中，但⼜不能提交它们，⽐如保存了数据库密码的配置⽂件啦，等等，每次git status都会显⽰“Untracked files ...”，有强迫症的童
鞋⼼⾥里肯定不爽。好在Git考虑到了大家的感受，这个问题解决起来也很简单，在Git⼯工作区的根目录下创建一个特殊的.gitignore⽂件，然后把要忽略的文件名填进去，Git就会⾃自动忽略这些⽂件。不需要从头写.gitignore文件，GitHub已经为我们准备了各种配置文件，只需要组合一下就
可以使用了。所有配置⽂件可以直接在线浏览：https://github.com/github/gitignore
忽略⽂件的原则是：

忽略操作系统⾃动⽣成的文件，比如缩略图等；
忽略编译生成的中间文件、可执⾏文件等，也就是如果一个⽂件是通过另一个文件自动生成的，那自动生成文件就没必要放进版本库，⽐如Java编译产生的.class文
件；
忽略你⾃己的带有敏感信息的配置文件，⽐如存放口令的配置文件。
举个例子：
假设你在Windows下进行Python开发，Windows会⾃自动在有图片的目录下⽣成隐藏的缩略图文件，如果有⾃定义目录，目录下就会有Desktop.ini文件，因此你需要忽略Windows自
动生成的垃圾文件：

⼩结

忽略某些⽂件时，需要编写.gitignore。

.gitignore文件本⾝身要放到版本库里，并且可以对.gitignore做版本管理！

配置别名

有没有经常敲错命令？⽐如git status？status这个单词真心不好记。
如果敲git st就表⽰示git status那就简单多了，当然这种偷懒的办法我们是极⼒力赞成的。
我们只需要敲⼀行命令，告诉Git，以后st就表示status：
$ git config --global alias.st status
好了，现在敲git st看看效果。
当然还有别的命令可以简写，很多人都用co表⽰示checkout，ci表⽰示commit，br表⽰示
branch：

$ git config --global alias.co checkout
$ git config --global alias.ci commit
$ git config --global alias.br branch
以后提交就可以简写成：
$ git ci -m "bala bala bala..."

--global参数是全局参数，也就是这些命令在这台电脑的所有Git仓库下都有用。
在撤销修改⼀节中，我们知道，命令git reset HEAD file可以把暂存区的修改撤销掉
（unstage），重新放回工作区。既然是一个unstage操作，就可以配置⼀个unstage别
名：
$ git config --global alias.unstage 'reset HEAD'
当你敲入命令：
$ git unstage test.py
实际上Git执行的是：
$ git reset HEAD test.py

小结

给Git配置好别名，就可以输⼊命令时偷个懒。我们⿎励偷懒。

作者开发经验总结的文章推荐,持续更新学习心得笔记
Runtime 10种用法（没有比这更全的了
 成为iOS顶尖高手，你必须来这里(这里有最好的开源项目和文章)
iOS逆向Reveal查看任意app 的界面
 JSPatch （实时修复App Store bug）学习(一)
iOS 高级工程师是怎么进阶的(补充版20+点)
扩大按钮(UIButton)点击范围(随意方向扩展哦)
最简单的免证书真机调试(原创)
通过分析微信app,学学如何使用@2x,@3x图片
 TableView之MVVM与MVC之对比
 使用MVVM减少控制器代码实战(减少56%)
ReactiveCocoa添加cocoapods 配置图文教程及坑总结

最浅显易懂Git教程的读书笔记(附下载链接)

创建版本库

把⽂件添加到版本库

小结

时光机穿梭篇

⼩结

工作区和暂存区

小结

撤销修改,撤销没有add 的修改

小结

删除文件

小结

远程仓库

分支

创建与合并分支

小结

解决冲突

小结

分支管理策略

分支策略

小结

bug 分支

feature 分支

小结

多人协作

忽略特殊⽂文件

⼩结

配置别名

小结

相关文章

网友评论

延伸阅读

深度阅读

栏目导航

热点阅读

首页投稿（暂停使用，暂停投稿）

iOS Developer

计算机技术一锅炖