Git 选择性提交主回购协议的技术

假设您已从远程开源项目（例如在Github上）克隆了本地回购协议。您可以在本地回购中进行更改，添加分支机构等

您记住了以下目标：您所做的一些更改是出于您自己的目的，不会返还给主回购协议，其他更改是社区感兴趣的，例如错误修复和功能添加，以及您希望返还给主回购协议的更改

基于此，让我们假设两个主要分支：一个用于所有更改的dev proj，一个用于将子集贡献回主repo的dev comm

在一般情况下，您会知道一组给定的更改是否会进入dev comm，因此您可以将它们隔离到一个分支中

然而，在一些复杂的情况下，您不希望分支由是否应该向上游贡献更改来决定

以web应用程序的本地化为例—翻译和视图的更改等。您为它创建了一个分支，并打算将其保持为私有，但在处理它的过程中，您发现原始代码存在i18n问题，因此您可以将这些问题作为此分支工作的一部分进行修复。这些变化是从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

在处理topicA时，我们不想担心哪些部分是为社区准备的。但在它的结尾，我们希望有类似topicAcomm的东西，可以合并到devComm中并向上游推进

我的问题是，采摘樱桃是否是解决这一问题的方法，从查看文档/教程来看，这似乎是一种可行的方法。或者还有其他一些技巧，比如稍后注释代码，或者其他一些我不知道的技巧

---

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

请看一下“git rebase--On…”。对于您的示例，可以将其视为两个步骤：1）使用“rebase”将您的“i18n”更改隔离到它们自己的分支上，2）将该分支与开发项目合并。来自“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

---

然后，您可以将topicB合并到master（dev proj）上，然后再合并到topicB（dev comm）。

您可以从中获得一些想法，也在“”中详细介绍

我宁愿重新排序主题分支的历史记录，以便合并到公共分支，而不是依赖于单独的挑选（稍后可能会出现问题：请参阅“”）

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

---

自动重新排序的一个技巧是

git-rebase--interactive--autosquash

，它将重新排序并对提交进行分组（请参见“”.

很抱歉，问题是关于像topicA这样的主题分支，其中包含混合提交，有些是针对私人项目的，有些是针对社区的。在处理topicA时，我们不想担心哪些更改是私人的，哪些是社区的，我们希望以某种方式对它们进行注释，然后将它们过滤到单独的分支中。问题是关于这方面的问题和最佳实践。我所描述的方法只有在提交是连续的或在两个连续的组中时才有效。如果它们分散，那么您必须逐个选择它们。注意，很容易将带有ABCDEFGHIJ的分支转换为三个分支（如上面的master:topicA:topicB）通过连续提交（如ABCD EFG HIJ），然后重新基址--on。在交互式重新基址中，您可以重新排序提交（）。将所有的“c”提交排列在分支的顶端，然后将其重新基化到comm分支上。之后，通过额外的编辑+提交来消除“非粒度”代码。感谢您提供的信息。我将检查这些资源。好的，这是重新基化的一个典型用例—interactive.Thx。