git 策略将一组提交限制在特定分支

发布于 2024-08-27 10:27:07 字数 293 浏览 2 评论 0原文

我需要经常在 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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

梦幻之岛 2024-09-03 10:27:07

我会推荐合并驱动程序(在 .gitattributes 文件内的合并指令中声明的脚本),以防止某些文件受到给定提交的影响。
(例如,如果某些文件不得修改,则该驱动程序将像 “保留我的”合并。这已用于 通过示例仅合并特定目录,或跟踪如何配置文件按分支进行管理。)

OP 补充道:

但我更多地寻找一种聪明的解决方案(如果存在的话),例如“创建一个仅具有撤消提交的分支并将其应用于master,在dev上伪造它”

聪明的解决方案?...
好吧,我可以建议 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:

But I am looking more for a clever solution, if one exists, like "create a branch that has the undo commit only and apply it to master, fake it on dev"

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.

謸气贵蔟 2024-09-03 10:27:07

对 git 撒谎:在一个单独的分支中进行差异,该分支植根于“dev”分支的分支点。然后将其“合并”到 master 中,而不实际更改 master:类似 git merge -s ours devfix-branch 的东西(您在 master 上执行此操作)

然后返回到 dev 并正常合并:git merge devfix-branch。现在 devmaster 都会认为他们已经有了 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 on master)

Then go back to dev and merge normally: git merge devfix-branch. Now both dev and master 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.

昔梦 2024-09-03 10:27:07

我会使用开发存储库中的本地分支(即从未被推送到任何地方)来执行此操作,每当我从 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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文