注解目录
1、关于 Git
1.1Git 今生
(Git 和 Linux 的生父都是 Linus，振南给你讲讲当初关于 Git 的爱恨情愁，其背后其实是开源与闭源两左阵营的明争暗斗。)
1.2Git的爆发
(Git 超越时代的分布式思想。振南再给你讲讲旧金山三个年轻人创办 GitHub，打败Google，逆袭上位的创业故事。据说 GitHub 服务器要放到火星去? )
2、用Git代码
2.1Git化使用
(以实例来讲解代码仓库的创建、提交、分支等基础内容。)
2.2 Git 的远端使用
(以实例来讲解仓库的克隆、推送等基础内容。)
2.3代码拯救纪实
（绝不会把代码弄丢。一次有惊无险的代码追回经历,根源是对 Git 机制理解不深。)
3、用Git 管理硬件PCB
(对于硬件资源你是如何管理的? final _final _打死不改_final_1.2.zip? 还是用 Git 吧。)
3.1Git的增量
(Git 具体是如何对资源进行管理的? )
3.2 AD 中的Git
(AD 是原生支持 Git 的，让我们把它利用起来。)
3.3PCB 工程的协作开发
(团队协作中的冲突是如何产生的?如何解决冲突? )
2
用Git代码
2.2 Git的远端使用
Git 的真正威力其实是其社区化的多人协作的模式。要协作就一定要公开你的代码,这就需要一个代码托管服务器,并能够方便高效地在本地与远端服务器之间进行各种操作。每个公司可能都有自己的 Git 服务器,并且通常是私有的,不对外开放。只有使用公司内网或VPN 才能登录。而且有专人进行维护,还会有多重的数据备份。这对于阿里、百度这样典型的互联网公司来说,在管理上就更加谨慎和严格了。
振南公司的私有服务器是不可能拿来演示的，那就用 GitHub 吧。
我们先来尝试把前文那个本地仓库上传(push)到服务器。基本的流程是：在 GitHub 上创建一个仓库，将本地仓库与 GipHuh 上的远端仓库建立关联，通过 git 命令操作远端仓库。
首先你要在 GitHub 上注册一个账,然后单击新建库,如图 4.25 和图 4.26 所示。
图4.25 在 GitHub上单击新建仓库
这样,我们就成功创建了一个远端的仓库，如图 4.27 所示。
可以看到 GitHub 已经给出来操作方法。要注意的是,GitHub 默认使用 SSH 协议与本地仓库建立连接。但是设置 SSH 是比较麻烦的(涉及 SSH-key 的生成和添加,后面会有介绍).所以我们使用 HTTPS。具体操作如图 4.28 所示。
在填入了设备码之后,我的电脑认证通过,Git 开始将本地仓库推向 GitHub。我们可以来看看 GitHub 上新建的仓库，如图 4.29 所示。
图4.26 在 CitHb 上新建仓库
图4.27 在 GitHub上新创建的仓库
图4.28 通过设备码进行认证从而将本地仓库推到 GitHub
图4.29 成功将本地仓库推到了远端
这里的讲解似乎与网上关于 Git 的使用有些不一样。我知道网上的很多教程都是以 SSH为例来展开的，但其实 HTTPS 更加简单。
如果我们想去将别人在 GitHub 上的仓库同步到本地,又该如何操作呢?很简单,用 gitclone 即可,而且这应该是使用频率最高的命令了。我们以 GitHub 上随便一个仓库为例,把它 Clone 下来，如图 4.30 所示。
首先我们要获取 GitHub 仓库的 HTTPS 链接(如果你 Clone 的目的只是为了看一看,而不打算加人到这个仓库的维护中去,那直接 Download ZIP 就可以了),然后就可以开始 clone了,如图 4.31 所示。
图4.30 获取 GitHub仓库的 HTTPS链接
图4.31 对 GitHub上的仓库成功进行 Clone
2.3 代码拯救纪实
很多人在使用 Git 的初期,因为对其机制没有很好的理解，所以经常会犯各种错误,然后自己又无法解决,最终无奈放弃 Git。在他们心里总是对 Git 有怀疑心理:“Git 会不会把我的代码弄丢?”而且这种疑虑在莫名其妙的问题出现时，尤为强烈。
这里我可以明确地告诉大家:“放心,只要你正确的 commit 过,那你的代码就不可能丢。
以下是一个代码拯救追回的实例，大家可以看看。
有一天同事找到我,说:“我提交的代码都不见了,那是近一个星期的工作,振南你帮我看看有什么办法恢复吗?”
“别着急”,我来到他的座位前,看到 GitBash 上显示当前正处于 master 分支上,使用 gitlog 查看历史提交记录,这几天的记录都没有了。OK,一顿操作猛如虎,数据恢复我最靠谱!最后同事的小心脏终于放回了肚子里。我又给他讲解了问题所在.他这才恍然大悟。
这个实例就讲完了。“等等,你讲了些啥就讲完了?”振南开个玩笑而已。
为了方便讲解恢复数据的过程,振南在自己的电脑上复现了这个问题,如图 4.33 所示。
然后我们对第二次提交不满意,想回退到第一次提交,再继续开发。我同事的方法如图 4.34 所示。
然后我们在这个 commit id 上对代码进行开发,然后直接提交,如图 4.35 和 4.36 所示。
图4.33 某 Git仓库的commit记录
图4.34 Checkout到第一次提交时的commit id
图4.35 象征性的对代码作一些修改
图4.36 在当前commit id上对代码进行提交
提交之后,我们会发现 commit id 变了。我们原以为这些提交操作都是在 master 分支上进行的,是跟随在第一次提交之后的。但是当我们切回到 master 分支之后,我们傻眼了,如图 4.37 和图 4.38 所示。
图4.37 切到 master分支之后只看到以前的两次提交
图4.38 代码的改动不见了(这就是所谓的“数据丢失”)
我们用 git reflog 来看看 Git 在这期间都做了什么(这个命令可以查看 Git 的所有内部操作),如图 4.39 所示。
HEAD 是一个指针,它指向某一个分支。比如图 4.39 中的(HEAD ->master)就是指HEAD 指向 master 分支。当 checkout 到某一个 commit id 上之后,我们会发现 HEAD 不再指向 master 了,而是 HEAD@(2),而在提交之后又换成了 HEAD@(1),这说明我们根本就
图4.39 使用git reflog查看 Git日志
没有向 master 分支上提交代码,而是向一个隐藏的临时分支在提交。当我们在切回到 master分支时,当然看不到提交记录了。
解决的方法是:我们把后面那“无名”的提交移到一个明确的分支上来,然后将此分支与master 进行 merge 合并。
具体操作如图 4.40 所示。
图4.40 将“无名”提交合并到 master分支上来
此时我们在 master 分支就可以看到对代码的改动了,如图 4.41 所示.
造成这次“虚惊一场”的根本原因是我这个同事向 commit id 向提交代码。他对分支和commit 并没有真正的理解。一个分支是由多个 commit 组成的,我们在某一个分支上进行的每一次提交都会生成一个 commit id。这个 commit id 其实是一个固定的标签,是不可修改
图4.41 在 master分支上看到了丢失的代码回来了
的,可以理解为一个阶段性的固定版本。我们可以从每一个 commit id 新建一个分支，然后在这个分支会继承这个 commit id 的代码(说拷贝可能更好理解),我们可以在此基础上继续开发,并向这个新的分支上提交。如果我们尝试向一个 commit id 进行提交,那么 Git 会悄悄地新建一个临时分支,我们以后的提交都是在这个临时分支上的。此时,我们可以通过 git reflog 来查看 Git 到底都做了什么,从而把那些“流浪”的代码找回来,接续在我们的工作分支上。
记住:Git 会比你更珍惜你的劳动成果,在它的管理体系下,不会真正删除任何东西!
