g4e基础篇#5 建立分支和保存代码

章节目录

前言

1. 基础篇：

• 为何要使用版本控制系统
• Git 分布式版本控制系统的优点
• Git 安装和设置
• 了解Git存储库(Repo)
• 起步 1 – 建立分支和保存代码
• 起步 2 – 了解Git历史记录
• 起步 3 – 拉取请求 Pull Request 工做机制

---

使用版本控制系统最多见的工做流程就是修改代码，保存代码，共享代码。Git提供了一个简单的3步工做流，让你方便的完成这些操做。

1. 新建工做分支
2. 提交更改
3. 推送分支到中心存储库与团队成员共享

Git 工做流

按照以上3步操做，咱们就能够开始平常的编码工做流了。下图中展现了这个工做流的示意：

下面，咱们按照这3个步骤来完成一个典型的Git提交的建立过程：

1. 建立分支

建立分支以前你须要获取Git存储库，这部分请参考以前的内容。将命令行切换到存储库中的任意目录，而后执行如下命令：

>>> git branch

不带分支名称命令能够查看本地已经存在的分支

>>> git branch <分支名称>
>>> git checkout <分支名称>

带有分支名称的branch和checkout命令用于建立和切换分支，你也能够经过一个命令完成以上操做

>>> git checkout -b <分支名称>

执行完成后你会看到命令行的提示符发生变化，表示你已经切换到一个分支上进行工做了。

2. 提交代码到分支

首先经过cmder中的命令提示行确认你所处的分支是正确的，注意下图中的 (my-new-branch-2 -> origin) 这表示咱们当前处于my-new-branch-2这条分支上，后面的origin是git远程存储库的一个标识，表示当前咱们跟踪的是origin这个别名的远程存储库。

注：关于远程存储库咱们在后面进阶篇会专门进行介绍，这里你只要知道这就是你克隆代码的那个存储库就够了。

在以上命令行状态下键入如下命令打开 Visual Studio Code，编辑文件并保存退出。

>>> code .

以上咱们对2个文件进行了变动，a.txt是一个已经存在的文件，b.txt是咱们刚刚新建的文件。以上咱们保存文件并关闭vscode之后，能够经过如下命令查看当前工做目录中的变动

>>> git status

以上输出的内容中有2部份内容须要理解清楚

○ Changes not staged for commit：这部分列出的文件表示已经属于存储库的一部分，可是当前的改动并无被暂存。
○ Untracked files: 这部分列出的文件还不属于存储库的一部分。

你会注意到在a.txt前面显示了modified，由于a.txt已是存储库的一部分因此git能够跟踪到你对它的修改，可是对与b.txt git根本不知道你作了什么，它只知道这里有个文件尚未被git跟踪。

如今，咱们须要将这两个文件“暂存”，作好提交准备。而后执行如下命令完成暂存

>>> git add --all
>>> git status

你也可使用文件名或者通配符替换–all参数，只添加那些本身认为须要暂存的文件。

若是暂存错误，使用如下命令取消暂存。

>>> git reset HEAD

这时git已经将2个文件所有放入了暂存区，准备进行提交。这时你能够执行如下命令完成提交，git会对当前文件建立快照，造成版本记录。请执行

>>> git commit -m "my first git commit"

git commit 命令用于提交代码变动到git存储库，后面的-m参数因为给出你的提交注释，在git中提交注释是必选项，不能掠过。这实际上是一个很是好的设计，我想你必定为了在svn代码库中看到一堆没有注释的变动骂过街。

完成 git commit 命令后，你的git中就已经保存了刚才所作的代码改动了。如今你能够继续编码，并在感受必要的时候随时重复以上的过程保存本身的改动，就不用再担忧会丢失代码了。

你还能够随时切换回到master分支，这个操做不会要求你更改目录，而在编辑器里面的代码会直接切换到master分支的代码状态。只要执行

>>> git checkout master

注意：当我完成切换的是时候，咱们以前建立的b.txt从vscode中消失了，同时a.txt里面以前修改的内容也不见了。若是要找回改动，只要再切换回到刚才的分支便可。

3. 推送分支到中心存储库与团队成员共享

企业开发中推常见的场景就是团队协同，开发人员本地完成修改后须要共享给其余开发人员一块儿使用，这时咱们能够利用中心存储库来完成这个操做。首先确保你处于本身但愿共享的分支中，而后运行：

>>> git push origin my-new-branch-2

完成操做后，你的本地分支就被推送到中心存储库上了，这时其余开发人员就能够经过如下命令获取你的分支代码。

>>> git fetch
>>> git checkout my-new-branch-2

注意：git容许你在本地和远程使用不一样的分支名称，这给予开发人员更多的自由度，可是有时候也会形成麻烦，好比可能你忘记了你本地分支已经在跟踪一条远程分支，不当心改错了代码。

为了可以更加清晰的标识分支的全部人，通常咱们在创建分支的时候会经过前缀的方式来标识，使用特定格式的前缀可让VSTS/TFS将你的前缀变成分支文件夹形式显示，便于管理。以下图，在建立分支的时候使用了 leixu/ 做为前缀，推送到服务器上之后就变成文件夹显示

你甚至能够设置多级文件夹，这样在团队比较大的时候管理起来就容易多了。

为什么必定要使用分支？

为何改动必定要放在分支中实现。这个与软件开发自己的特性有关系，软件开发过程自己是一个不肯定的过程，没有人能够在代码写完以前预测出到底应该怎样写。这个与产品生产制造不一样，产品生产制造以前，全部的工序，操做和零件都是肯定的，所以咱们能够清晰的规划如何完成制造过程，也能够将这个过程组织成流水线顺序执行（注意：这里的流水线特指制造业工厂中的生产流水线，与咱们后面说的软件交付流水线不一样）。软件的开发过程则彻底是一个探索过程，开发人员须要通过屡次失败的尝试才能最终找到正确的实现方式，这个过程须要屡次修改代码，有时还可能会推翻历来。这种循环往复的过程越接近开发人员的平常编码，越接近最小的功能实现就愈加频繁。所以，开发人员必须可以在不影响主干代码的状况下，自助的建立代码副本，在这个副本上完成以上尝试；同时，也须要兼顾代码主干上的变动，确保本身的改动的基准永远与整个团队对齐，不然就算写好了也没法与整个团队的工做集成。这个矛盾是全部配置管理策略要处理的核心矛盾，全部咱们所遇到问题，各类复杂的分支策略以及后续的持续交付流水线的设计都是基于这个问题延展出来的，只不过在更加复杂的团队/产品/项目中，这个矛盾被乘各类复杂度被放大，于是须要咱们提供更为复杂的配置管理流程来进行适应。

从这一点上稍微扩展一下，你就能够理解其实全部的配置管理流程的设计原则应该是“适应”而不是“控制”，找出最适合团队的流程，让流程为人服务是全部配置管理流程目标。也由于此，咱们须要将配置管理流程视为一个变化的规则，它必须根据团队的状况适时改变，才能确保可用。

理解了以上2点内容，咱们就知道为何Git的工做必定要放入分支，而不是在主干上直接操做。若是代码变动直接进入master或者团队成员共享的分支，则会直接对生产环境或者团队成员共享的环境形成影响，在变动还未成熟稳定以前，最保险的作法就是尽可能隔离的进行修改直到代码能够被其余成员或者某一环境接受的时候再合并进去。

虽然任何的配置管理工具都容许你建立分支，可是Git的如下2个特性决定了它超越其余任何配置管理工具成为团队的首选：

1. 轻量级分支：Git的分支很是轻，能够在瞬间完成建立，也能够随时被销毁；拉分支不会增长Git存储库的存储开销，只有当你提交修改的时候才会增量的增长相应的存储内容。
2. 同文件夹内切换分支：Git分支切换不须要切换文件夹，这样能够和开发工具更好的集成，开发人员能够快速的在不一样分支间进行切换，甚至都不须要中止IDE里面的Debug进程。这让开发人员更加敏捷的进行尝试，更加快速的解决问题。
3. 本地分支：由于分布式的特色，Git分支不须要依赖服务器就能够完成。给予开发人员独立的，不依赖其余人就能够进行尝试的可能性。而在集中式配置管理工具中，任何分支的建立都必须是由配置管理员才能完成的工做，这大大下降了单个开发人员的效率。

采用集中式版本控制(CVCS)的系统并非不能建立分支，可是因为分支过于沉重，开销太大，团队每每会选择只容许配置管理员才能执行这个操做，这就让开发人很受束缚。

注：固然，也正是由于以上这些优点，才让不少企业的大规模团队管理者对Git敬而远之，以为它太过灵活。其实Git彻底兼顾了大规模团队的管控要求，只是实现的方式与传统的配置管理工具不一样而已，这一点咱们会在第3部分中专门讨论。

小结

在这一篇中咱们介绍了基本的Git编码工做流程，了解了这些你就能够开始使用Git进行平常的编码工做了。固然，既然Git推荐咱们尽可能使用分支来维护变动，那么就必须容许咱们进行合并，这样才能最终完成团队开发的协做。这部分会在下一篇中进行介绍