什么是.o文件或构建版本控制的最佳实践?

时间:2017-12-21 03:35:25

标签: git makefile build version-control

我有一个C项目源(本例中是Linux内核)和Makefile。

我觉得这很痛苦,因为我做了修改,我在分支之间切换,然后我忘记了这些目标文件与哪些提交有关。

我可以在构建过程中自动进行版本控制吗?

例如(我认为可能是一个很好的工作流程,也许它很愚蠢):

  1. make

  2. 之前强制我确保git work spcace是干净的
  3. 自动保留构建版本。将一个构建与目标文件和源文件相关联。

  4. 我可以查看任何版本

  5. 我可以知道哪些.o文件是最新的(与源代码工作空间相比)。与git status

  6. 类似

    但最重要的是,源代码git树无法受到干扰。

3 个答案:

答案 0 :(得分:2)

一个常见的解决方案是在人工制品中嵌入信息以识别它。

例如,如果您有许多控制编译器的-D parameter=value设置,请将它们放在一个字符串中。

const volatile static char build[] = "parameter PARAMETER has value " PARAMETER;

然后您可以拥有将此字符串返回给调用者的代码,或者您只需使用stringsless检查二进制文件即可查看嵌入其中的信息。

有关详细信息,请参阅Does gcc have any options to add version info in ELF binary file?

答案 1 :(得分:1)

由于.o文件是C编译器生成的目标文件(来自C项目的输出文件),不需要对git repo中的.o文件进行版本控制

您只需要管理git仓库中的源代码(例如C项目和Makefile)。

对于输出文件,您应该在.gitignore

中忽略它们
touch .gitignore
echo **/*.o >> .gitignore
git add .
git rm **/*.o --cached 
git add .
git commit -m 'ignore .o files'
git push

答案 2 :(得分:1)

关于目标文件的最佳实践是git-ignore它们:

echo *.o >> .gitignore

关于使用分支构建流程的最佳实践是为不同的分支建立单独的长期运行工作:

git clone -b branch1 master-repo project-b1
git clone -b branch2 master-repo project-b2
cd project-b1
make
cd ../project-b2
make

不要在这些工作区中切换分支。

相关问题