假设您从远程开源项目(例如在 Github 上)克隆了一个本地存储库。您在本地存储库中进行更改,添加分支等。
您有以下目标:您所做的一些更改是出于您自己的目的,不会回馈给主存储库,其他更改是社区感兴趣的,例如错误修复和功能添加以及您会喜欢回馈主回购。
因此,基于此,让我们假设两个主要分支:一个用于所有更改的 dev-proj,一个带有子集的 dev-comm 将被贡献回主 repo。
在一般情况下,您会知道给定的一组更改是否会进入 dev-comm,因此您可以将它们隔离到一个分支中。
但是,在一些复杂的情况下,您不希望分支受制于是否应在上游贡献更改。
以 Web 应用程序的本地化为例——翻译和视图的变化等。您为它创建了一个分支并打算将其保密,但在处理它时您发现原始代码存在 i18n 问题,因此您将这些问题作为您在此分支上工作的一部分进行修复。这些将 WRT 更改为 i18n,您希望将其隔离并推回主存储库。
我的问题是:挑选处理这种情况的最佳方法 - 我担心尝试细化提交会分散注意力,如果我错误地做出涉及大量私人和社区的提交会发生什么更改,那么我将不得不尝试为此应用修复程序。或者是否有更好的技术,即使它涉及一些手动元素。
编辑:我将用一个粗略的草图澄清一下:p 用于本地项目,c 用于专门为社区推送到上游的更改:
Ep--Fc--Gp--Hc--Ipc(commit not granular!)--Jc topicA
/
A--B--C devProj
|
\ Q--R devComm
|
\ Fc--Hc--I2c--Jc topicAcomm
在处理主题 A 时,我们不想关心哪些部分是为社区服务的。但最后,我们希望有一些类似 topicAcomm 的东西,可以合并到 devComm 中并推送到上游。
我的问题是挑选樱桃是否是处理这个问题的方法,从检查文档/教程来看,这似乎是一种合理的方法。或者是否还有其他一些技巧,例如稍后注释代码或其他一些我不知道的技巧。
意外混合提交只是可能出现的问题之一。