摘要：
`git` 鼓励大量使用分支 "早建分支!多用分支!" ,这是因为即便创建再多的分支也不会造成存储或内存开销,并且分支的作用有助于我们分解逻辑工作,这样一样其实比维护单一臃肿分支要简单得多! 正因如此,每个新功能会创建合并分支,修复 会创建合并分支等等,一段时间后再次回顾整个版本库的提交历史就会发现 阅读全文
摘要：
和往常一样,每个人团队开发者都在自己的本地分支上进行日常工作,相互独立又相互联系,一直以来相安无事,可是某天下午,上级领导突然急冲冲的打电话告诉你线上出 了,需要你紧急修复,下班之前必须解决! 我们天生就是创造 的特殊群体,每天都在和各种各样的 打交道,早已经习惯了这样的工作节奏,再也没有当初刚刚遇 阅读全文
摘要：
默认情况下合并分支常常直接使用 命令,是最方便快速的合并方法.其实这种情况下 采用的是 模式,特点是删除分支后,会丢失分支信息,好像从来没存在该分支一样,而我们推荐的是 模式,能够保留分支的版本记录. 递归模式( ) 创建并切换 分支,提交版本后切换回 分支,然后再合并 分支,这不过这一次不再使用 阅读全文
摘要：
如果足够幸运的话,团队成员互不影响,彼此相安无事,大家各自基于 分支的某个 创建自己的分支,平时在分支上独立工作,等到一段时间后再合并 到 分支,这样一样 作为各个功能的集大成者,最终完成项目. 然而事情总不是一帆风顺的,团队协作时由于意见不同,遇到冲突简直是家常便饭,既然无法回避冲突,当冲突发生时 阅读全文
摘要：
分支就是一条独立的时间线,既有分支,必有主干,正如一棵树谈到树枝,必有树干一样的道理.我们先前对 的全部操作默认都是在主干上进行的,这个主干也是一种特殊的分支,名为 分支. 无论是穿越历史还是撤销更改,我们都或多或少接触过时间线, 管理的版本串在一起就组成了这个时间线,其中 分支是当前分支, 指向 阅读全文
摘要：
背景 什么是分支?简单地说,分支就是两个相对独立的时间线,正常情况下,独立的时间线永远不会有交集,彼此不知道对方的存在,只有特定情况下,两条时间线才会相遇,因为相遇,所以相知,因为相知,所以改变! 正如分支对于科幻电影来说是一个很好的卖点,关于分支的话题完全可以开启新的题材,对于这点相信不少科幻迷都 阅读全文
摘要：
远程仓库 如果说本地仓库已经足够个人进行版本控制了,那么远程仓库则使多人合作开发成为可能. 如果你只是打算自己使用 ,你的工作内容不需要发布给其他人看,那就用不到远程仓库的概念. 是 分布式版本控制系统 ,分布式意味着同一个 可以部署在不同的机器上,正如"鸡生蛋蛋生鸡"问题一样,不论如何,先要有一个 阅读全文
摘要：
删除文件 回忆一下文件的常见操作,新增文件,修改文件,删除文件等,新增和修改文件都单独讨论过,现在我们来研究一下如何删除文件. 你可能会说删除文件还不简单啊,直接 即可,但是这仅仅是本地文件被删除了,对于 来说,文件并没有被删除. 还记得我们开篇介绍 时就说过, ,对于新增是一个版本,修改也是一个版 阅读全文
摘要：
撤销更改 相信你已经了解了 的基本概念,也清楚了工作区,暂存区和版本库的关系,现在让我们用所学的知识继解决实际问题吧! 背景 正常看得见的目录是我们最为熟悉的工作区,在工作中不可能总是100%的精力,难免会犯错,尤其是下午犯困,晚上加班更是如此.下面列举了常见的一些场景 场景一: 工作区出现意外更改 阅读全文
摘要：
版本控制 我们知道 是分布式版本控制系统,所以称被控制对象是版本本身没错,但是从 命令中发现,并没有版本这个名词,有的只是 ,所以前几节我一直称其为 提交 . 为了避免后续教程引发歧义,特意说明,无论是 版本 也好, 提交 也罢,都是中文翻译而已,不必太过较真,直接原汁原味称 也可以啊! 假设你已掌 阅读全文