标签：处理   理解   同事   需求   复制   协同   任务   运行   science   

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

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

一起盖房子吧

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

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

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

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

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

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

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

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

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

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

提交就像将更改保存在本地，每一次新的提交都有一个数字，也代表了你可以返回的保存点，就像在任务游戏中你可以返回到之前的保存点一样，所以当张三建造橱柜的时候，他可以提交它们以保证他的更改不会丢失，并且如果他建造的下一个部分危及到橱柜的质量，他还可以回滚回去。
因此，当Bob建造厨柜时，他可以提交它们，以免丢失更改，并承诺如果他制造的下一部分会危害厨柜的质量。

每次提交还需要一条消息，因为写一些关于你的提交的内容以便让每个人都知道这个“保存点”包括什么是一个很好的实践，张三提交的消息写道“创建红色厨房橱柜”。

我想将设计保存在存储库中的安全位置—git push

存储库是存储所有分支的地方，包括主分支，它就像一个文件夹，里面有关于项目的所有文件，包括它们的修订历史。

Git push 获取你的所有提交并将它们发送到分支的远程版本，该版本可以在在线存储库中获得，所有参与其中的的开发人员都可以看到对分支所做的更改。因此，张三将他的提交推到他的远程分支，我现在可以看到张三关于红色橱柜的提交。

我的客厅装修好了，现在怎么办呢?-开发分支和合并（merge）请求

我们的开发分支是一个集成我们的房间(或功能)的地方，在这里，我们尝试把我们的设计(或功能)结合在一起，看看我们的客厅和厨房的功能是否很好地结合在一起。

如果我想把我的客厅添加到开发分支，我必须做一个合并请求(pull request)，通常，在远程分支上发生合并之前，至少必须有一个其他开发人员批准你的合并请求。

张三的厨房做完了，我们的设计不匹配—合并冲突（Merge conflicts）

我试图将张三的新变更合并到我的分支中，但是如果我没有把张三的开放式厨房一侧的墙砌好，会发生什么呢？我们的设计存在冲突，Git 可以自动解决一些冲突，但不能解决所有冲突，Git 有时需要你的帮助来确定应该保留哪些更改，因为其中一些更改是相互冲突的。换句话说，它需要知道保留谁的“设计”(或代码)是正确的选择。

假设我是犯错的人，我可以告诉 Git 在设计厨房墙壁时保留Bob的部分，而不是我的。

我们什么时候可以把厨房和客厅加到主分支？

项目的这一部分通常包括测试、批准，一旦我们的设计经过了全面的测试，这意味着它们也能很好地一起工作，并且我们的利益相关者，房屋所有者批准了这些设计，我们就可以决定将我们的更改合并到主分支，这意味着从现在开始，我们房子的稳定版也将包括我们的客厅和厨房，因此所有的新分支至少应该包括这些房间。

在某些情况下，明智的方法可能是将主分支以前的每个版本都保存在不同的分支中，然而，处理主分支的正确方法取决于你的团队和公司的需求或准则。

总之，版本控制是简单和安全协作的核心

在团队项目中使用 Git 允许多个开发人员独立地处理同一个项目，而不会经常干扰彼此的输入。每个开发人员都可以获得一个独立的代码版本，他们可以修改这个版本，而不必承担破坏稳定版本代码的风险。

Git 能够复制代码并在不同版本上独立工作，这使它成为构建应用程序的任何人(甚至是单独工作的开发人员)的一个很好的选择，它使您有机会保留代码的多个版本，并跟踪每个更改的所有特征，比如谁做了更改以及何时做的更改。

感谢大家的阅读，欢迎留言进行交流讨论。

最好的关系就是互相成就，大家的在看、转发、留言三连就是我创作的最大动力。

参考

https://towardsdatascience.com/a-simple-story-to-explain-version-control-to-anyone-5ab4197cebbc

一个故事带你了解版本控制

标签：处理   理解   同事   需求   复制   协同   任务   运行   science   

原文地址：https://www.cnblogs.com/wupeixuan/p/13298443.html