gpt4 book ai didi

指示丢弃分支的 Git 约定

转载 作者:太空狗 更新时间:2023-10-29 13:21:20 27 4
gpt4 key购买 nike

场景:

A 创建了一个实验分支来解决问题。 B 产生了兴趣并想检查代码,由于懒惰,A 推送到他的 github 而不是配置他的工作站让 B 直接从他那里 pull 。

A 和 B 正在黑客攻击,C 看到 github 上的事件并克隆,急于查看发生了什么。与此同时,A 和 B 得出了一个可怕的解决方案并删除了分支。但是 C 设法把这个想法变成了很棒的东西,并且想要分享。 merge hell 开始于 C 的分支与其 merge 目标不再有共同的祖先。


我很好奇应该如何处理这种情况。

  • 是否有一个公认的分支命名约定来表明——即使被推——这个分支很可能会被完全抹去。 A 表示“如果你放弃这个,我不能保证持续幸福”的方式
  • 或者在 git 中甚至有一种方法(命令)可以让我标记分支为丢弃?
  • 无论情况如何,如果有人可以从中提取 git 历史记录,它是否永远不会接受更改?
  • A 是否应该花时间正确配置他的工作站,让 B 直接从他那里 pull 数据?因此在黑暗中进行,不让任何人知道他们在做什么。
  • 也许唯一可行的解​​决方案是良好的老式沟通方式;只是和你的同龄人谈谈。

如果其他所有方法都失败了,那么在这种情况下 C 的正确策略是什么?当您在断开连接的图中完成工作时,如何正确应用更改?

最佳答案

还没有正式的约定。

一次性分支的一个很好的例子(在 2010 年 3 月的 Git rebase 上的这篇文章中提到)是 git.git 的分支 pu

Git FAQ details :

The "pu" branch often won't fast forward because some commits have been completely deleted in it since the last time you pulled.

If you want to track it, add a plus (+) sign to the proper line in your .git/config file, like this:

[remote "origin"]
fetch = +refs/heads/pu:refs/remotes/origin/pu

Which tells git to deal with the problem for you by simply skip the fast forward check (overwriting your old ref with the new one).
Or you can just delete that line completely if you don't want to track the pu branch at all.

It is conceivable that in future versions of git we might want to be able to mark some branches "this is expected to be rewound" explicitly and make the clone operation to take notice, to give you the plus sign automatically.

所以一个想法是主动阻止(通过钩子(Hook))任何对那些被丢弃的分支的推送:

  • 只读
  • 仅由一名管理员更新。

关于指示丢弃分支的 Git 约定,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/2385971/

27 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com