我正在寻找一种方法来实现JIRA或Confluence等软件的配置管理解决方案，这些解决方案可以作为存档，但您必须修改一些配置文件或添加丢失的jar文件。
每次出现新版本时，您都必须重新应用更改。
显然我正在考虑使用补丁队列，但在这种情况下它不能很好地工作，因为归档通常超过200 MB而且大多数二进制文件都是更改，所以如果你把它们放在SCM中它的大小很容易变得太快了。此外，没有必要将这些文件保存在repo中，重要的只是更改，文件添加（可以是二进制）或文本文件更改。
实现此目的的正确方法是什么，以便在我有新版本时可以自动执行升级/修补。显然，如果应用补丁失败，我可以停止自动化过程，但根据对配置文件所做的更改，这种情况的变化几乎为零。
注意：如果可能，我倾向于使用git来跟踪这些变化。
答案 0 :(得分：1)
如果上游不使用git，处理此问题的最佳方法是使用称为供应商分支的东西手动复制该功能（分支的实际名称无关紧要，我将其称为“上游”，但在进行搜索时，我认为供应商分支是艺术术语。
最好之前进行任何本地修改，以便git能够跟踪正在发生的事情。如果你可以重写历史记录（强制推送，让其他人基本上都重新投入或重新投入），那么你可以在之后做一些事情（有一些更棘手的方法，我不建议这样做。）
这样做的方法是：
git init创建git存储库git add -Af .（假设这是一个真正的新解包，其中没有任何不需要的文件）git commit -m "Some text describing where you got the source code, how the vendor identified it, etc" git branch -m master upstream将新主持人命名为稍后，供应商会发布新版本。然后你。
git status和git stash -a以及朋友确保所有内容（已跟踪，未跟踪，无论如何）已提交，存储或删除。git checkout upstream find . -maxdepth 1 -mindepth 1 ! -name .git -print0 | xargs -0 rm -f清理所有内容的目录。git add -Af .; git commit -m "similar description as above"将提交供应商信息git checkout master; git merge upstream将合并供应商所做的更改。你经历了正常的冲突解决。如果您希望将修复程序发送回供应商，请从供应商处新建一个分支，然后将该修补程序合并回主服务器。您可以向该供应商发送该补丁，如果他们拿起它，一切都会很好，一切都应该自动运行。如果他们修改它，您将不得不正常解决冲突。但是，关键在于供应商分支本身应始终保持原始状态。
如果要忽略二进制文件并且只处理配置文件，可以在执行供应商分支提交之前将二进制文件添加到.gitignore（并且不要将-f用于git add -A）。