振南技术干货集：研发版本乱到“妈不认”? Git!（4）

注解目录

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 工程的协作开发

(团队协作中的冲突是如何产生的?如何解决冲突? )

上面振南讲解了如何使用 Git 来对软件代码进行管理。关于 Git 被最频繁问到的一个问题是:“Git 能不能用来作 PCB 资料的管理?”答案是肯定的。

我先来问广大硬件工程师们一个问题:“你们是如何管理 PCB 工程的版本的呢?”以我这么多年的经历所看到的,很多工程师和公司更在乎的是 PCB 相关资料的留存和安全(就是说有就行,顶多简单地整理一下),在版本管理上似乎并不太在意,或者说没有什么好的办法。关于硬件资料的版本,更多是依赖于工程师自身的素养。比如统一整理到某种存储介质中,可以是一块硬盘,可以是一台设置了权限的共享计算机,或者一个 NAS 服务器,也可以是一个类似于 seafile 的网盘。

对于这些资料的追溯,则要靠完整的技术文档。这样的管理方式,看似严谨,硬件资料都在公司的掌控之中,但实际上最终难免落得个版本凌乱,七零八落的下场。很多时候,你面对着众多的 PCB 版本,并不能确定哪一个是最终可用于生产的版本,因为往往并不是最新的版本就是可用的版本。

OK.那我们向硬件也引人 Git 这一版本管理利器.来看看通过它如何来管理硬件版本。

用Git 管理硬件PCB

Git的增量式管理

Git对于文件的管理采用的是增量式管理,如图4.42所示。

图4.42 Git的增量式文件管理

Git 在文本管理上的优势是显而易见的。但是像 PCB、Word、PDF 等这些文件,都是二进制的,不同版本的文件相同之处比较少,此时再用增量式管理,基本无异于文件拷贝。所以,用Git 管理二进制文件,会让仓库体积比较大。而且,二进制文件是没法直接合并的。不过,这些并不妨碍我们使用 Git 来进行管理。因为 Git 针对二进制或者大文件有自己的一套管理方法(比如压缩或者 LFS,大家可以去百度一下)。

我向很多硬件工程师推荐了 Git,让他们用来管理 PCB 资料的版本。但是他们反映最多的问题是:不太适应纯命令行的操作方式,那些命令总是容易忘。这让他们产生了抵触心理所以我仔细研究了 AD 对 Git 的界面化支持。

3.2 AD中的 Git

鉴于 Git 的广泛应用,很多开发环境都已经与 Git 无缝衔接,而并不需要涉及太多的命令行操作。AD(Altium Designer)作为最著名的 EDA 工具之一,自然是支持 Git 的。

1.本地化操作

振南以一个 PCB 工程为例来进行介绍,如图 4.43 所示。

首先创建一个本地仓库 git init,如图 4.44 所示。

接下来我们的操作基本上都在 AD 软件中来完成(本章的讲解基于 AD 22)。单击右键PCB 工程文件,将其添加到仓库中来,如图 4.45 所示。

接下来,我们尝试将整个 PCB 工程进行提交,如图 4.46 所示

在 Comment 中可以填入关于此次提交的一些说明,这类似于 git commit-m,如图 4.47所示

随后我们可以看到工程视图中的文件右边出现了图标,如图 4.48 所示。

这种图标的意思是“Ahead of server”,即等待推到远端仓库。这是因为刚才只进行了commit 而没有 push,等后面我们设置了远端仓库的链接,就可以执行 push 了。

我们尝试对某个文件进行修改，如图 4.49 所示。