2

假设您从远程开源项目（例如在 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 中并推送到上游。

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

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

4

2 回答 2

1

看看'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

然后，您可以将 topicB 合并到 master (dev-proj) 并返回 topicB (dev-comm)。

于 2012-04-15T03:03:55.510 回答
1

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

我宁愿重新排序您的主题分支的历史记录，以便合并到公共分支，而不是依赖单独的樱桃采摘（稍后可能会出现问题：请参阅“如何在 git 中合并特定提交”）

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

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

于 2012-04-15T13:03:57.930 回答