git学习

我们会先了解一些版本控制工具的历史背景，然后试着让 Git 在你的系统上跑起来，直到最后配置好，可以正常开始开发工作。读完本章，你就会明白为什么 Git 会如此流行，为什么你应该立即开始使用它。

 

1.1 关于版本控制

什么是版本控制？我真的需要吗？版本控制是一种记录若干文件内容变化，以便将来查阅特定版本修订情况的系统。在本书所展示的例子中，我们仅对保存着软件源代码的文本文件作版本控制管理，但实际上，你可以对任何类型的文件进行版本控制。

如果你是位图形或网页设计师，可能会需要保存某一幅图片或页面布局文件的所有修订版本（这或许是你非常渴望拥有的功能）。采用版本控制系统 （VCS）是个明智的选择。有了它你就可以将某个文件回溯到之前的状态，甚至将整个项目都回退到过去某个时间点的状态。你可以比较文件的变化细节，查出最 后是谁修改了哪个地方，从而导致出现怪异问题，又是谁在何时报告了某个功能缺陷等等。使用版本控制系统通常还意味着，就算你乱来一气把整个项目中的文件改 的改删的删，你也照样可以轻松恢复到原先的样子。但额外增加的工作量却微乎其微。

本地版本控制系统

许多人习惯用复制整个项目目录的方式来保存不同的版本，或许还会改名加上备份时间以示区别。这么做唯一的好处就是简单。不过坏处也不少：有时候会混淆所在的工作目录，一旦弄错文件丢了数据就没法撤销恢复。

为了解决这个问题，人们很久以前就开发了许多种本地版本控制系统，大多都是采用某种简单的数据库来记录文件的历次更新差异（见图 1-1）。

图 1-1. 本地版本控制系统

其中最流行的一种叫做 rcs，现今许多计算机系统上都还看得到它的踪影。甚至在流行的 Mac OS X 系统上安装了开发者工具包之后，也可以使用 rcs 命令。它的工作原理基本上就是保存并管理文件补丁（patch）。文件补丁是一种特定格式的文本文件，记录着对应文件修订前后的内容变化。所以，根据每次 修订后的补丁，rcs 可以通过不断打补丁，计算出各个版本的文件内容。

集中化的版本控制系统

接下来人们又遇到一个问题，如何让在不同系统上的开发者协同工作？于是，集中化的版本控制系统（ Centralized Version Control Systems，简称 CVCS ）应运而生。这类系统，诸如 CVS，Subversion 以及 Perforce 等，都有一个单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新。多年以来，这 已成为版本控制系统的标准做法（见图 1-2）。

图 1-2. 集中化的版本控制系统

这种做法带来了许多好处，特别是相较于老式的本地 VCS 来说。现在，每个人都可以在一定程度上看到项目中的其他人正在做些什么。而管理员也可以轻松掌控每个开发者的权限，并且管理一个 CVCS 要远比在各个客户端上维护本地数据库来得轻松容易。

事分两面，有好有坏。这么做最显而易见的缺点是中央服务器的单点故障。如果宕机一小时，那么在这一小时内，谁都无法提交更新，也就无法协同工作。要 是中央服务器的磁盘发生故障，碰巧没做备份，或者备份不够及时，就还是会有丢失数据的风险。最坏的情况是彻底丢失整个项目的所有历史更改记录，而被客户端 提取出来的某些快照数据除外，但这样的话依然是个问题，你不能保证所有的数据都已经有人事先完整提取出来过。本地版本控制系统也存在类似问题，只要整个项 目的历史记录被保存在单一位置，就有丢失所有历史更新记录的风险。

分布式版本控制系统

于是分布式版本控制系统（ Distributed Version Control System，简称 DVCS ）面世了。在这类系统中，像 Git，Mercurial，Bazaar 以及 Darcs 等，客户端并不只提取最新版本的文件快照，而是把原始的代码仓库完整地镜像下来。这么一来，任何一处协同工作用的服务器发生故障，事后都可以用任何一个镜 像出来的本地仓库恢复。因为每一次的提取操作，实际上都是一次对代码仓库的完整备份（见图 1-3）。

图 1-3. 分布式版本控制系统

更进一步，许多这类系统都可以指定和若干不同的远端代码仓库进行交互。籍此，你就可以在同一个项目中，分别和不同工作小组的人相互协作。你可以根据需要设定不同的协作流程，比如层次模型式的工作流，而这在以前的集中式系统中是无法实现的。

 

 

1.2 Git 简史

同生活中的许多伟大事件一样，Git 诞生于一个极富纷争大举创新的年代。Linux 内核开源项目有着为数众广的参与者。绝大多数的 Linux 内核维护工作都花在了提交补丁和保存归档的繁琐事务上（1991－2002年间）。到 2002 年，整个项目组开始启用分布式版本控制系统 BitKeeper 来管理和维护代码。

到了 2005 年，开发 BitKeeper 的商业公司同 Linux 内核开源社区的合作关系结束，他们收回了免费使用 BitKeeper 的权力。这就迫使 Linux 开源社区（特别是 Linux 的缔造者 Linus Torvalds ）不得不吸取教训，只有开发一套属于自己的版本控制系统才不至于重蹈覆辙。他们对新的系统制订了若干目标：

* 速度 * 简单的设计 * 对非线性开发模式的强力支持（允许上千个并行开发的分支） * 完全分布式 * 有能力高效管理类似 Linux 内核一样的超大规模项目（速度和数据量）

自诞生于 2005 年以来，Git 日臻成熟完善，在高度易用的同时，仍然保留着初期设定的目标。它的速度飞快，极其适合管理大项目，它还有着令人难以置信的非线性分支管理系统（见第三章），可以应付各种复杂的项目开发需求。

 

 

 

1.3 Git 基础

那么，简单地说，Git 究竟是怎样的一个系统呢？请注意，接下来的内容非常重要，若是理解了 Git 的思想和基本工作原理，用起来就会知其所以然，游刃有余。在开始学习 Git 的时候，请不要尝试把各种概念和其他版本控制系统（诸如 Subversion 和 Perforce 等）相比拟，否则容易混淆每个操作的实际意义。Git 在保存和处理各种信息的时候，虽然操作起来的命令形式非常相近，但它与其他版本控制系统的做法颇为不同。理解这些差异将有助于你准确地使用 Git 提供的各种工具。

直接记录快照，而非差异比较

Git 和其他版本控制系统的主要差别在于，Git 只关心文件数据的整体是否发生变化，而大多数其他系统则只关心文件内容的具体差异。这类系统 （CVS，Subversion，Perforce，Bazaar 等等）每次记录有哪些文件作了更新，以及都更新了哪些行的什么内容，请看图 1-4。

图 1-4. 其他系统在每个版本中记录着各个文件的具体差异

Git 并不保存这些前后变化的差异数据。实际上，Git 更像是把变化的文件作快照后，记录在一个微型的文件系统中。每次提交更新时，它会纵览一遍所有文件的指纹信息并对文件作一快照，然后保存一个指向这次快照 的索引。为提高性能，若文件没有变化，Git 不会再次保存，而只对上次保存的快照作一链接。Git 的工作方式就像图 1-5 所示。

图 1-5. Git 保存每次更新时的文件快照

这是 Git 同其他系统的重要区别。它完全颠覆了传统版本控制的套路，并对各个环节的实现方式作了新的设计。Git 更像是个小型的文件系统，但它同时还提供了许多以此为基础的超强工具，而不只是一个简单的 VCS。稍后在第三章讨论 Git 分支管理的时候，我们会再看看这样的设计究竟会带来哪些好处。

近乎所有操作都是本地执行

在 Git 中的绝大多数操作都只需要访问本地文件和资源，不用连网。但如果用 CVCS 的话，差不多所有操作都需要连接网络。因为 Git 在本地磁盘上就保存着所有当前项目的历史更新，所以处理起来速度飞快。

举个例子，如果要浏览项目的历史更新摘要，Git 不用跑到外面的服务器上去取数据回来，而直接从本地数据库读取后展示给你看。所以任何时候你都可以马上翻阅，无需等待。如果想要看当前版本的文件和一个月 前的版本之间有何差异，Git 会取出一个月前的快照和当前文件作一次差异运算，而不用请求远程服务器来做这件事，或是把老版本的文件拉到本地来作比较。

用 CVCS 的话，没有网络或者断开 V*N 你就无法做任何事情。但用 Git 的话，就算你在飞机或者火车上，都可以非常愉快地频繁提交更新，等到了有网络的时候再上传到远程仓库。同样，在回家的路上，不用连接 V*N 你也可以继续工作。换作其他版本控制系统，这么做几乎不可能，抑或非常麻烦。比如 Perforce，如果不连到服务器，几乎什么都做不了（译注：默认无法发出命令p4 edit file 开始编辑文件，因为 Perforce 需要联网通知系统声明该文件正在被谁修订。但实际上手工修改文件权限可以绕过这个限制，只是完成后还是无法提交更新。）；如果是 Subversion 或 CVS，虽然可以编辑文件，但无法提交更新，因为数据库在网络上。看上去好像这些都不是什么大问题，但实际体验过之后，你就会惊喜地发现，这其实是会带来很大不同的。

时刻保持数据完整性

在保存到 Git 之前，所有数据都要进行内容的校验和（checksum）计算，并将此结果作为数据的唯一标识和索引。换句话说，不可能在你修改了文件或目录之后，Git 一无所知。这项特性作为 Git 的设计哲学，建在整体架构的最底层。所以如果文件在传输时变得不完整，或者磁盘损坏导致文件数据缺失，Git 都能立即察觉。

Git 使用 SHA-1 算法计算数据的校验和，通过对文件的内容或目录的结构计算出一个 SHA-1 哈希值，作为指纹字符串。该字串由 40 个十六进制字符（0-9 及 a-f）组成，看起来就像是：

24b9da6552252987aa493b52f8696cd6d3b00373

Git 的工作完全依赖于这类指纹字串，所以你会经常看到这样的哈希值。实际上，所有保存在 Git 数据库中的东西都是用此哈希值来作索引的，而不是靠文件名。

多数操作仅添加数据

常用的 Git 操作大多仅仅是把数据添加到数据库。因为任何一种不可逆的操作，比如删除数据，都会使回退或重现历史版本变得困难重重。在别的 VCS 中，若还未提交更新，就有可能丢失或者混淆一些修改的内容，但在 Git 里，一旦提交快照之后就完全不用担心丢失数据，特别是养成定期推送到其他仓库的习惯的话。

这种高可靠性令我们的开发工作安心不少，尽管去做各种试验性的尝试好了，再怎样也不会弄丢数据。至于 Git 内部究竟是如何保存和恢复数据的，我们会在第九章讨论 Git 内部原理时再作详述。

文件的三种状态

好，现在请注意，接下来要讲的概念非常重要。对于任何一个文件，在 Git 内都只有三种状态：已提交（committed），已修改（modified）和已暂存（staged）。已提交表示该文件已经被安全地保存在本地数据库 中了；已修改表示修改了某个文件，但还没有提交保存；已暂存表示把已修改的文件放在下次提交时要保存的清单中。

由此我们看到 Git 管理项目时，文件流转的三个工作区域：Git 的工作目录，暂存区域，以及本地仓库。

图 1-6. 工作目录，暂存区域，以及本地仓库

每个项目都有一个 Git 目录（译注：如果 git clone 出来的话，就是其中 .git 的目录；如果git clone --bare 的话，新建的目录本身就是 Git 目录。），它是 Git 用来保存元数据和对象数据库的地方。该目录非常重要，每次克隆镜像仓库的时候，实际拷贝的就是这个目录里面的数据。

从项目中取出某个版本的所有文件和目录，用以开始后续工作的叫做工作目录。这些文件实际上都是从 Git 目录中的压缩对象数据库中提取出来的，接下来就可以在工作目录中对这些文件进行编辑。

所谓的暂存区域只不过是个简单的文件，一般都放在 Git 目录中。有时候人们会把这个文件叫做索引文件，不过标准说法还是叫暂存区域。

基本的 Git 工作流程如下：

1. 在工作目录中修改某些文件。 2. 对修改后的文件进行快照，然后保存到暂存区域。 3. 提交更新，将保存在暂存区域的文件快照永久转储到 Git 目录中。

所以，我们可以从文件所处的位置来判断状态：如果是 Git 目录中保存着的特定版本文件，就属于已提交状态；如果作了修改并已放入暂存区域，就属于已暂存状态；如果自上次取出后，作了修改但还没有放到暂存区域，就 是已修改状态。到第二章的时候，我们会进一步了解其中细节，并学会如何根据文件状态实施后续操作，以及怎样跳过暂存直接提交。

 

二、常用的git命令

--文件目录操作命令

1 mkdir *   创建一个空目录 *指目录名
2 pwd       显示当前目录的路径。
3 cat *     查看*文件内容
4 git rm *  删除**文件

 

--git初始化操作

1 git init                   把当前的目录变成git仓库，生成隐藏.git文件。
2 git remote add origin url  把本地仓库的内容推送到GitHub仓库。
3 git clone git@url/test.git 从远程库克隆
4 git add *                  把x文件添加到暂存区去。
5 git commit –m "*"          提交文件 –m 后面的是注释。   

 

--git 克隆分支

1 git clone xxx.git                最简单直接的命令
2 git clone xxx.git "指定目录"      clone到指定目录
3 git clone -b branchname xxx.git  clone时创建新的分支替代默认Origin HEAD（master）

 

--clone 远程分支

　　git clone 命令默认的只会建立master分支，如果你想clone指定的某一远程分支(如：dev)的话，可以如下：

　　1. 查看所有分支(包括隐藏的)  git branch -a 显示所有分支　　　　

1 * master
2   remotes/origin/HEAD -> origin/master
3   remotes/origin/dev
4   remotes/origin/master

　　2. 在本地新建同名的("dev")分支，并切换到该分支

1 git checkout -t origin/dev 该命令等同于：
2 git checkout -b dev origin/dev

 

--查看命令

1 git status        查看仓库状态
2 git diff  *       查看X文件修改了那些内容   
3 git log           查看历史记录
4 git reflog        查看历史记录的版本号id（记录你的每一次命令,不论是否提交）
5 git log --pretty=oneline 如果信息量太多可以进行比较好的列表显示   

 

--版本回退

1 git reset –hard HEAD^       回退到上一个版本
2 git reset --hard HEAD~第几个 如果想回退到第3个版本，使用git reset –hard HEAD~3
3 git reset --hard 057d       回退到某一个具体的版本号

 

--撤销修改

1  git checkout file-name 恢复某个已修改的文件（撤销未提交的修改）：
2  git revert HEAD        还原最近一次提交的修改：
3  git revert commit-id   还原指定版本的修改

 

--分支管理

 1 git branch                   查看本地所有的分支
 2 git branch -a                查看远程所有的分支
 3 git branch name              创建分支
 4 git branch –d dev            删除dev分支
 5 git push origin --delete dev 删除远程的dev分支
 6 git branch -m dev develop    重命名分支

 7 git checkout –b dev          创建dev分支 并切换到dev分支上
 8 git merge dev                在当前分支上合并dev分支代
 9 git push origin zyf-dev      把当前新疆的zyf-dev分支推送到远程库(远程仓库没有给分支则会新建立该分支)
 
10 git checkout — *                     把XX文件在工作区的修改全部撤销。
11 git checkout master                  切换回master分支
12 git push --set-upstream origin dev   提交修改并创建远程分支dev

 

--tag相关操作

1 git tag         列出所有的tag
2 git tag name    打轻量标签 name
3 git tag -d name 删除本地的tag
4 git push origin --delete tag name  删除远程的tag
5 git show name        查看tag信息
6 git push origin name 将tag提交到远程

 

--隐藏的文件

1 git stash       把当前的工作隐藏起来 等以后恢复现场后继续工作
2 git stash list  查看所有被隐藏的文件列表
3 git stash apply 恢复被隐藏的文件，但是内容不删除
4 git stash drop  删除文件
5 git stash pop   恢复文件的同时 也删除文件

 

--查看远程库信息(git  remote的用法) 

1 git remote       查看远程库的信息
2 git remote –v    查看远程库的详细信息
3 git remote add  name url          添加远程仓库
4 git remote rename oldname newname 重命名仓库
5 git remote rm                     删除仓库

 

--将远程分支拉取到本地

1 方法一：git checkout -b 本地分支名x origin/远程分支名x
2 方式二：git fetch origin 远程分支名x:本地分支名x

 

--git pull操作

 1 git pull命令的作用是，取回远程主机某个分支的更新，再与本地的指定分支合并，基本的格式如下。
 2 $ git pull <远程主机名> <远程分支名>:<本地分支名>
 3 
 4 取回origin主机的next分支，与本地的master分支合并，需要写成下面这样
 5 $ git pull origin next:master
 6 
 7 如果远程分支是与当前分支合并，则冒号后面的部分可以省略。
 8 $ git pull origin next
 9 
10 上面命令表示，取回origin/next分支，再与当前分支合并。实质上，这等同于先做git fetch，再做git merge。
11 $ git fetch origin
12 $ git merge origin/next
13 
14 在某些场合，Git会自动在本地分支与远程分支之间，建立一种追踪关系(tracking)。比如，在git clone的时候，所有本地分支默认与远程主机的同名分支，建立追踪关系，也就是说，本地的master分支自动”追踪”origin/master分支。
15 Git也允许手动建立追踪关系。
16 git branch --set-upstream master origin/next
17 
18 上面命令指定master分支追踪origin/next分支。如果当前分支与远程分支存在追踪关系，git pull就可以省略远程分支名。
19 $ git pull origin

 

--git 设置大小写敏感

Windows上的Git默认是大小写不敏感的，这样多平台写作就可能会出现问题。Win上的Git设置为大小写敏感的命令如下

1 git config core.ignorecase false  

 

--git 设置忽略文件或文件夹权限修改

1 git config core.filemode false

 

--创建追踪分支

不带任何参数的git push，默认只推送当前分支，这叫做simple方式。此外，还有一种matching方式，会推送所有有对应的远程分支的本地分支。Git 2.0版本之前，默认采用matching方法，现在改为默认采用simple方式。如果要修改这个设置，可以采用git config命令。

$ git config --global push.default matching
# 或者
$ git config --global push.default simple (最好使用这种方式)

  $ git branch --track  master origin/master //在使用 git branch 命令时加上 '--track' 参数, 来手动创建一个追踪分支

 

--切换git 命令提示中文到英文

// ubuntu装的git不知道怎么就出现全中文的提示,不太好,果断切换到中文了,切换方法如下:
// 1:写入
echo "alias git='LANG=en_GB git'" >> ~/.bashrc

// 2:生效
source ~/.bashrc

 

--git 删除未添加到版本中的文件或者文件夹

git checkout 只能回退在版本中的修改或者删除, 对于新添加的文件是没有作用的, 也就是说, 新建的文件或者文件夹是:Untracked files, 要删除或者清理掉这些文件,需要使用 git clean 命令:

 1 // 删除 untracked files
 2 git clean -f
 3  
 4 // 连 untracked 的目录也一起删掉
 5 git clean -fd
 6  
 7 // 连 gitignore的untrack 文件/目录也一起删掉 （一般这个是用来删掉编译出来的 .o一类的文件）
 8 git clean -xfd
 9  
10 // 在使用清理 git clean之前，建议加上 -n 来先看看会删掉哪些文件，防止重要文件被误删
11 git clean -nxfd
12 git clean -nf
13 git clean -nfd

三、常出错误：
1：There is no tracking information for the current branch...
    则说明本地分?支和远程分?支的链接关系没有创建，用命令：
    git branch --set-upstream branch-name origin/branch-name。

2: ![rejected] dev -> dev (non-fast-forward)  ... Updates were rejected because the tip of your current branch
    推送失败，因为远程代码的最新提交和你试图推送的提交有冲突，解决办法也很简单，先用git pull把最新的提交从origin/dev抓下来，然后，在本地合并，解决冲突，再推送
    
3：CONFLICT (content): Merge conflict in . . .
    这回git pull成功，但是合并有冲突，需要手动解决，解决的方法和分支管理中的解决冲突一样。解决后，提交，再push：
    
4: You are not currently on a branch, so I cannot use any
   解决办法：git checkout master

5：Your branch is behind 'origin/master' by 1 commit, and can be fast-forwarded.
   上面的显示的意思是，有一个更新还没有反应到本地来，可能是别人往server上提交了一点东西。 
   可以使用git pull命令拿这些更新到本地来。

 

6：在执行 git push 时可能会看到如下消息: 

warning: push.default is unset; its implicit value is changing in
Git 2.0 from 'matching' to 'simple'. To squelch this message
and maintain the current behavior after the default changes, use:
git config --global push.default matching
To squelch this message and adopt the new behavior now, use:
  git config --global push.default simpl

  解决办法：‘matching’ 参数是 Git 1.x 的默认行为，如果你执行 git push 但没有指定分支，它将 push 所有你本地的分支到远程仓库中对应匹配的分支。而 Git 2.x 默认的是 simple，意味着执行 git push 没有指定分支时，只有当前分支会被 push 到你使用 git pull 获取的代码。 
根据提示，修改git push:

1 git config --global push.default matching

再次执行git push 就行了。

 

7：You asked to pull from the remote 'origin', but did not specify:a branch. Because this is not the default configured remotefor your current branch, you must specify a branch on the command line.

解决办法：找到：.git/config  修改如下

1 [branch "master"]
2   remote = origin
3   merge = refs/heads/master

 

8：ERROR: Permission to user1/test.git denied to user2   fatal: The remote end hung up unexpectedly

　账户冲突，下面有针对讲解

 

9: 添加的ssh不起作用？

   ssh 的添加一定要在root用户权限在添加，其他的权限不起作用，切记！

四、经验之谈：
1：git revert 和 git reset的区别 
开始感觉两者一样，但是在客户端和命令行窗口操作之后发现大大的不同，看一个例子：我先提交三次1,2,3 id号分别是（15d5f70,a167eb1,8fbfe3f）如下图

然后执行版本回退 git reset –hard a167 如图：

说明执行git reset –hard ** 版本回退是撤销某次提交，但是此次之后的修改都会被退回到暂存区，因为上面显示有提交（by 1 commit）
同理执行 git revert –hard a167
git revert是用一次新的commit来回滚之前的commit
　　在回滚操作上看，效果一样。但是在日后继续merge以前的老版本时有区别。revert是用一次逆向的commit“中和”之前的提交，因此日后合并老的branch时，导致这部分改变不会再次出现，但是reset是之间把某些commit在某个branch上删除，因而和老的branch再次merge时，这些被回滚的commit应该还会被引入。 
得到结论：git reset 是把HEAD向后移动了一下，而git revert是HEAD继续前进，
只是新的commit的内容和要revert的内容正好相反，能够抵消要被revert的内容。

　　这样在版本回退的时候就比较的好，比如本地dev分支，远程master分支，某一次的上线发现线上有重大的bug，然后你reset本地代码到前一个版本，在你git push 的时候git会报一个错误：“说你的本地分支版本低于远程master分支的版本，让你先去pull 下来代码，再提交”，这就不行了，你pull下来的代码还是最新版有bug的代码，不进行pull代码，master分支又不让你提交。解决这个问题还得使用 revert 来进行 “回退”操作，为什么加引号呢，是因为这种回退是向前提交一次中和了上次的修改，这就比较好了，这样你revert之后相当于指针向前移动一次，本地版本dev高于远程master版本，这时你就可以git push 本地代码到远程了。也就是说，git reset 对未提交到（git push）远程的修改做回滚比较好，如果要回滚本地，同时想远程也回滚，就要用到revert

五、常用修改：
1：避免每次提交都输入用户名和密码
    原因是使用了https方式 puh 在termail里边 输入  git remote -v 可以看到形如一下的返回结果
    origin https://github.com/git/librarysystem.git(fetch)
    origin https://github.com/git/librarysystem.git(push)
    下面把它换成ssh方式的。

1. git remote rm origin
2. git remote add origin git@github.com:yu/demo.git
3. git push origin 

2：添加忽略文件 .gitignore 
    .gitignore配置文件用于配置不需要加入版本管理的文件。
    配置语法： "/"  开头表示目录；  "*"  通配多个字符；  "?"  通配单个字符   "[]" 包含单个字符的匹配列表；  "!"  表示不忽略(跟踪)匹配到的文件或目录；
    说明：git 对于 .ignore 配置文件是按行从上到下进行规则匹配的，意味着如果前面的规则匹配的范围更大，则后面的规则将不会生效；
    示例：（1） foder/*     忽略目录foder下的全部内容,不管是根目录下的 /foder/ 目录，还是某个子目录 /list/foder/ 目录，都会被忽略。
    　　   （2） /foder/*   说明：忽略根目录下的 /foder/ 目录的全部内容；
    　　   （3） /*!.gitignore
                          !/fw/bin/
                          !/fw/sf/
                          说明：忽略全部内容，但是不忽略 .gitignore文件,根目录下的 /fw/bin/ 和 /fw/sf/ 
    注意问题： .gitignore文件只对还没有加入版本管理的文件起作用，如果之前已经用git把要忽略的文件纳入了版本库，就不起作用了。

3：如何在同一台电脑上使用两个git账户

　　问题描述：作为程序员有时候是有多个的项目，而且每个项目git的用户名，邮箱等，都不一样。就我来说，我在github上有一个账号，自己开发一些东西，同时我参与的也有项目需要连接别人的github账号，在我电脑上只有一个git客户端，本地一个身份用户，开始的时候我自己开发是用ssh方式，参与的项目的是用https连接，但是https每次都需要输入密码，非常不方便，所以想转成ssh连接，利用命令：
>$ git remote rm origin
>$ git remote add origin git@github.com:yu/demo.git 
>$ git push origin       
转换成功，不幸的是push的时候出错了：ERROR: Permission to user1 denied to
这种情况的解决方式是方法，使用本地托管多个个ssh的密钥，不同的账号是用不同的密匙。
第一步：生成SSH Key

执行命令，如下图：

具体说明：

1 $ ssh-keygen -t rsa -C "your_email@youremail.com"
2   Creates a new ssh key using the provided email Generating public/private rsa key pair.
3   #输入将要保存的路径，我的默认为当前路径（/c/Users/zhaoyafei/.ssh/id_rsa）,但是不能使用默认文件id_rsa，要添加新账户就要生起一个成新的好记的名字，例如id_rsa_work
4   Enter file in which to save the key (/c/Users/zhaoyafei/.ssh/id_rsa):
5   #输入回车后提示输入一个类似于密码的号，直接回车就行
6   Enter passphrase (empty for no passphrase):
7   Enter same passphrase again:

第二步：识别新的私钥
    默认SSH只会读取id_rsa，所以为了让SSH识别新的私钥，需要将其添加到SSH agent　　

1 ssh-add ～/.ssh/id_rsa_work
2  //该命令如果报错：Could not open a connection to your authentication agent.可执行 ssh-agent bash 命令后再执行ssh-add -l 看是否成功。

执行命令，如下图：

 

第三步：修改config文件
    该文件用于配置私钥对应的服务器。内容如下:

 1 # Default github （默认的）
 2       Host github.com
 3       HostName github.com
 4       User git
 5       IdentityFile ~/.ssh/id_rsa
 6 
 7 # second user(work@gmail.com)
 8       Host github_work
 9       HostName github.com
10       User git
11       IdentityFile ~/.ssh/id_rsa_work

       这样配置，也就是使用hostname为github.com会根据用户名的不同，去使用不用的private key。github上，也可以添加对应的公钥。其实这个配置是关于ssh的与git无关，只是git使用的方式是ssh的方式。Host可随意，方便自己记忆，后续在添加remote是还需要用到。

第四步：将SSH key输入到GitHub网站中    
      将生成的id_rsa_work.pub输入到GitHub网站中就可以了，输入完成后单击Add key后，会看到git-tutorial已经被添加进去了。 配置完成后，在连接非默认帐号的github仓库时，远程库的地址要对应地做一些修改，比如现在添加abc帐号下的一个仓库test，则需要这样添加：git remote add test git@github-work:abc/test.git #并非原来的git@github.com:abc/test.git 这样每次连接都会使用id_rsa_abc与服务器进行连接。

　　注意：github根据配置文件的user.email来获取github帐号显示author信息，所以对于多帐号用户一定要记得将user.email改为相应的email(work@mail.com)。我遇到的问题是本地单一用户，链接不同的github账号，所以用户配置可以采用全局配置。如果不同本地用户（不同的身份标识，即需要本地使用不同的用户名），那么git就不要使用有–global的配置，可以按照下面的方法：

1 1)设置局部的user.name和user.email
2     git config user.name "xxxxxx"
3     git config user.email "xxx@xxx.com"
4 2)设置全局的user.name和user.email
5     git config --global user.name "xxxxxx"
6     git config –-global user.email ""