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

这个是广大网友评为最浅显易懂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
忽略⽂件的原则是:

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

⼩结

  1. 忽略某些⽂件时,需要编写.gitignore。
  1. .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配置好别名,就可以输⼊命令时偷个懒。我们⿎励偷懒。


最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,456评论 5 477
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,370评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,337评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,583评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,596评论 5 365
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,572评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,936评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,595评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,850评论 1 297
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,601评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,685评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,371评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,951评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,934评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,167评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 43,636评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,411评论 2 342

推荐阅读更多精彩内容