我使用GitFlow作为git工作流程。我为电子微控制器编程。
虽然我在开发分支上，我不需要跟踪或提交编译的HEX文件，我只需要代码。但是当我在发布或主分支上时，我确实需要提交生成的HEX文件。
目前我“精神上”忽略了HEX文件，并且只在我需要的时候暂停并提交它。但它有点困扰，有它在那里，总是看着你，问“为什么所有其他文件，但不是我”......我觉得有点内疚，我宁愿不在那里看到它除非我在适当的分支上。
有什么建议吗？
答案 0 :(得分：1)
没有一个很好的方法可以做你想要的。我还建议你重新检查一些假设，因为当你说“...当我在[某个分支]时，我确实需要生成 [任何] ......”（强调添加） ，这告诉我你可能不会让你的源控制系统只是一个源控制系统。
只是说“在每个分支上保持不同.gitignore”的问题是，（1）它没有考虑到您将定期创建需要不从需要忽略HEX文件的分支中忽略HEX文件; （2）.gitignore的其中一个版本将被视为对另一个版本的修改，因此例程合并可能会默默地将该更改带入一个不应该得到它的分支。
您可以使用gitflow提供的结构使其更易于管理，尤其是在围绕release分支编写分支和合并活动的脚本时。您可以将HEX文件保留在.gitignore中，但在每个release分支上暂存第一次提交时强制添加它。这里有几个关键点：
1）所有.gitignore都表示，如果存在与某些路径模式匹配的未跟踪文件，那么默认情况下 的文件仍未跟踪。 跟踪文件后，.gitignore没有进一步的效果。
2）如点（！）中所用，“跟踪”仅表示“在索引中”。如果文件在提交A但未在提交B中，则在提交A和B之间移动通常会更新索引，以便跟踪或取消跟踪文件每次结账，相应。 但这确实会引起问题......
2a）如果你在develop，那里的HEX文件是.gitignore d，但你的工作树中有一个未跟踪的HEX文件;然后你git checkout master（其中master 有一个HEX文件），git将忽略你未跟踪的HEX文件并允许结帐，导致你的本地版本被覆盖。您将无法恢复HEX文件。同样，既然你说文件是生成的，这可能不是什么大问题;但要记住这一点。
3）您可以使用-f的{{1}}选项覆盖保持忽略文件未跟踪的默认行为，如
git add如果您遵循gitflow合并模式，那么您可以在每次创建git add -f path/to/HEX/file
分支时执行强制添加，覆盖release分支上的忽略规则（以及{{1 }，由release分支的合并组成。到目前为止一切都很好。
当然，那些要发布的合并确实存在问题，因为每次他们都会看到新的HEX文件与旧版本冲突（因为它们是独立创建的，就像git所知道的那样。你想要什么，本质上，是默认合并策略的“他们的”选项的行为（从我正在合并的分支中获取版本，如果存在冲突）。您可能不想使用除之外的那个选项那个文件;你可以使用master来安装一些文件。
如果您有release个分支，也会出现问题，因为这些分支来自.gitattributes（所以他们将拥有HEX文件），但您将它们合并到hotfix和master。因此，每个修补程序都有将“HEX”文件“泄漏”到master分支中的风险（之后您必须再次将其删除以使忽略规则正常工作）。
如果这看起来很麻烦，那就是。同样，在我看来，这是因为你正在反对源代码控制工具。并且澄清一下，这些问题并不是我提出的解决方案所特有的，而是会出现任何解决问题的方法。如果git看到文件在每个发布分支上弹出，但在开发或功能分支上不存在，则合并到主将冲突，并且修补程序将冒险将文件复制到无论你到底在哪里，都要发展。