Elena's Blog

上面讲解的是企业级常用的一种 Git 分支设计规范：Git Flow 模型。但要说的是，该模型并不是适用于所有的团队、所有的环境和所有的文化。如果你采用了持续交付，你会想要一些能够尽可能简化交付过程的东西。有些人喜欢基于主干的开发模式，喜欢使用特性标志。然而，从测试的角度来看，这些反而会把他吓一跳。关键在于站在你的团队或项目的角度思考：这种分支模型可以帮助你们解决哪些问题？它会带来哪些问题呢？这种模式为哪种开发提供更好的支持？你们想要鼓励这种行为吗？

⽬前，我们所完成的工作如下：基本完成 Git 的所有本地库的相关操作，git 基本操作，分支理解，版本回退，冲突解决等等。申请码云账号，将远端信息 clone 到本地，以及推送和拉取。是时候做最重要的一件事情了，实现多人协作开发。为了做这件事情，需要先做一些准备工作。

标签tag可以简单的理解为是对某次commit的一个标识，相当于起了一个别名。例如，在项目发布某个版本的时候，针对最后一次 commit起一个v1.0这样的标签来标识里程碑的意义。这有什么用处呢？相较于难以记住的commit idtag很好的解决这个问题，因为tag 一定要给一个让人容易记住，且有意义的名字。当我们需要回退到某个重要版本时，直接使用标签就能很快定位到。

理解分布式版本控制系统。

分支在实际中有什么用呢？假设我们准备开发一个新功能，但是需要两周才能完成，第一周写了 50% 的代码。如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交，又存在丢失每天进度的巨大风险。现在有了分支，就不用担心了。我们创建一个属于我们自己的分支，别人是看不到的，还继续在原来的分支上正常工作，而我们在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样既安全，又不影响别人工作。

要提前说的是，仓库是进行版本控制的一个文件目录。我们要想对文件进行版本控制，就必须先创建一个仓库出来。创建⼀个 Git 本地仓库对应的命令为git init，注意命令要在文件目录下执行，例如：我们发现，当前目录下多了一个.git的隐藏文件，.git 目录是 Git 来跟踪管理仓库的，不要手动修改这个目录里面的文件，不然改乱了，就把 Git 仓库给破坏了。

提出问题。