有选择地提交到主存储库的技术

Question

假设您已经从远程开源项目（例如在Github上）克隆了一个本地存储库。在本地存储库中进行更改，添加分支等。

您

牢记以下目标：您所做的一些更改是为了您自己的目的，不会贡献回主存储库，其他更改是社区感兴趣的，例如错误修复和功能添加，以及您希望贡献回主存储库的更改。

因此，基于此，让我们假设两个主要分支：一个用于所有更改的 dev-proj，一个包含要贡献回主存储库的子集的 dev-comm。

在一般情况下，您会知道一组给定的更改是否会进入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中并推送到上游。

我的问题是樱桃采摘是否是处理此问题的方法，这似乎是检查文档/教程的合理方法。或者是否有其他一些技巧，例如稍后注释代码或其他一些我不知道的技巧。

意外混合提交只是可能出现的一个问题。

Answer 1

你可以从原始的 git 分支管理中获取一些想法，在"gitworkflows 手册页"中也有详细说明。

我宁愿重新排序主题分支的历史记录，以便合并到公共分支，而不是依赖单个挑选（以后可能会有问题：请参阅"如何在 git 中合并特定提交"）

任何

变基都会迫使您的团队将他/她的主题分支重置为新排序的主题分支，但这比要求社区（更大的人群）重置任何内容更易于管理。

自动重新排序的一个技巧是git rebase --interactive --autosquash这将重新排序和分组提交（请参阅"修剪 GIT 签入/压缩 GIT 历史记录"。

Answer 2

看看 'git rebase --onto ...'。 对于您的示例，可以将其视为两个步骤：1） 使用"rebase"将您的"i18n"更改隔离到它们自己的分支上，以及 2） 将该分支与 dev-proj 合并。 从"git help rebase"中，一个例子：

If we have the following situation:
                                         H---I---J topicB
                                        /
                         E---F---G  topicA
                        /
   A---B---C---D  master
  then the command
       git rebase --onto master topicA topicB
   would result in:
                        H'--I'--J'  topicB
                       /
                       | E---F---G  topicA
                       |/
   A---B---C---D  master

然后，您可以将主题B

合并到master（dev-proj）上，然后再合并到主题B（dev-comm）。