如何在git中实现“浮动”的私有分支何时与上游合并？
我有另一个组织的存储库的分支。我位于存储库中的最新标签，这不是头部，并且我已经从该标签创建了一个分支，该分支永远不会被推送到上游。这就是为什么我认为该分支机构是私有的。
我已提交到我的私人分支，并在我的生产环境中使用该代码。当上游存储库添加新标签时，我希望能够提取它们的更改。
但是，我希望始终将我的提交整齐地堆叠在最后一个标签的顶部。然后我不想合并，因为我的提交最终会留在历史中，我希望看到它们就在最上面，这样当我在存储库上使用某些工具时，我可以轻松地使用它们。
所以，我真的想要一个“浮动”分支，当我将上游更改带到我的存储库时，我可以将其移植到任意点。
[编辑] 然而，我不相信我可以使用变基，因为这是一个历史重写操作。你看，我在两台机器上使用我的存储库，我的开发机器和生产机器。我在开发机器上进行提交，推送到 github，然后拉到生产环境。所有这些都与我最初派生的上游存储库上的更改无关。
我不太清楚移植、挑选或任何其他可能适合的工具。但无论它是什么工具，我认为它不应该重写历史。从我的阅读中，我发现在推送时重写回购历史是禁忌。所以我不确定应该使用什么命令来移植分支而不重写历史记录。
如果我使用 Mercurial，我可能会考虑使用版本控制的 mq 之类的东西。我不知道 git 是否有类似的解决方案，或者是否有另一种更适合 git 的工具。
[编辑]
在评估了我在这里得到的回复后，我最终确定挑选是正确的答案。在所有情况下，变基都会删除历史记录，并且由于这是一个共享存储库，因此删除历史记录是不可接受的，至少根据我读过的每个资料来源。
然而，樱桃采摘会将提交复制到我的工作树，而不将其从原始位置删除。因此，我可以将我的更改的副本放置在最新标签的顶部，并将它们整齐地堆放在一起。
作为记录，我还尝试使用 Mercurial 来执行此操作，方法是使用 hg-git 扩展，该扩展允许您使用 hg 克隆 git 存储库。这有优点也有缺点。最大的缺点是当我用完它时，它无法推动。 hg-git 直到那时都可以正常工作，然后告诉您它不支持 hg 1.9。至少可以说是假的。另一个缺点是克隆和拉取大量更改的速度非常慢。然而，mq 和 TortoiseHg 的合并冲突解决工具比 gitcherry-pick 和 Smartgit 的合并冲突解决工具有了巨大的改进。我希望 hg-git 能够工作。
我想最后，“浮动”对于我的更改分支来说并不是一个很好的描述，因为结果是复制它而不是移动它。抱歉我的描述可能很糟糕，我仍在弄清楚到底有哪些选项。感谢您的帮助。
I have a fork of another organization's repository. I'm at the the latest tag in the repo, which is not the head, and I've created a branch from that tag which will never be pushed upstream. That's why I consider the branch private.
I've made commits to my private branch and am using that code in my production environment. When a new tag is made to the upstream repository, I want to be able to pull their changes.
However, I'd like to always keep my commits in a neat stack on top of their last tag. I don't want to merge then, since my commits will end up living far back in the history and I want to see them right on top so I can work with them easily when I use certain tools on my repository.
So really, I want a "floating" branch, one that I can transplant to an arbitrary point when I bring the upstream changes to my repository.
[edits]
I don't believe I can use rebase, however, since that's a history-rewriting operation. You see, I use my repository on two machines, my development and production. I make my commits on the development machine, push to github, then pull to production. All of this has nothing to do with the changes on the upstream repository that I originally forked from.
I'm not entirely clear on transplanting, cherry-picking or whatever other tool might be suited. Whichever tool it is though, I gather it shouldn't rewrite history. From my reading, I see that rewriting repo history is a no-no when pushing . So I'm not sure what commands I should be using that will transplant a branch without rewriting history.
If I were using mercurial, I might consider something like a version-controlled mq. I don't know the analogous solution for git, if there is one, or whether there is another, better-suited tool for git.
[edit]
After evaluating the responses I got here, I finally determined that cherry-picking was the right answer. In all cases, rebase removes history, and since this is a shared repository, removing history is unacceptable, at least according to every source I've read.
Cherry-picking, however, copies the commit to my working tree without removing it from its original location. So I can plant a copy of my changes on top of the latest tag and have them in a nice neat pile.
For the record, I also tried to do this with Mercurial, by using the hg-git extension which lets you use hg to clone a git repository. This had pluses and minuses. The biggest minus was that when I finished using it, it couldn't push. hg-git works happily until that point, then tells you that it doesn't push with hg 1.9. Bogus, to say the least. The other minus was that cloning and pulling a large set of changes is extremely slow. However, mq and TortoiseHg's merge conflict resolution tools are a vast improvement over git cherry-pick and Smartgit's merge conflict resolution. I wish hg-git could have worked.
I guess that in the end, "floating" wasn't such a good description for my change branch, since the result is to copy it rather than move it. Sorry for my perhaps poor description, I was still figuring out exactly what the options were. Thanks for the help.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
必须处理冲突，并且完全取决于您对可能从一个标签更改为下一个标签的文件所做的操作。特别是，如果有人删除了您更改的某些代码，您将必须解决此问题并确保您更改的代码现在可以应用于其他地方。对此没有灵丹妙药。一旦解决了冲突并且一切正常，
请重复冲洗。
要补充的是，如果您这样做只是为了能够部署，那么“浮动分支”可能不是处理此问题的最佳方法。考虑这些替代方案：
您的浮动分支似乎只是为了您自己的环境而存在，因此不应成为 项目。
Conflicts have to be dealt with and entirely depend on what you are doing with files that may have changed from one tag to the next. In particular, if someone has eliminated some code that you change, you will have to address this and make sure that the code you changed can now be applied elsewhere. There is no silver bullet for this. Once you resolved your conflicts and everything works,
Rinse repeat.
To add, if you are doing this to just be able to deploy, a "floating branch" may not be the best method for dealing with this. Consider these alternates:
Your floating branch seems like it is there only for the sake of your own environment and hence should not be part of the project.
您在此处描述了 git rebase --onto 的工作。
场景：
git fetch；gitbranchnewbranchcurrentbranch;oldtag，新标签是newtag；git rebase --onto newtag oldtag newbranch;git分支-D当前分支;git分支-m newbranch当前分支。但是，至于重写历史记录，您将 - 您的分支的历史记录，而不是原始存储库的历史记录，您没有对它的写访问权限，是吗？
You describe the job of
git rebase --ontohere.Scenario:
git fetchfrom the remote;git branch newbranch currentbranch;oldtag, and the new tag isnewtag;git rebase --onto newtag oldtag newbranch;git branch -D currentbranch;git branch -m newbranch currentbranch.However, as to rewriting history, you will -- of your branch, not of the origin repository, you don't have write access to it, do you?