2

我有另一个组织的存储库的一个分支。我在 repo 中的最新标签，它不是头部，我已经从该标签创建了一个永远不会被推送到上游的分支。这就是为什么我认为分支是私有的。

我已经对我的私人分支做出了承诺，并在我的生产环境中使用了该代码。当对上游存储库进行新标记时，我希望能够提取他们的更改。

但是，我希望始终将我的提交保持在最后一个标签之上的整洁堆栈中。那时我不想合并，因为我的提交最终会在历史上很久很久，我希望看到它们就在最前面，这样当我在我的存储库上使用某些工具时，我可以轻松地使用它们。

所以真的，我想要一个“浮动”分支，当我将上游更改带到我的存储库时，我可以移植到任意点。

[编辑] 但是，我不相信我可以使用变基，因为这是一个历史重写操作。你看，我在两台机器上使用我的存储库，我的开发和生产。我在开发机器上提交，推送到 github，然后拉到生产环境。所有这些都与我最初派生的上游存储库的更改无关。

我对移植、摘樱桃或任何其他可能适合的工具并不完全清楚。不管它是什么工具，我认为它不应该重写历史。从我的阅读中，我看到在 push 时重写 repo 历史是一个禁忌。所以我不确定我应该使用什么命令来移植一个分支而不重写历史。

如果我使用的是 mercurial，我可能会考虑使用版本控制的 mq。我不知道 git 的类似解决方案是否有，或者是否有另一种更适合 git 的工具。

[编辑]

在评估了我在这里得到的回复后，我最终确定挑选樱桃是正确的答案。在所有情况下，rebase 都会删除历史记录，并且由于这是一个共享存储库，因此删除历史记录是不可接受的，至少根据我读过的每个来源都是如此。

然而，Cherry-picking 会将提交复制到我的工作树，而不会将其从其原始位置删除。所以我可以将我的更改副本放在最新标签的顶部，并将它们整齐地堆放在一起。

作为记录，我还尝试使用 Mercurial 执行此操作，方法是使用 hg-git 扩展，它允许您使用 hg 克隆 git 存储库。这有利有弊。最大的缺点是，我用完后，它无法推动。hg-git 在那之前一直工作得很愉快，然后告诉你它不支持 hg 1.9。假的，至少可以这么说。另一个缺点是克隆和提取大量更改非常慢。但是，mq 和 TortoiseHg 的合并冲突解决工具是对 git cherry-pick 和 Smartgit 的合并冲突解决的巨大改进。我希望 hg-git 可以工作。

我想最后，“浮动”对于我的更改分支来说并不是一个很好的描述，因为结果是复制它而不是移动它。抱歉我的描述可能很糟糕，我仍在弄清楚这些选项到底是什么。谢谢您的帮助。

4

2 回答 2

3 
git fetch
git rebase --onto latesttag previoustag yourbranch

必须处理冲突，并且完全取决于您对可能已从一个标签更改为下一个标签的文件所做的事情。特别是，如果有人删除了您更改的某些代码，您将必须解决这个问题并确保您更改的代码现在可以应用到其他地方。对此没有灵丹妙药。一旦你解决了你的冲突并且一切正常，

git add -A
git rebase --continue

冲洗重复。

另外，如果您这样做只是为了能够部署，“浮动分支”可能不是处理这个问题的最佳方法。考虑这些替代方案：

  1. 部署操作文件以确保部署工作的脚本。
  2. 在填充工作目录时修改文件的 smudge/clean 脚本。( https://git-scm.com/book/en/v2/Customizing-Git-Git-Attributes#_keyword_expansion )

您的浮动分支似乎只是为了您自己的环境而存在，因此不应成为项目的一部分。

于 2011-12-28T20:51:27.160 回答
0

你描述了git rebase --onto这里的工作。

设想：

  • git fetch从遥控器；
  • 安全起见，制作一份新副本git branch newbranch currentbranch：
  • 假设您当前基于的旧标签是oldtag，而新标签是newtag;
  • “移植”：git rebase --onto newtag oldtag newbranch；
  • 必要时解决冲突；
  • git branch -D currentbranch;
  • git branch -m newbranch currentbranch.

但是，至于重写历史，您将——您的分支，而不是原始存储库，您没有对它的写入权限，是吗？

于 2011-12-28T20:40:58.353 回答