我是一个从事相当大项目的唯一开发人员。我在master
进行了几项重要更改,我即将恢复在feature
分支机构上工作,该分支机构已落后于优惠政策。 feature
分支确实需要master
的更改,但我不希望将更改合并到master
,直到feature
上的工作准备好发布。我认为这是一个相当简单的变基,但我不确定。下面是我的情况的一个非常简化的版本(实际历史更长)。
* 0e109d5 - (HEAD, origin/master, origin/HEAD, master) latest commit
* 9188511 - major schema change
| * d3472a5 - (origin/feature, feature) feature branch commit
| * 6c36837 - Start of feature branch
|/
* 80d93a8 - Base commit
feature
推送到遥控器以进行保管,这对于变基通常是一件坏事。但由于它还没有与其他任何人共享,我可以简单地删除远程分支并继续它从未存在过吗?我的remote
仅用于离线存储和安全(它是一个普通的git服务器,而不是github)。master
重新绑定到feature
,然后继续处理feature
而不将master
快速转发到最后一个功能分支提交?feature
几乎需要master
中的所有更改。HEAD
并尝试将其应用到feature
。任何建议表示赞赏。我喜欢git,但我还没有变相的经历。
答案 0 :(得分:9)
由于您的远程feature
分支仅仅是出于安全保护目的而尚未与其他任何人共享,因此删除分支或强制推送它肯定是安全的。您可以在feature
上的分支master
重新定位当前的工作,并继续处理它:
# while staying at feature branch
git rebase master
根据master中的更改,您可能必须在rebase期间解决一些冲突。
更新远程安全保护分支(除了您自己以外没有人见过):
git push -f origin feature
历史将如下:
* newsha1 - (feature, origin/feature) feature branch commit
* newsha2 - Start of feature branch
* 0e109d5 - (HEAD, origin/master, origin/HEAD, master) latest commit
* 9188511 - major schema change
* 80d93a8 - Base commit
从本质上讲,提交历史记录会线性增长,就像您在feature
中引入更改后才开始master
上的工作一样。
答案 1 :(得分:5)
我认为你想要的是rebase
feature
到master
。只是做:
git rebase master feature
如果您目前在feature
分行,只需:
git rebase master
对于你的问题:
因为你是唯一的开发者,所以它很重要。在rebase
之后,只需使用-f
或--force-with-lease
推送到您的远程分支。后者更安全,但对于唯一的开发者来说没有区别。
git push --force-with-lease origin feature
是的,您现在不需要快速转发主人。完成feature
的工作后,您可以执行此操作。您可以使用--ff-only
仅允许快进合并,以保持历史记录的线性。
git checkout master
git merge --ff-only feature
是的,此处不需要cherry pick
。
无需使用补丁。 Patch
用于将您的更改分发给其他人。
PS。 git
与patch
非常友好。您可以按照以下方式执行此操作。
git diff > some.patch
git apply some.patch
或者
git diff > some.patch
patch -p1 < some.patch
或者
git diff --no-prefix > some.patch
patch -p0 < some.patch
答案 2 :(得分:1)
对我来说似乎只是想将master合并到你的功能分支中?
git checkout feature-branch
git merge master
将尝试将master中的所有提交移动到您的功能分支中,以便您可以在那里处理冲突/合并问题,而不会触及master
的当前状态。