git 策略将一组提交限制在特定分支
我需要经常在 dev 和 master 之间进行合并。
我还有一个提交,我只需要应用于开发人员,以便在本地工作。
早些时候,我只从 dev 合并到 master,所以我有一个分支 production_changes,其中包含 dev 特殊提交的“撤消提交”。从大师那里,我合并了这个。以前工作得很好。
现在,每次我从 dev 合并到 master 时,反之亦然,我都必须一次又一次地挑选并应用相同的提交:(。这很丑。
我可以采取什么策略,以便我可以在两个分支之间无缝合并,但仅在其中一个分支上保留一些更改?
I need to merge between dev and master frequently.
I also have a commit that I need to apply to dev only, for things to work locally.
Earlier I only merged from dev to master, so I had a branch production_changes that contained the "undo commit" of the dev special commit. and from the master, I merged this. Used to work fine.
Now each time I merge from dev to master and vice versa, I am having to cherry-pick and apply the same commit again and again :(. Which is UGLY.
What strategy can I adapt so that I can seamlessly merge between 2 branches, yet retain some of the changes only on one of those branches?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
我会推荐合并驱动程序(在
.gitattributes
文件内的合并指令中声明的脚本),以防止某些文件受到给定提交的影响。(例如,如果某些文件不得修改,则该驱动程序将像 “保留我的”合并。这已用于 通过示例仅合并特定目录,或跟踪如何配置文件按分支进行管理。)
OP 补充道:
聪明的解决方案?...
好吧,我可以建议
git rerere
(重用记录的冲突合并解决方案:如果您合并到开发触发冲突,并且如果该冲突的解决方案是您有效地取消该合并,则可以记录该解决方案,以便在下次合并时自动重复它。请参阅 Rerere Your Boat... by Scott Chacon 了解此命令的更多信息。
I would recommend a merge driver (scripts declared in a merge directive within a
.gitattributes
file) in order to prevent certain files to be affected by a given commit.(for instance, if certain files must not be modified, that driver would be as simple as a "keep mine" merge. That has been used to merge only specific directories by example, or to track how config files are managed per branch.)
THE OP adds:
Clever solution?...
Well I can propose
git rerere
(reuse recorded resolution of conflicted merge: if you merge to dev trigger a conflict, and if the resolution of that conflict is you effectively cancelling that merge, you can record that resolution, in order to have it automatically repeated during the next merge.See Rerere Your Boat... by Scott Chacon for more in this command.
对 git 撒谎:在一个单独的分支中进行差异,该分支植根于“dev”分支的分支点。然后将其“合并”到 master 中,而不实际更改 master:类似 git merge -s ours devfix-branch 的东西(您在 master 上执行此操作)
然后返回到
dev
并正常合并:git merge devfix-branch
。现在dev
和master
都会认为他们已经有了 devfix,你可以继续合并到 master。留给读者作为练习,看看这是否真的有效,或者可以使其有效。
Lie to git: make the diff in a separate branch rooted at the branch point of your 'dev' branch. Then "merge" it into master without actually changing master: something like
git merge -s ours devfix-branch
(you do this onmaster
)Then go back to
dev
and merge normally:git merge devfix-branch
. Now bothdev
andmaster
will think they already have the devfix, and you can continue to merge to master.It is left as an exercise to the reader to see if this actually works, or can be made to work.
我会使用开发存储库中的本地分支(即从未被推送到任何地方)来执行此操作,每当我从 master 拉取时,我都会将其重新设置为开发分支的顶部。虽然不是很无缝,但我认为这比挑选樱桃要好一点。
I'd do this with a local branch (i.e. which was never pushed anywhere) in the dev repo which I'd rebase to the top of the dev branch whenever I pulled from master. It's not quite seamless, but I think it's a little better than cherry-picking.