Windows下Git与TortoiseGit使用教程（Github为例）（三）

Git工作流程

不要着急，我们在正式使用之前，需要对Git的基本工作流程有一个清晰的理解。

从本地库单一分支开始

Git是分布式的，因此，服务器上的库和你本地的库其实是同等的，两边的库都是具有完整的历史版本信息的。事实上，如果没有服务器，那么成员之间也是可以直接进行代码同步的，只不过这样会很混乱。这一点和SVN与CVS这样的集中式系统是很不同的。

我们先研究本地的单一分支库。

文件状态

文件的两种基本状态：被追踪，和不被追踪。

原因很简单，项目中有我们需要进行控制的代码文件，也有不需要的临时文件。如果我们新添加了一个文件，那么它默认是不被追踪的，你需要主动去添加到追踪文件中（add操作）。

 

对于被追踪的文件，有三种状态，已修改（modified），已暂存（staged），已提交（commit）。

已修改：你把原有的库中的某个文件进行了修改，此时由于文件的校验值发生了变化，Git会检测到你做了修改。此时我们需要做暂存的操作。

已暂存：在修改之后，你可以把修改暂时写入缓冲区，在积累了几次修改足够构成一次提交之后，再一次性提交（commit）到本地库。其实上面讲的“add”操作，完整的应该说是什么？应该是“add files to stage”。

已提交：注意这个提交是提交到本地库，因为本地也有一套完整的代码库。

 

暂存的历史不会被记录，只有commit到库中的信息才会被记录到版本信息库中，以后可以随时回滚查看。

 

可能有的时候你会觉得，中间的那个暂存区要来干嘛？很多余嘛。小项目当然完全无所谓，但是如果项目大了，那么版本的历史信息会很复杂的。这个时候，不必要的版本过多，也不好。暂存区就是用来防止一些不必要的commit。

分支的作用

分支是git的最突出的一个地方。

其实概念很简单，看名字就知道了，不过为什么要分支？

比如一个项目，现在要同时开发A功能和B功能，怎么处理？

 

其实也很简单，比如有一个中心库，然后你克隆到本地，做了一些修改，commit到版本A，而我呢，commit到版本B，然后呢？合并吗？合并的结果是什么，合并之后，如果代码一点问题都没有，如果A和B两个功能我们不需要再回溯，那么什么都不是问题。但是往往现实中，如果A突然发生了问题怎么办。

 

分支就要用上了：我们有一个主干分支，然后分别开一个A分支和B分支，你做你的，我做我的，然后确认无误之后，合并到主干。那这样，如果发生问题，是不是就比原来要容易解决多了？否则你都不知道问题出在了哪里。

 

流程

 

真正开发的时候，往往至少会有两个长期的分支（develop，master），最新的进度在develop中，而master则是稳定可靠的随时可以发布的版本。当然，develop中的代码也是可运行的完整代码，不能有残缺的代码。开发中会有很多临时的分支，用来开发一些新功能，在确认无问题之后，合并到develop中，然后删除临时分支。Develop中的代码不一定是合适发布的，可能是实验性的，在develop中的某个版本到了比较成熟的时候，去和master合并。

 

当master中有bug了怎么办？那就新开一个bugfix分支，解决掉master的bug，同时再和master与develop合并（develop一般也会存在同样的bug嘛），然后删除临时分支。

 

我们在开始工作前，先从服务器上拉去最新的版本，然后开发，然后把自己的版本合并到服务器上去。

 

本文档完整版PDF版本下载：http://download.csdn.net/detail/jarelzhou/7074985