GIT入门篇-基本概念与操作 - 推酷
GIT入门篇-基本概念与操作
首先必须说明的是, 这篇文章不是阐述GIT原理性和比较深入的文章。只是对于日常开发中比较常用的需求的总结和GIT 这些命令大体的原理解释。所以掌握这个只能说能够应付一定的开发需求。但是如果你是个追求极值和完美的人。应该 再去了解下GIT具体的模型和实现细节。需要说明的是, 技术性东西，得先入门再深入理论，这很重要，入门可以让你不断 的进行实践，加深理解，而不是纸上谈兵，看着理论无从下手。 GIT的应用我们主要掌握GIT中团队开发协助的常用命令和 场景 。在这之前，我们需要先介绍一些必备概念。
A、基本概念
一、Repository
repository, 使用过SVN的应该都知道，这是版本库。何为版本库，简单理解就是用来存储和检索数据的一个仓库，只不过我们 用它来存储代码，来实现团队开发中的代码共享，以此来实现协同工作。简单的所就是用来保证，一个软件项目中的代码同步。
在GIT中的版本库一般有两个, 一个是本地版本库，一个是服务器版本库(共享版本库)。这是因为GIT本身就是设计为非集中式(分布式) 版本控制器，其优点就是，当你没有网络的时候，你不用依赖于服务器版本库(共享版本库)。想一下，你使用SVN的时候， 可以不用联网吗？如果希望一个项目交由GIT来管理，那么应该再该项目所在的同级目录中有一个.GIT文件夹，该文件夹里存放的就是 本地版本库，这时候，当你没有网络的时候，可以在本地进行版本管理。再有网络连接时候, 再将本地版本库与共享版本库进行同步。
在GIT中，我们使用 git init 命令来创建初始化一个版本库。其会自动生产.GIT文件夹和对应的文件，这时候就能用GIT进行版本管理。 git init --bare 用在(共享版本库中)，因为在共享版本库中, 我们不需要工程文件夹(即工作空间), 因为共享版本库，相当于一个存放 代码的服务器，不需要工作空间。
1.git init用在我们本地工作空间中需要进行管理的项目中。
2.git init --bare用在创建共享版本库，用来于本地版本库进行同步，实现多人开发的版本库。
二、工作区
所谓的工作区, 就是你项目所在的文件夹里，都可以统称为工作区。
三、暂存区(stage、index)
该区域是用来保存要提交到本地版本库中的所有文件, 称为stage或index。当执行 git commit 指令时候，会一次性将该区域类的文件提交到 本地版本库。可以理解为相当于一个缓存区，用来缓存要交给本地版本库管理的文件。而要将文件加入暂存区域，需要 使用git add指令进行添加操作。也就是说要提交到本地版本库需要两步操作: git add + git commit 。执行完这两条只是提交到了本地版本库， 只能自己来使用，要是在团队开发中，要需要执行git push提交到共享版本库.
四、HEAD指针
简而言之，这里的HEAD指针就是一个用来标识当前所在的版本。也就是我们是通过HEAD所指向的版本来确定 当前所在的版本，所以当我们进行版本切换的时候，进行的就是改变HEAD指针的指向。
B、基本操作
由GIT的模型我们知道，要交给本地仓库管理，我们必须先将其提交到stage中。再又stage提交到本地版本库中，我将这步操作归纳为增。以此来 于数据库中的增概念类比，方便学习。所以我们这里所谓的增加细分而来个分为向stage中增加，和向本地版本库中增加。需要明确的是本地版本库 的增, 是依赖于stage中的。具体的例子演示。
由于我们要模拟多人开发，所以先完成以下的准备工作。
1.创建一个SWPTest文件夹，我们准备在该文件夹中创建A用户的工作空间，和共享代码库。
执行如下操作
mkdir SWPTest
cd SWPTest/
mkdir AWorker sharedRep
2.创建共享版本库(模拟远程版本库)
cd sharedRep
git init --bare
3.用户A将服务器上版本库下载下来，准备工作。并加入.gitigonre忽略文件(用来过滤掉项目中不提交给 版本库进行管理的文件)。(记得在SWPTest根目录位置执行命令)
cd AWorder
git clone ../sharedRep/
touch .gitignore
// 在工作区创建了.gitignore文件
open .gitignore
git add .gitignore
// 执行完这步, 将工作区的.gitignore文件提交到了暂存区(缓存区)
git status -s
// 查询的是工作区与暂存区的文件状态(文件状态的理解是重点)
git commit -m &添加gitignore文件&
// 执行完之后，一次性将暂存区的内容提交到本地版本库。此时暂存区清空。
然后向.gitignore文件中粘贴object-c的忽略信息。(Github上搜索gitignore)
总结：以上三小步，分别为服务器端的版本库的创建(1,2), 与客户端(3,)clone到本地(如果该工程没有gitignore文件, 最好自己加上, 并添加到本地版本库和服务端版本库(共享版本库))。
增总结(三种不同的添加)
1.向stage中增加(提交):
git add &file&
&file&值的是要交给git管理的文件，上面第三步的最后一小步，就是stage添加
2.向本地版本库种增加(提交)： git commit
// 基于stage缓存
3.向共享版本库增加(提交): git push origin master
// 将当前的暂存区的所有数据提交到共享版本库(远程版本库)
在执行完上面3个小步骤时候，你也可以立即将该文件同步到共享代码库，方便其它同事的使用。
git push origin master
// 提交到主分支
在进行删除模拟前，我们先做如下准备工作，创建a.m, b.m, c.m三个源文件。并准备将其交给本地版本库管理。 所以进行向stage添加操作。具体如下
suweipeng:sharedRep sixleaves$ touch a.m b.m c.m
suweipeng:sharedRep sixleaves$ git add *.m
suweipeng:sharedRep sixleaves$ git status -s
suweipeng:sharedRep sixleaves$
当查询当前暂存区的文件状态的时候，会发现，已经变成A(第一栏表示暂存区，第二栏表示工作区)，表示已经添加到暂存区域, 状态为A(add)。接着我们开始研究删除。 通过模型，我们可以知道，git中又有三块存储文件的地方，分别是工作区、暂存区(stage)、分支。
所以，我们应该 在学习之前就问自己一个问题，如果有删除操作，是针对哪块区域的
。 我们通过具体操作来理解，如下(针对的缓存区和工作区一起删除)
suweipeng:sharedRep sixleaves$ git rm a.m
error: the following file has changes staged in the index:
(use --cached to keep the file, or -f to force removal)
suweipeng:sharedRep sixleaves$ git rm -f a.m
suweipeng:sharedRep sixleaves$ ls -al
drwxr-xr-x
6 sixleaves
7 21 16:43 .
drwxr-xr-x
3 sixleaves
7 21 11:34 ..
drwxr-xr-x
13 sixleaves
7 21 16:43 .git
-rw-r--r--@
1 sixleaves
7 21 15:59 .gitignore
-rw-r--r--
1 sixleaves
7 21 16:27 b.m
-rw-r--r--
1 sixleaves
7 21 16:27 c.m
suweipeng:sharedRep sixleaves$
第一行的意思是将a.m这个文件从工作区，并在暂存区响应的文件中标记删除操作。但是提示出错， 根据提示，我们可以使用-f来强制执行。
在Git 2.0中已经支持一种更加容易理解的方式来进行文件的删除。
现在我们直接使用系统自带的rm程序来删除，而不使用git rm。 步骤如下
1.使用rm删除工作区的文件。
2.使用git add &删除的文件名&将工作区的删除添加到暂存区。(删除工作区、暂存区中指定的文件)
3.使用git commit -m &删除文件b&。将文件从本地仓库中删除。(删除工作区、暂存区中件、本地版本库指定的文)
4.使用git push origin master. 则这时候，不仅可以将本地版本库中的文件删除，同时也将共享版本库中的文件删除。((删除工作区、暂存区中件、本地版本库、共享版本库指定的文件)。
也许你会想问，那么如果是已经提交到本地版本库中的文件呢？只是想将其从本地版本库中删除，是不能用这种新方法的，因为这种方法的前提你要删除工作区间的文件，并且让版本库中的也删除。那么如何应对这种需求，请看下面。
git rm剖析: 此时我们来验证git rm的作用区域，在验证的时候，我这边只剩下一个e.m文件，并且已经交给git管理。 此时再重新创建b.m与c.m并将其交给git管理。
具体分析:首先怎么验证所git rm -f a.m删除的是这两个区域的呢？如果一个文件已经提交到版本库中，那么此时在使用该操作会不会影响版本库呢？答案是否定的，它只影响暂存区和工作区，也就是所只删除这两个区域的元素。验证思路很简单，我们创建一个文件z.m,然后将其提交给本地版本库进行管理，在提交的后，暂存区就清空了，所以此时只剩下版本库和工作区又这个文件，此时我们执行git rm，接着在同步到共享版本库，再另外一个员工的工作目录中clone下共享版本库，查看是否存在z.m。如果存在z.m，那么也就是所git rm是不会影响版本库的中已经存在的文件。
在AWorker的工作空间中，此时AWork的暂存区存在两个文件，将其提交到本地版本库中进行管理。并同步到共享版本库中。接着我们删除git rm删除其中b.m这个文件，由于此时暂存区没有存在该文件，工作区有所以git rm不会提示 错误。这时候假设git rm对本地版本库有影响，则我们再本地版本库同步到共享版本库，如果有影响，则此时的共享版本库就不会存在该文件。于是我们又在BWorker中进行git pull指令来验证。
suweipeng:sharedRep sixleaves$ git status -s
suweipeng:sharedRep sixleaves$ git commit -m &添加b、c文件&
[master b8e8cc9] 添加b、c文件
2 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 b.m
create mode 100644 c.m
suweipeng:sharedRep sixleaves$ git push origin master
Counting objects: 2, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (2/2), 288 bytes | 0 bytes/s, done.
Total 2 (delta 0), reused 0 (delta 0)
To /Users/sixleaves/SWPTest/AWorker/../sharedRep/
97b6aa0..b8e8cc9
master -& master
suweipeng:sharedRep sixleaves$ git rm b.m
suweipeng:sharedRep sixleaves$ ls -l
-rw-r--r--
1 sixleaves
7 21 17:27 c.m
-rw-r--r--
1 sixleaves
7 21 17:16 e.m
suweipeng:sharedRep sixleaves$ git push origin master
Everything up-to-date
suweipeng:sharedRep sixleaves$
在BWorker中进行git pull指令，具体细节如下，可以看到BWorker工作区间在pull之后，存在b.m c.m e.m 所以我们可以得出结论git rm针对的只是工作区和暂存区域，当两个区域同时存在该文件的时候，进行删除 操作会出错，我们需要详细说明是不是要保存工作区的文件。
suweipeng:sharedRep sixleaves$ pwd
/Users/sixleaves/SWPTest/BWorker/sharedRep
suweipeng:sharedRep sixleaves$ git pull
remote: Counting objects: 2, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 2 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (2/2), done.
From /Users/sixleaves/SWPTest/BWorker/../sharedRep
97b6aa0..b8e8cc9
-& origin/master
Updating 97b6aa0..b8e8cc9
Fast-forward
2 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 b.m
create mode 100644 c.m
suweipeng:sharedRep sixleaves$ ls -al
drwxr-xr-x
7 sixleaves
7 21 19:00 .
drwxr-xr-x
3 sixleaves
7 21 17:18 ..
drwxr-xr-x
15 sixleaves
7 21 19:00 .git
-rw-r--r--
1 sixleaves
7 21 17:18 .gitignore
-rw-r--r--
1 sixleaves
7 21 19:00 b.m
-rw-r--r--
1 sixleaves
7 21 19:00 c.m
-rw-r--r--
1 sixleaves
7 21 17:18 e.m
suweipeng:sharedRep sixleaves$
最后分别针对这三个区域总结，如下
1、针对工作区域的删除: (如果文件是已经交给git管理)这种情况，也必须同步版本库，所以其实就是新方法的完整流程。
如果是还没提交给git管理，此时直接是用rm删除即可。
2、针对暂存区域的删除(而不删除工作区): git rm &文件名& --cached
3、针对分支(版本库)的删除: 所谓的针对分支的删除其实是没必要的，因为每次提交的时候都会产生一个新版本。
如果出错，我们可以直接使用git reset 进行版本回退。所以如果你想做到针对版本库的删除效果，就只能使用版本回退。
4、针对同时删除工作区域和暂存区域的: git rm -f &file&
需要明确的一点是，当你把文件交给git管理的时候，一旦你一修改一个文件(无论是换行还是空格都算)，git就会追踪到此时文件发生了变化。也就是所此时你必须再每次改完后，add到暂存区，然后进行commit。总要的事要所三篇！！！每次修改完都必须add到暂存区，保持暂存区该份文件的最新状态，这样在commit之后，版本库中保存的才是我们修改的文件！！！。觉得改也就这个注意点，是比较简单的，所以具体的操作，可以常见官方文档。
所以我把改分为两种，一种是针对自己编程任务进行编码的&改&。一种是你需要从共享版本库种更新下来最新 代码的&改&。前者不在复述，后者简单说一下。
在git中，我们可以使用git pull来更新一个已经和共享版本库关联起来的本地版本库，和相应的工作区间。严谨点来说git pull = git fetch + merge。即一步是取数据，一步是合并数据，所以git pull可能会在合并时候产生数据冲突，后面会详细介绍产生冲突的解决方案。这边暂且掌握简单的更新操作即可。
所谓的查有两种，一种是查看版本记录。一种是查看暂缓区和工作区的中的文件差别，以此来判断时候要更新暂缓区的文件。
查看版本记录: 就是进行版本的查看(git log、git reflog)。前者是当前存在的可追溯的版本，后者是历史记录中存在的版本。一般如果我们要回退版本的话，使用git reflog会更方便，应该它可以查看到所有的版本的历史记录。
suweipeng:sharedRep sixleaves$ git log
commit 7f0486eda9bfcaaae56ec6d854d3
Author: sixleaves &&
Tue Jul 21 20:09:53
添加了main.m
commit 97b6aafc1b73eaeb615d86faf83807f7
Author: sixleaves &&
Tue Jul 21 17:20:05
commit efcfd68ac10bab4a15c
Author: sixleaves &&
Tue Jul 21 17:16:46
添加了e文件
commit 4ebf5c7bf914bdf3f1
Author: sixleaves &&
Tue Jul 21 17:15:00
添加了b文件
suweipeng:sharedRep sixleaves$ git reflog
7f0486e HEAD@{0}: commit: 添加了main.m
97b6aa0 HEAD@{1}: reset: moving to 97b6aa0
b8e8cc9 HEAD@{2}: commit: 添加b、c文件
97b6aa0 HEAD@{3}: commit: 删除文件b
ef1169e HEAD@{4}: commit: 添加了e文件
4eb1002 HEAD@{5}: commit: 添加了b文件
a18151c HEAD@{6}: commit (initial): add gitignore file
suweipeng:sharedRep sixleaves$
查看工作区的文件状态:
git status 指令会去暂缓区中与工作区进行比较，如果是暂缓区不存在，而工作区存在的，则会显示两个？，表示还没提交给git进行管理。此时可以执行git add命令将其提交到暂缓区，此时暂缓区的文件状态，就变成了A，表示已经加入暂缓区，此时若在提交到本地版本库，则git就可以管理该文件了，所以此时再使用git status查询是没有结果的，因为此时暂缓区已经清空(在执行git commit后清空)，而工作区中的文件已经交给git管理，并且没有发送变化。
suweipeng:sharedRep sixleaves$ git status -s
suweipeng:sharedRep sixleaves$ git add 1.m
suweipeng:sharedRep sixleaves$ git status -s
suweipeng:sharedRep sixleaves$ vim 1.m
suweipeng:sharedRep sixleaves$ git status -s
suweipeng:sharedRep sixleaves$ vim 1.m
suweipeng:sharedRep sixleaves$ git status -s
suweipeng:sharedRep sixleaves$ git add 1.m
suweipeng:sharedRep sixleaves$ git status -s
suweipeng:sharedRep sixleaves$ git commit -m &添加1.m&
[master f6378aa] 添加1.m
1 file changed, 1 insertion(+)
create mode .m
suweipeng:sharedRep sixleaves$ git status -s
suweipeng:sharedRep sixleaves$
如果修改了main.m文件，再进行查看此时，第二栏目就变成了红色的M，表示已经修改工作区的文件，而此时git中版本库里的文件和该文件不同，所以我们要将其同步，必须得先进行git add，此时文件状态由工作区的M变成了暂缓区的M，并且变成绿色，而工作区的M会消失。
此时可以使用git diff查看工作区和暂缓区中具体的变化。
suweipeng:sharedRep sixleaves$ touch 2.m
suweipeng:sharedRep sixleaves$ git add 2.m
suweipeng:sharedRep sixleaves$ vim 2.m
suweipeng:sharedRep sixleaves$ git status -s
suweipeng:sharedRep sixleaves$ git diff
diff --git a/2.m b/2.m
index e69de29..abe
@@ -0,0 +1 @@
suweipeng:sharedRep sixleaves$
上图的意思是在变动后的文件种，新增加了一行ddddd
1.查询版本记录使用git log或者git reflog。
前者记录的是当前版本号的迭代顺序(可能会因为回退而覆盖)。
后者记录的是所有的历史版本记录。(后者包含前者)。
2.使用git status -s就可知道暂存区的数据是否是最新的，是否有文件没有添加进暂存取。
3.如果暂存区数据不是最新的，可以使用git diff必将查看变化的数据。
git diff中的格式说明
---: 表示变动前的文件(工作区文件)。
+++: 表示变动后的文件(暂存区文件)。
没有减号或加号的行表示没有变动的行。
-号的行表示第一个文件中删除的行，+号表示第二个文件中增加的行。
@@ -1,7 +1,7 @@这句话中的减号和加号分别表示第一个文件，和第二个文件。
文件状态总结:
补充: 暂存区的D和工作区的D的区别:
1.第一栏目的，也就是暂存区显示的是绿色的D，则表示该文件已经从工作空间
删除，删除标志提交到了暂存区，此时若再执行git commit就会将其从版本库种删除。
2.而红色的D，再第二栏目，表示工作空间上的文件已经被删除，但是删除操作还没有提交到暂存区。
只有提交到了暂存区才有机会，将其在git种删除。
颜色的红绿只是为了让你能迅速的分辨出暂存区和工作区的文件状态的 修改状态。
这是第一篇GIT简要入门的文章，如果有疑惑的地方，可以给我留言，大家相互交流。后面的文章还会再介绍 git种的冲突解决等问题。
已发表评论数()
已收藏到推刊！
请填写推刊名
描述不能大于100个字符!
权限设置： 公开
仅自己可见
正文不准确
排版有问题
没有分页内容
视频无法显示
图片无法显示32559人阅读
这个教程之前是发在社区网站上，现在把它转到自己博客上:)
说明：该教程全部图片都来自于《》。以下所有的操作，除非特别声明，都是基于终端来进行的。如果你发现这篇文章有错误，或者其他问题，欢迎与我联系：
Git是一个强调速度的分布式版本控制软件和源代码管理系统（，）。最初是由为内核开发而设计的管理软件。自从推出以来，已经被很多开源项目所采纳。每一个工作目录是一个带有完全历史记录和版本信息的仓库，不依赖于网络和中央服务器。是一个免费的开源软件，遵从协议。
Git这个词在英语中的原意是很笨拙，没用的人。自嘲说：“我是一个任性的笨蛋，所以我把我的所有的项目的名字都和我很相似。第一个是，现在是。”的帮助文档中描述为：笨拙的内容跟踪者（）。翻译自
关于开发的一些历史由来，可以看看这个网站：
2、为什么要用
更顺畅的工作流程，开发过程中，完全可以离线操作快速，分布式架构使得本地仓库包含所有的历史版本信息，你可以在不同的版本之间快速切换弹性的本地分支，在下，你建一个分支需要把源代码复制到另外一个文件夹，而在下，创建分支的代价是非常小的，只需一条命令仓库目录结构简洁，用复制一个项目，只会在项目根目录创建一个的目录，而其他目录很干净内容按元数据方式存储，所有的版本信息都位于目录下完整性好，更易于协作开发用户群大，现在已经有成千上万个开源项目采用来做项目管理，上更是有无数个代码仓库
3、GIT安装与配置
1.从源码安装
在安装之前，你必须保证以下几个依赖包已经安装在你的系统上：。如果你的系统是，你可以这样安装：
apt-get&install&curl-devel&expat-devel&gettext-devel&openssl-devel&zlib-devel
当所有的依赖项已经解决，就可以从上下载的源码，然后编译安装，具体命令如下：
tar&-zxf&git-1.*.*.*.tar.gz
cd&git-1.*.*
make&prefix=/usr/local&all
sudo&make&prefix=/usr/local&install
2.在上安装
如果你的系统是或者，你可以通过以下命令直接安装：
yum&install&git-core&(fedora)
apt-get&install&git-core&(ubuntu)
3.在上安装
尽管是发源于，但现在上也有能够正常使用，只不过不支持中文，在下所有的中文都显示问号，另外还有一些功能上的。所以建议还是在上去使用，如果你不得不工作在上，你可以到上下载msysgit的最新版，安装过程和其他程序差不多，基本上点下一步就了。默认会安装和这两个程序，一般用就可以了，它支持常用的命令。如果对命令行不熟，你也可以用用，但功能有限制。
b)&第一次使用
在你安装好之后，你需要修改一些配置，才能正常使用。
Git通过“”命令来配置，这个命令有个选项：加上默认选项，分别对应上级配置文件。第一个是文件，和对应，这是全局配置文件，修改这个文件，将会影响系统上所有的用户，所有的仓库。第二个是你家目录下的文件，与对应，修改它会对你当前用户的所有仓库产生影响。第三个是你仓库中的文件，这是“”默认修改的配置文件，它只会对你当前仓库产生影响。
在第一次使用时，你需要告诉你的协同开发者，你是谁以及你的邮箱，在你提交的时候，需要这两个信息。具体通过以下命令设置：
git&config&--global&user.name&“Test&OSS”
git&config&--global&user.email&
当然你也可以不用选项，但这意味这你在每一个仓库中都要这样设置。
同时，你也可以指定你的编辑器，你的工具：
git&config&--global&core.editor&vim
git&config&--global&merge.tool&vimdiff
你还可以通过”git&config&--list”命令来查看你的设置。
当你把设置好之后，如果你要和从服务器上获得仓库，或者向服务器提交你的代码（比如），你可能需要生成你自己的密钥对。支持种与服务器端通信的协议：、、和。其中只是一个只读协议，也就是说你只可以从服务器端获取仓库，但是你不能提交你自己的代码。而和用的很少，大部分都只支持协议和协议。
当你通过协议与远端服务器进行通信的时候，你可以通过以下命令生成密钥对：
ssh-keygen&-t&rsa
如果你没有指定密钥名称和存放路径的话，它默认把两个不对称密钥放在你的家目录下的目录下，密钥文件默认名称为和，前者是私钥，后者是公钥。中间可能会要你设定访问密钥密码，这个可以设，可以不设，但为了安全考虑，还是建议你设一个访问密码。否则，意味着任何持有你密钥的人都可以使用该密钥。
然后把你的公钥发给仓库管理员，然后你就可以通过协议来访问服务器端，期间程序会自动进行密钥对匹配，如果你设了访问密码，你可能需要输入密码。
更多关于的内容，请访问这里：
这些设定完之后，你可以通过获得任何一个公开的代码仓库来检测你的git是否工作正常。比如下面这个：
git&clone&git://git2.kernel.org/pub/scm/git/git.git
4、GIT仓库
Git做为一个资源管理和跟踪系统，如果想要把自己的文件托管在上，那么首先你得让知道你需要管理的文件在哪。比如说现在我有一个项目，它在文件夹里，我想让管理这个项目，这个时候你需进入到这个目录，然后运行“”命令。这个时候就会在该目录下生成一个的隐藏目录，用来进行版本控制和内容跟踪的所有文件都在该文件夹下。
处于跟踪下的文件只具有三种状态：
Modified(working&directory)：被修改过的文件Staged(staging&area)：通过添加到暂存区域的文件Committed(git&directory)：通过提交到仓库的文件
所以，一般的工作流程可能是这样：修改过某些文件，然后把这些文件添加都暂缓区，再提交到仓库中形成一个版本或快照，最后提交到服务器上。而在中间，可能伴随着分支管理，分支切换，撤消与合并。
可能有些人会觉得很奇怪，为什么会有暂存区域这个概念，直接提交到仓库中不就了。其实这是为了做版本控制用的，试想如果没有暂存区域，每修改一个文件，就会形成一个版本，太过频繁，不易于管理。暂存区域其实就是下一个版本的文件清单，你可以自由控制该往仓库中提交什么文件，这也可以避免在一个版本中包含一些中间文件，比如编译后的文件。
5、GIT基本流程
1.初始化仓库
初始化仓库有两种情况，一种是直接在一个空目录里建立一个项目，这时候你可以这样干：
另一种是从其他机器复制一个仓库，比如这样：
git&clone&git://git2.kernel.org/pub/scm/git/git.git&(远程仓库
git&clone&/jquery/jquery.git&(远程仓库
git&clone&:wengpingbo/MicroBlog.git&(远程仓库
git&clone&/home/oss/test.git&(本地仓库
第一次从服务器上复制一个仓库，可能比较慢，因为要把所有的历史记录和版本全部复制下来，这也算的一个弊端吧！
复制完后，就会在当前目录下生成一个工作目录，名字以仓库名字命名。如果你不想指定目录，那就在上面的命令后加一个目录就了。比如我想把仓库放到仓库中：
之后，你就可以开始你的工作啦！
2.添加文件
在编辑了几个文档之后，你可能突然想起来，好像文件还没有让跟踪。并不会实时的跟踪你的文件，只在你明确让它记录你的文件时，它才会把指定的文件的当前状态记录到仓库中去，然后又撒手不管了。我想这就是说笨的原因吧。这个时候，你需要手动添加你的文件当暂存区域：
git&add&filename1&filename2
如果你懒得一个一个加，你可以试试这个：
git&add&-A
它会把当前目录下所有的文件都添加到暂存区域。
3.添加一个版本
在添加完文件后，你可能觉得应该创建一个了。
git&commit
怎么样？是不是有点不对劲，好像这个命令并没有按你想象的那样跳出一个提交成功的提示，而是直接跑到了你在配置中指定的编辑器中了。仔细看一下，原来是让你给这个版本做一些备注，随便写点什么，然后保存退出就了。如果你不想这么麻烦，可以这么干：
git&commit&-m&‘initial&version’
可能你觉得之前讲的太罗嗦了，提交一个还这么麻烦，其实有一个捷径可以使你跳过添加文件这个过程：
git&commit&-a&-m&‘initial&version’
大功告成，这个命令会把之前所有的已经添加的文件都加入到这个版本中。
可能你又有疑问了，之前添加的文件不是自动会加入到下一个版本中吗，问什么还加这个参数？
其实命令只是把指定文件的当前状态添加到暂存区域，并不代表一个文件一旦添加，就会一直存在每个版本中。如果你添加一个文件后对这个又进行了修改，在你时候，只会这个文件添加时的状态，不会把之后的修改也进去，除非你再次添加。
4.推送变更
在你完之后，你可能想把自己的代码提交到或者其他服务器上，与他人交流共享，这时候就需要和远程服务器打交道了。
如果你是在本地建立起的仓库，默认情况下是没有任何服务器地址的，如果你是从其他服务器复制过来的仓库，这个服务器地址会自动添加到你的仓库中，你可以这样查看：
git&remote&-v
如果只输入”git&remote”，就只会列出服务器端的别名，不会列出地址来。
一个仓库可以有多个服务器地址，这就意味着，你可以从不同的人手中复制同一个仓库，但这并不会打乱你自己的分支，哪怕双方的分支名字都一样。假如你现在在和另外两个人做同一个项目中的同一个分支，你发现的一个模块正是你想要的，你想把他的代码合并到你现在的版本中，这时候你可以这样做：
git&remote&add&code_a&git://url/test.git&&//添加对方的地址是别名
git&fetch&code_a&&//复制对方的仓库到本地，但不合并，会自动合并
git&merge&code_a/master&//把对方分支合并到自己当前版本下
合并完之后，你可能想提交你的代码到其他的服务器上，这时候你可以先把要提交的服务器地址添加进来，然后这样做：
git&push&origin&master
上面的命令就是把自己的分支提交到名字为的服务器上
5.创建并管理分支
在做项目的时候，你可能会想写一些扩展性的功能，或者做一些小实验，但是你又不想影响你现在的项目。这时候，你可以创建一个分支，然后在这个分支里写东西，当觉得不好的时候，你可以把这个分支删除掉，对你之前的主分支没有任何影响。或者你觉得这个新特性超出了自己的预想，可以合并到主分支里，这时候你只要把工作转回主分支，然后合并分支，最后删除分支，然后就跟那个分支没创建一样。具体操作如下：
git&branch&test&&//创建一个分支
git&checkout&test&&//转到分支
edit&something...commit&something...
git&checkout&master&&//转到分支
git&merge&test&&//合并分支
git&checkout&-b&test2&&//创建分支，并转到分支
git&branch&-d&test&//删除分支
git&branch&&//列出分支列表
git&branch&-v&&//列出分支列表和当前
Git&merge的实质是把两个版本合在一起，然后在当前分支创建一个新的，如果你在两个分支的同一个文件的同一个地方都做了修改，这时候就会失败，就不会自动创建一个新的，而是直接停住。你需要手动修改这些冲突的文件，选择这两个分支中的一个版本，或者自己重写这个部分，然后手动添加这些文件到暂存区域，再一下就了。要查看哪些文件冲突了，可以用”git&status”查看。
6.撤消改动
是人就会犯错。当你执行某个命令之后，突然发现，自己写错了，或者漏了一个文件，这时候怎么办？
如果你提交得太早，忘了添加某些文件，你可以这样做：
git&commit&-m&‘add&something&’
git&add&file1
git&commit&--amend
最后一个命令会把你当前暂存区域最为上一次的。如果你以后，马上，这时候会直接跳到编辑备注里面，这样你可以修改你上次的备注。
如果你添加了不该添加的文件，你可以这样挽回：
git&add&.&//把所有的文件都添加进去
git&reset&HEAD&readme&&//把文件从暂存区域去除
如果你发现你编辑错了一个文件，你想把它恢复到上一个版本的状态，这时候你可以这样：
git&checkout&--&filename1&//只撤消这一个文件
如果你觉得这个版本糟糕透了，想完全回滚到上一个版本，你可以干如下事情：
git&reset&--hard&HEAD^
HEAD是指向当前版本，指当前版本的父版本，这个操作无法撤消。你可以把换成，这只会回退信息。还有一个默认选项，大家可以参考官方文档，查看这个选项的具体区别。
6、GIT常用命令
Git&commit
Git&checkout
Git&status
Git&branch
//advanced
7、学习相关资料
Git&manual&：
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：64794次
排名：千里之外
原创：14篇
C/C++/Java/lua/php/perl/shell
Lanzhou University
(2)(8)(1)(1)(2)}