假设我想要在GitHub上修复一个开源项目,以下是我的工作流程:
1. 在GitHub上fork源项目 2. 将fork的项目克隆到本地 3. 从主分支创建一个主题分支 4. 进行修改(这里略去不必要的细节) 5. 将主题分支推送到GitHub上 6. 向原始项目提交拉取请求
如果我已经多次这样做了,我就会有一些主题分支,如issue#123和issue#456。除了主干之外,原始项目还有发布分支,例如1.0、1.1等。
我有自己独立的项目,使用的是此开源项目的1.1版本。我不想构建针对开源项目的"master",因为它尚不稳定。我需要的是一个本地构建的开源项目的1.1分支,其中包括我的问题#123和问题#456的解决方案。
我目前正在执行的操作是创建一个名为my-1.1的本地分支(从1.1分支中创建),将我的主题分支中的修复程序挑选出来,然后构建并将结果用于我的独立项目。
我不确定这里是否100%应该使用cherry-picking,但合并似乎不正确,因为我不希望"my-1.1"分支中流入来自主干之后的所有更改(这些更改存在于我的主题分支中)。这是否是最佳方法?需要注意的事项有哪些?
我唯一能想到的其他方法是为每个修复创建两个重复的主题分支,一个从主干创建,另一个从1.1创建。然后,我可以将基于1.1的主题分支合并到my-1.1中,而不是从基于主干的主题分支中挑选提交。但是这似乎很麻烦。
1. 在GitHub上fork源项目 2. 将fork的项目克隆到本地 3. 从主分支创建一个主题分支 4. 进行修改(这里略去不必要的细节) 5. 将主题分支推送到GitHub上 6. 向原始项目提交拉取请求
如果我已经多次这样做了,我就会有一些主题分支,如issue#123和issue#456。除了主干之外,原始项目还有发布分支,例如1.0、1.1等。
我有自己独立的项目,使用的是此开源项目的1.1版本。我不想构建针对开源项目的"master",因为它尚不稳定。我需要的是一个本地构建的开源项目的1.1分支,其中包括我的问题#123和问题#456的解决方案。
我目前正在执行的操作是创建一个名为my-1.1的本地分支(从1.1分支中创建),将我的主题分支中的修复程序挑选出来,然后构建并将结果用于我的独立项目。
我不确定这里是否100%应该使用cherry-picking,但合并似乎不正确,因为我不希望"my-1.1"分支中流入来自主干之后的所有更改(这些更改存在于我的主题分支中)。这是否是最佳方法?需要注意的事项有哪些?
我唯一能想到的其他方法是为每个修复创建两个重复的主题分支,一个从主干创建,另一个从1.1创建。然后,我可以将基于1.1的主题分支合并到my-1.1中,而不是从基于主干的主题分支中挑选提交。但是这似乎很麻烦。
git merge-base
来查找它们最后一次共同点并从那里创建一个新分支。 - Karl Bielefeldt