有没有正确的方法来“同步”?分支并将它们分开?

发布于 2024-09-11 14:44:14 字数 244 浏览 4 评论 0原文

因此,我从 master 创建了一个新分支,并最终将更改合并回来,只有一些更改似乎合并了,而且似乎我向一个方向合并了。最终我决定确保 master 收到所有“实验性”更改,然后删除实验分支并创建一个新分支。所以这个问题突然变成了几个问题:

1)如何匹配分支但保持它们分开?

1a)不建立一个新分支是不好的做法吗?

2)为什么一次合并后分支不一样?

2a)我是否只应该对我想要进行所有更改的那个调用合并?

So I created a new branch from master and eventually merge the changes back, only some changes seemed to merge and it would seem I merged in one direction. Eventually I just decided to be sure master received all the 'experimental' changes then I deleted the experimental branch and made a new one. So this question is turning into a few questions suddenly:

1) How do I match up branches but keep them separate?

1a) Is that bad practice to not just make a new branch?

2) Why were the branches not the same after after one merge?

2a) Am I only supposed to call a merge on the one that I want to have all of the changes?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

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

发布评论

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

评论(1

不…忘初心 2024-09-18 14:44:14

就实际而言,合并绝对是一种单向操作。它将一个分支合并到另一个分支中。将实验合并到 master 后生成的历史记录如下所示:

- o - o - o - o - o - X (master)
   \                 /
    o - o - o - o - o (experimental)

因此,在一次合并之后,master 包含了在 Experiment 中所做的所有更改,但它们显然不一样。

我对你所说的“匹配但保持分离”到底是什么意思有点困惑。常见的做法是为某些特定目的(功能、错误修复...)创建主题分支,然后将其合并到需要该实体的任何地方。例如,错误修复可能属于两个旧的维护版本以及当前的主版本,因此它会合并到所有三个版本中。

我认为 Junio Hamano 博客(他是 git 的当前维护者)上的 这篇文章 是其中之一我找到了关于何时应该合并以及何时不应该合并的最佳解释。它应该可以回答你的大部分哲学问题。

With respect to the practical, a merge is definitely a one-way operation. It merges one branch into another. The resulting history after merging experimental into master would look like this:

- o - o - o - o - o - X (master)
   \                 /
    o - o - o - o - o (experimental)

So after one merge, master contains all of the changes made in experimental, but they are clearly not the same.

I'm a little confused about what exactly you mean by "match up but keep separate". It's common practice to make a topic branch for some specific purpose (feature, bugfix...), then merge it into everywhere that entity is needed. For example, a bugfix could belong in two old maintenance releases as well as the current master, so it'd get merged into all three.

I think this post on Junio Hamano's blog (he's the current maintainer of git) is one of the best explanations I've found of exactly when you should merge, and when you shouldn't. It should answer the bulk of your philosophical questions.

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