当我们初次在项目中使用版本控制时，这个概念可能难以理解。我看到很多人（也包括我）都在运行诸如 git pull，git push 以及运行其他一些我不理解的命令。为什么我既要 commit 还要 push？为什么每个新特性都需要新建一个分支？

在使用 Git 进行协同工作几个月后，对于版本控制这个概念就比较清晰了，可以更好地理解和使用版本控制来进行协作。下面通过一个小故事来说明版本控制的工作方式及其在项目中的优势吧！

一起盖房子吧

在这个美好的合作项目中，我们将尝试一起盖房子。简单点说，我们只有两个人在这栋房子里工作。我们不是房子的主人，我们为别人（利益相关者）处理房子的内容，他告诉我们他想要什么，想要在哪里。

我们有 4 面墙—主（Master）分支

我们从 4 面墙和屋顶开始，这是坚固的，耐久且非常好的，这四堵墙代表我们的 Master 分支，它们目前已经实施，并且不会被删除。利益相关者批准了这四堵墙，他甚至可能亲自选择了它们，并且希望保留它们。我们需要做的就是改善这四堵墙，在上面或周围建造。无论如何，我们要建造的任何东西都将以这四堵墙为基础。

业主想要一间客厅和一间厨房-特性（Feature）分支

正如我之前提到的，有两个人在做这个项目，我和另外一个同事张三。每个房间都是一个特性，在这种情况下，为了使结果最大化，我和张三将研究不同的特性，我将设计客厅，张三将设计厨房，到目前为止一切都很顺利。

我们都创建了一个特性分支，我们还知道必须使用约定来命名我们的分支，因此，我们将以正在处理的工作(在本例中，是一个新特性)、该特性的名称和我们的名字。

• feature-living_room-wupx
• feature-kitchen-zhangs

命名分支有多种约定，这只是其中一个建议。

我们都从主分支创建特性分支，所以我们一开始都有相同的四面墙，然而，我们的特性分支完全是主分支的独立副本，对主分支的内容没有直接影响，这就保证了如果我和张三完全破坏了四面墙其中的一个，主分支的四面墙仍然是站立的。

我想将设计保存在本地—git commit

提交就像将更改保存在本地，每一次新的提交都有一个数字，也代表了你可以返回的保存点，就像在任务游戏中你可以返回到之前的保存点一样，所以当张三建造橱柜的时候，他