
338
|
第
13
章
你还可以通过将修改后的代码检入 Git,将最新的项目文件作为新分支导入,然后使用
Git 的内置合并功能来处理集成,从而获取更高级的功能。由于我们自己还没有使用过
这种方法,且对 Git 的了解不够专业,因此我们还不能提供有关这种方法的建议。
此过程与使用更传统的代码生成方法执行相同的操作的最大区别在于,代码仍然被分成
许多逻辑文件,这些文件的路径随着时间的推移保持不变。典型的代码生成会将所有源
代码链接到一个文件中,这使得合并或跟踪更改非常困难,因为对顺序或布局的微小更
改会使历史比较无法进行。
有时你可能希望进行另一个方向的更改移植,即从项目文件合并到主源代码树。这个主
要的源代码树不必是 GitHub 上的官方代码仓库,也可能是你在本地维护且不分发的版
本分叉(fork)。我们很乐意在主代码仓库中通过拉取请求(pull request)接受修复和
升级改动,但我们知道专用的嵌入式开发并不总能做到这一点,因此我们也很乐意帮助
保持分支状态良好。要注意的关键事项是,你需要尝试为开发文件保留单个“信息源”
(source of truth)。尤其是如果你有多个开发人员,则很容易在项目存档中对源文件的不
同本地副本进行不兼容的更改,这将使更新和调试成为一场噩梦。无论是内部共享还是
公共共享,我们强烈建议你使用源代码控制系统,该系统应具有每个文件的单个副本,
而不是检入多个版本。
若要将更改迁移回“信息源”仓库,则需要跟踪已修改的文件。如果你没有这些信息,
可以随时返回到最初下载或生成的项目文件,然后运行 ...