没有什么好方法可以做你想做的事。我还建议您重新检查一些假设，因为当您说“...当我在 [某个分支] 时，我确实需要生成的[任何东西]...”（强调），这告诉我您可能不会让您的源代码控制系统只是一个源代码控制系统。
仅仅说“保持不同”的问题.gitignore在每个分支上”是，（1）它没有考虑到您将定期创建需要的分支这一事实not忽略HEX文件，来自需要忽略HEX文件的分支； (2) 版本之一.gitignore将被视为对另一个的修改，因此例程合并可能会默默地将更改转移到不应获取它的分支中。
您可以使用 gitflow 提供的结构来使其更易于管理，特别是如果您围绕分支和合并活动编写脚本release分支机构。你可以将十六进制文件保存在你的.gitignore，但在每个上暂存第一次提交时强制添加它release分支。这里有几个关键点：
1) All .gitignore确实是说，如果存在与某些路径模式匹配的未跟踪文件，这些文件应该默认情况下保持未被追踪。一旦一个文件is跟踪,.gitignore没有进一步的影响。
2）如点（！）中所使用的，“跟踪”仅意味着“在索引中”。如果文件正在提交A但不在提交中B，然后在提交之间移动A and B通常会更新索引，以便文件在每次签出时相应地被跟踪或未跟踪。但这确实会产生一个问题...
2a) 如果你在develop，其中 HEX 文件是.gitignored，但你的工作树中有一个未跟踪的 HEX 文件；然后你git checkout master (where master does有一个 HEX 文件），git 会忽略你未跟踪的 HEX 文件并允许签出，导致你的本地版本被覆盖。您将无法恢复 HEX 文件。再说一遍，既然你说文件已生成，这可能没什么大不了的；但这是需要记住的事情。
3) 您可以使用以下命令覆盖保持被忽略的文件不被跟踪的默认行为-f的选项git add, as in
git add -f path/to/HEX/file
如果您遵循 gitflow 合并模式，那么您可以在每次创建时简单地执行此强制添加release分支，覆盖忽略规则release分支机构（以及master，它由来自的合并组成release分支机构）。到目前为止，一切都很好。
当然，这些合并到发布确实会带来问题，因为每次他们都会看到新的 HEX 文件与旧的文件冲突（因为据 git 所知，它们是独立创建的。本质上，你想要的是默认合并策略的“theirs”选项的行为（如果存在冲突，则从我要合并的分支中获取版本）。您可能不想使用该选项except对于那个文件；你可以使用.gitattributes maybe.
如果你这样做的话也会有一个问题hotfix分支，因为它们是从master（所以他们会有十六进制文件）但你将它们合并到两者master and develop。因此每个修补程序都有将 HEX 文件“泄漏”到系统中的风险develop分支（之后您必须再次删除它才能使忽略规则发挥作用）。
如果这看起来很麻烦，确实如此。同样，在我看来，这是因为您正在违背源代码控制工具的原则。需要澄清的是，这些问题并不是我提出的解决方案所特有的，而是会随着any问题的解决方案如所述。如果 git 发现该文件在每个发布分支上弹出，但在开发或功能分支上不存在，则合并到 masterwill冲突和修补程序will复制文件进行开发是有风险的，无论您是如何到达那里的。
