有选择地在两个 Git 存储库之间共享更改的最佳方法是什么？
我们有一个 Git 存储库（在 Azure DevOps 中），其中包含一个库的代码，该库将在某些领域进行大量重构。但是，代码的某些区域将（几乎）保持不变。作为变化的一部分，图书馆将获得一个新名称。这就是为什么我们计划为这些更改创建一个新的存储库，以便重构的库与原始库明确分开。
重构需要一些时间，在此期间，我们将被迫维护旧版本的库并提供错误修复和可能的新功能。由于库的部分内容将保持不变，我们希望能够将这些错误修复从旧存储库合并到新存储库（反之亦然）。但是，我们不想合并所有更改，而只想合并特定的更改 - 两个存储库之间的樱桃选择。我知道这可能永远不可能，因为这两个存储库的分歧会越来越大。
对于这种情况，最好的解决方案是什么？
我想到了以下解决方案：
- 创建一个新存储库，克隆旧存储库，将该克隆的远程更改为新存储库，然后将所有内容推送到新存储库。然后在新的存储库中进行重命名和重构，并在旧的存储库中进行错误修复。如果应该将错误修复合并到新存储库，我会将我的工作副本切换到新存储库，并通过将旧存储库指定为远程来从旧存储库中挑选带有错误修复的修订版本。
- 创建旧存储库的分支，在分支中执行重命名和重构，并在原始存储库中进行错误修复。可以使用拉取请求将原始存储库中的错误修复合并到分支中，如果需要，反之亦然。我不确定这种方法是否会支持选择性挑选。我担心我只能将所有更改从原始版本合并到分支，这不是我想要的。
正如您所看到的，我使用 Git 的经验有限，我需要一些建议。提议的选项之一是可行的解决方案，还是有更好的方法来解决这个问题？
We have a Git repository (in Azure DevOps) containing code for a library which is going to be refactored heavily in certain areas. However, some areas of the code will remain (almost) unchanged. As part of the changes, the library will get a new name. This is why we plan to create a new repository for these changes, so that the refactored library is clearly separated from the original library.
The refactoring will take some time, and during that time, we'll be forced to maintain the old version of the library and provide bugfixes and possibly new features. Since parts of the library will remain unchanged, we would like to be able to merge those bugfixes from the old repository to the new repository (and probably vice versa). However, we do not want to merge ALL changes, but only specific ones - kind of cherry-picks between two repositories. I know that this may not be possible forever since the two repositories will diverge more and more.
What's the best solution for such a scenario?
I have thought of the following solutions:
- Create a new repository, clone the old repository, change the remote of that clone to the new repository, and push everything to the new repository. Afterwards do the renaming and refactoring in the new repo, and do the bugfixing in the old repo. If a bugfix should be merged to the new repo, I would switch my working copy to the new repo, and cherry-pick the revision with the bugfix from the old repo by specifying the old repo as the remote.
- Create a fork of the old repo, perform the renaming and refactoring in the fork, and do the bugfixing in the original repo. A bugfix from the original repo could be merged to the fork using a pull request, and also vice versa if required. I am unsure if this approach would support the selective cherry-picking. I fear that I would only be able to merge ALL changes from original to fork which is not what I want.
As you can see, my experience with Git is limited and I would need some advice. Is one of the proposed options a viable solution, or is there a better way to approach this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论