Git的正确姿势

引言

与传统的代码版本工具相比，Git有很多的优势，因而越来越多的程序员喜欢版本管理工具。Git这个版本管理工具最大的优势包含以下几个方面：

• Git是一个分布式的版本管理工具，而且可以是单机版的，所以，你在没有网络环境的时候同样可以提交(Commit)代码。对于我们来说，这意味着在出差途中或是没有网络的环境中依然可以工作写代码。

这意味着，一方面，以后再也不能以没有网络作为不工作的借口了。另一方面，没有网络意味着没有Google和StackOverflow，光有本地的Git我也一样不能写代码啊...

• Git从一个分支向另一个分支合并代码的时候，会把要合并的分支上的所有提交一个一个应用到被合并的分支(Branch)上，合并后也能看得到整个代码的变更记录。而其它的版本工具则不能。
• Git切换分支的速度非常的，不像其它版本管理工具，每个分支就是一个副本，一份拷贝。
• Git有很多非常有用的命令，让我们可以很方便的工作。

常用的Git命令

• git stash:：就我个人而言，我比较喜欢git stash命令,这个命令可以把当前没有完成的事暂存一下，然后忙别的事情。
• git cherry-pick：git cherry-pick命令可以让你有选择的合并并提交。
• git add -p：可以让你挑选改动提交。
• git grep $regexp $(git rev-list --all)：可以用来在所有提交中找代码，因为是本地操作，所以你会觉得飞快。

除此之外，由Git衍生出来的GitHub和GitLab可以帮助你很好的管理编程工作，比如:wiki，fork，pull，request，issue... ...集成了与编程相关的工作，让人觉得这不是一个冷冰冰的工具，而真正和我们的日常工作发生了很好的交互。

像GitHub和GitLab这样的工具的出现，让我们的工作可以呈现在一个工作平台上，并以此来规范整个团队的工作，这才是Git这个版本管理工具成功的原因。

我想说的是，如果你还不会用Git的话，那你已经严重的落后于这个时代了。接下来的篇幅我们就来讲解一下Git的协同工作流，因为我看到很多团队在使用Git时，并没有用好。

注意：因为GIt是一个分布式的代码管理器，所以，是分布式就会出现数据不一致的情况（CAP），因此我们需要一个协同工作流来让工作变得高效，并可以有效的让代码具有更好的一致性。

说到一致性，就是每个人手里的开发代码，还有测试和生产线上的代码，要有一个比较好的一致性的管理和协同方法。这就是Git协同工作流所需要解决的问题。

目前来说，你可能以为我想说的是GitFlow工作流。恭喜你猜对了。但是，我想说的是，GitFlow工作流太过复杂，我并不觉得GitFLow工作流是一个好的工作流。如果你的团队在用这种工作流开发软件，你相信你一定会觉得糟透了。

所以，这篇文章的目的会对比一些比较主流的协同工作流，然后顺便抨击一下GitFlow工作流。

中心式协同工作流

首先，我们先说明一下，GIt可以像SVN这样的中心工作流一样的工作。我相信很多程序员都是采用这样的工作方式。

这个过程一般是下面的这个样子：

1. 从服务器做git pull orgin master把代码同步下来。
2. 修改完后,git commit到本地(local)代码仓库中。
3. 然后git push origin master到远程仓库，这样其它同学就可以得到你提交的代码了。

如果在第3步发现push失败，因为别人已经提交了,那么你需要把服务器上的代码pull下来，为了避免merge动作，你可以git pull --rebase。这样就可以把服务器上的提交直接合并到你的代码中，对此，Git的操作就是这样子的。

如下图所示。Git会把Origin/Master的远程分支下载下来（紫色）,然后把本地的Master分支上的改动一个一个地提交上去（蓝色）.