Git 使用分支或单独的存储库来维护多个不向后兼容的代码版本的正确方法是什么？

我为Revit编写外接程序。这些外接程序依赖于Revit API库。这些库随Revit的每个新版本（2018、2019、2020等）而变化。不幸的是，它们不向后兼容，因此我无法从2018年起将我的外接程序用于2020年。这意味着我在2018年、2019年和2020年分别维护自己的代码库。我目前正在使用pull请求，以便如果我在2018年进行更改，我可以将其移至2019年和2020年。问题是，当收到请求时，它会将2019/2020年的图书馆更新回2018年的图书馆。然后我必须返回并确保它引用了正确的库

---

每次需要将更改推送到其他版本时，我应该如何做才能避免此问题？

是否确定您的2018插件不能在Revit 2020中使用

在许多情况下，如果不是大多数的话，情况恰恰相反

通常，也可以在更高版本中使用为早期版本的Revit编译的外接程序

如果要调用在不同版本之间更改的Revit API功能，可以通过为早期版本的Revit编译并添加.NET运行时功能来处理，以在运行时检查是否调用旧版本或新版本的Revit API。可以在运行时为新版本动态更新更改的调用

查看完整的实现示例

---

尽管如此，我仍然完全同意你的问题本身；在许多情况下，每个版本的Revit都需要一个单独的外接程序的干净更新版本，以避免复杂性并增强代码可读性。因此，我完全同意Ôrel为每个版本维护一个单独的分支，并将更新合并到其他分支。

我写的外接程序也有同样的问题。由于API的变化，我必须根据与插件相关的年份制作单独的版本。我为每个版本设置了一个单独的项目，并共享代码和库，以减少重复代码的数量。不幸的是，我在创建第二个版本之后设置了这个，所以并不是所有的代码都被正确地细分。不过，这应该会让您了解如何进行设置。您可以在github存储库中看到这一点：

---

注意，虽然这确实减少了代码量，但是对于共享代码的更改需要考虑每一个版本，都需要额外的工作。p> 每个版本都有一个分支，当一个分支上的拉请求被接受时，就可以在所有其他分支上合并，以修复不兼容（如果需要）。