Git 的发展历史
在做一个项目工程的时候，代码总是不断地更新，于是你就可能一边写代码，一边就为你的代码创建了很多的版本文件夹，分别叫“项目 0.1”、“项目 0.2”、“项目 0.3”、“项目 1.0”之类的名字，让你可以区分哪个是新版本，哪个是老版本。当你想找到一个曾经修改过的代码时，你可能会根本记不起你是在创建哪个版本文件夹的时候做出了这个修改。
更要命的是，如果你和一个同事一起在做一个项目，你拷给他了某一个版本。之后的几天，你和他都在这个基础上做了一些修改。当你们想把这些修改放到一起，做一个新版本的时候，你可能会觉得手足无措，不知道该从哪里下手，似乎完全没有任何办法可以让你的修改和他的修改被放到一起。
你所面对的这些问题，Linux 操作系统的创始管理者 Linus 也遇到过。在 2002 年前，参与贡献 Linux 操作系统的人们通过源代码差异标注的方式把自己的修改发给 Linus，然后 Linus 需要手动合并代码，就类似于我们前面提到的办法。2002 年，Linus 得到 BitMover 的支持，BitMover 允许 Linux 社区免费使用他们的商业版本控制系统。
但是 Linux 社区有一些贡献者在 年的时候被发现试图破解 BitKeeper 协议，被 BitMover 发现了，于是 BitMover 提出要收回 Linux 社区免费使用他们版本控制系统的权利。Linus 随即用两周时间写了一个叫 Git 的分布式版本控制系统，之后 Git 迅速地成为了最流行的代码及版本管理工具。
相比于诸如 SVN 之类的集权式的版本管理，Git 并没有把代码的版本仓库维护在中央服务器，而是每个人都有一份完整的代码版本仓库。这样的情况下，如果某一个人的版本仓库坏掉了，也不会引发像 SVN 的中央服务器坏了以后没法工作的灾难，他只要再从别人那拷贝一个版本仓库就好了。
Git 的安装和配置
http://git-/download
当然，如果你使用的操作系统是 Windows，就完全没有必要这么麻烦了，直接下载安装文件即可。
安装完成后，你就可以在你的机子上使用git命令了。不过你最好还是先进行一下设置，让以后提交你的版本后面都署上你的名字和你的邮箱。比方说你叫suantou，邮箱是suantou@，那么就可以这样设置：
$ git config --global user.name "suantou"$ git config --global user.email "suantou@"
因为 Git 是分布式的版本管理系统，每个提交者都有必要标记一下自己，让其他的人知道你到底是谁。你可能注意到了，我们在这里加了一个--global，这个选项表示了在这台机子上的所有 Git 仓库都会共用这个配置。而如果不加这个选项则可以给不同的项目指定不同的署名
Git 的工作区和版本仓库
工作区
就是我们平时说的工作目录，jisuanke这个目录就是我们一直在使用的工作区。
版本仓库
在工作区中有一个隐藏目录.git，这个不算工作区，而是 Git 的版本仓库。Git 的版本仓库里存了很多东西，其中最为重要的就是暂存区。除此之外，还有 Git 为我们自动创建的第一个分支master。
暂存区
暂存区是 Git 版本仓库的一部分，Git 和其他版本控制系统如 SVN 的一个不同之处就是有暂存区的概念。
我们将文件往 Git 版本仓库中添加的时候，是分两步执行的：
用git add把文件添加进去，实际上就是把文件修改添加到暂存区；用git commit提交更改，实际上就是把暂存区的所有内容提交到当前分支。
团队和软件团队
什么是团队？团队有着这样的特点，他们有一致的集体目标，并且他们会一起完成这个目标。一个团队的成员不一定要同时工作，但他们之间有各自的分工，互相依赖合作，共同完成任务。如果你是在街边随口喊一嗓子拉来了一帮群众演员，那么他们一定是不能称之为一个团队的。
软件团队则有各种形式，适用于不同的人员和需求。而我们现在比较常见的团队模式有两种，分别是：交响乐团模式和功能团队模式。
交响乐团模式
当某个软件领域处于稳定成长阶段的时候，众多大型软件公司的开发团队就会采取这种模式，就像交响乐团的演奏一样，有着这样的特点：
团队成员多，分工详细；团队成员各司其职，按职能合作，往往有各自的办公区域；有着统一的一个项目目标；大多是维护已经成型的产品，重在执行。
功能团队模式
很多软件公司的团队最后都演变成功能团队，简而言之，就是具备不同能力的同事们平等协作，共同完成一个功能。在这个功能完成之后，这些人又重新组织，和别的角色一起去完成下一个功能。不同职能的同事之间没有管理和被管理的关系。大型软件公司里的不少团队都采用这种模式。
团队开发流程
我们在开发、运营、维护软件的过程中有很多技术、做法、习惯和思想。软件工程把这些相关的技术和过程统一到一个体系中，叫“软件开发流程”，软件开发流程的目的是为了提高软件开发、运营和维护的效率，以及提升用户满意度、软件可靠性和可维护性。
瀑布模型
当软件行业还在年幼的时期，它从别的成熟行业借用了不少经验和模型。在这些行业中，产品大多遵循“分析→设计→实现→销售→维护”这个流程，被称之为“瀑布模型”。在不断的演变过程中形成了一个固定的版本。
瀑布模型的局限性
尽管瀑布模型是一个反映人类解决问题思路的常用模型，但它还是有着各种各样的问题。它在软件工程中的局限性在于：
各步骤之间是分离的，但是软件生产过程中的各个步骤不能这样严格分离出来；回溯修改很困难甚至不可能，但是软件生产的过程需要时时回溯；最终产品直到最后才出现，但是软件的用户，甚至软件工程师本人都需要尽早知道产品的原型并试用。
瀑布模型的好处
尽管如此，瀑布模型在一些情况下是很适用的：
如果产品的定义非常稳定，但是产品的正确性非常重要，需要每一步的验证；产品模块之间的接口、输入和输出能很好地用形式化的方法定义和验证；使用的技术非常成熟，团队成员都很熟悉这些技术；负责各个步骤的子团队分属不同的机构，或在不同的地理位置，不可能做到频繁的交流。
敏捷流程
在软件工程的语境里，“敏捷流程”是一系列价值观和方法论的集合。从 2001 年开始，一些软件界的专家开始倡导“敏捷”的价值观和流程，他们肯定了流行做法的价值，但是也强调了敏捷的做法更能带来价值。敏捷流程与渐进交付的流程很相似。
敏捷的要求
敏捷对团队的要求很简单：自主管理、自我组织、多功能型，但是这很难做到。软件项目的团队各式各样，假设一个团队做的还不错，现在要变成敏捷流程，那么团队要做到以下的改变：
自主管理：团队成员要做到自己挑选任务，而不是等待领导布置任务，并且要自主做到总结不足，提出改进，并且自己要实施这些改进。“自主管理”并不代表“没有管理”。自我组织：以前每个人做好自己的事情就好了，现在每个人要联合起来对项目负责，有人工作落后了还要帮助他改进，项目缺少某类资源还要自己顶上去。多功能型：以前规格说明书由 PM 来写，测试由测试人员来做，现在每个人都全面负责，自己搞定规格说明书，和别人沟通，同时自己搞定测试。
敏捷开发的原则
敏捷开发提倡尽早并持续地交付有价值的软件以满足顾客需求，因此敏捷流程欢迎需求的变化，并会利用这种变化来提高竞争优势，软件的发布间隔也只有几周到几个月。在项目开发的过程中，业务人员会和开发人员每天共同工作，通过面对面的交流方式来提高效率。
