git 知道合并后哪个分支是哪个分支吗？

发布于 2024-09-02 19:46:57 字数 322 浏览 4 评论 0原文

抱歉，如果这是一个只有是/否答案的愚蠢问题，但如果我理解正确的话，在 git 中，分支只是指向提交的指针。这是否意味着一旦合并两个分支，git 就不知道哪个分支指向哪一组提交？

之前

A---B---C---D---E    <- X
 \                
  1----2----3----4   <- Y

之后

A---B---C---D---E--M  <-X & Y
 \                /
  1----2----3----4

原文

Sorry if this is a stupid question with just a yes/no answer, but if I understand correctly, in git a branch is just a pointer to a commit. Doesn't this imply that once you've merged two branches, git doesn't know which one pointed to which set of commits?

Before

A---B---C---D---E    <- X
 \                
  1----2----3----4   <- Y

After

A---B---C---D---E--M  <-X & Y
 \                /
  1----2----3----4

分享到QQ

分享到微博

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

发布评论

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

只等公子 2024-09-09 19:46:57

如果我没记错的话，您将一个分支合并到另一个分支中，就像 feature1 合并到 master 中一样，所以 master 现在指向合并提交，但 feature1 仍然指向它之前指向的位置。

Jefromi 编辑：这是正确的。图片应该是这样的：

git checkout branch X

    A---B---C---D---E   branchX (HEAD)
     \                
      1----2----3----4   branchY

git merge branchY

    A---B---C---D---E--M  branchX (HEAD)
     \                /
      1----2----3----4  branchY

If I recall correctly you merge a branch into another one, like feature1 into master, so master now points to merge-commit but feature1 still points to where it pointed before.

Edit by Jefromi: This is correct. The pictures should look like this:

git checkout branch X

    A---B---C---D---E   branchX (HEAD)
     \                
      1----2----3----4   branchY

git merge branchY

    A---B---C---D---E--M  branchX (HEAD)
     \                /
      1----2----3----4  branchY

回复收藏 0 原文

滴情不沾 2024-09-09 19:46:57

合并分支实际上并不合并另一个分支的引用；它将另一个分支的内容合并到当前分支中。

回复收藏 0 原文

药祭#氼 2024-09-09 19:46:57

Chris Johnson 的评论当然是正确的，git 不记录分支名称。但其他答案向我表明，可能不清楚这种情况是如何发生的。下面是一个示例：

假设工作是在 main 和 feature1 分支上并行完成的。

$ git status
On branch main
$ echo M1 > t.txt; git add t.txt; git commit -m"M1"
$ git checkout -b feature1
$ echo F1 >> t.txt; git add t.txt; git commit -m"F1"
$ git checkout main
$ echo M2 >> t.txt; git add t.txt; git commit -m"M2"

现在您希望将您的 featrue1 分支与 main 同步，以便有权合并到 main 的开发人员可以通过快进合并来完成此操作。您可以这样做：

$ git checkout feature1
$ git merge main
Auto-merging t.txt
CONFLICT (content): Merge conflict in t.txt
Automatic merge failed; fix conflicts and then commit the result.
$ vi t.txt
$ git add t.txt
$ git merge --continue
[feature1 e393a9c] Merge branch 'main' into feature1

现在存储库的维护者可以通过快进合并到 main：

$ git checkout main
$ git merge feature1
Updating 9adb9c3..e393a9c
Fast-forward
 t.txt | 1 +
 1 file changed, 1 insertion(+)

$ git log --oneline --graph -3
*   e393a9c (HEAD -> main, feature1) Merge branch 'main' into feature1
|\
| * 9adb9c3 M2
* | 6b1adde F1
|/

此时您无法再看到哪个分支 M2 或 >F1 属于。

诀窍是维护者在合并到 main 时在这种情况下使用 --no-ff 选项。使用此选项，我们会看到下图：

$ git checkout main
Switched to branch 'main'
$ git merge --no-ff feature1
Merge made by the 'ort' strategy.
 t.txt | 1 +
 1 file changed, 1 insertion(+)

$ git log --oneline --graph -5
*   079274c (HEAD -> main) Merge branch 'feature1'
|\
| *   ba06737 (feature1) Merge branch 'main' into feature1
| |\
| |/
|/|
* | 7f7b2f0 M2
| * ab53267 F1
|/
* 5ddd4f7 M1

Chris Johnson is of course correct in his comment, git does not record the branch name. But the other answers suggest to me, that it may be unclear how this situation may arise. Here is an example:

Lets assume work is done on main and a feature1 branch in parallel.

$ git status
On branch main
$ echo M1 > t.txt; git add t.txt; git commit -m"M1"
$ git checkout -b feature1
$ echo F1 >> t.txt; git add t.txt; git commit -m"F1"
$ git checkout main
$ echo M2 >> t.txt; git add t.txt; git commit -m"M2"

Now you want to sync your featrue1 branch with main so that the developer with the permission to merge to main can do so via fast forward merge. You could do it like this:

$ git checkout feature1
$ git merge main
Auto-merging t.txt
CONFLICT (content): Merge conflict in t.txt
Automatic merge failed; fix conflicts and then commit the result.
$ vi t.txt
$ git add t.txt
$ git merge --continue
[feature1 e393a9c] Merge branch 'main' into feature1

Now the maintainer of the repo can merge to main via fast forward:

$ git checkout main
$ git merge feature1
Updating 9adb9c3..e393a9c
Fast-forward
 t.txt | 1 +
 1 file changed, 1 insertion(+)

$ git log --oneline --graph -3
*   e393a9c (HEAD -> main, feature1) Merge branch 'main' into feature1
|\
| * 9adb9c3 M2
* | 6b1adde F1
|/

At this point you cannot see any more to which branch M2 or F1 belong.

The trick is for the maintainer to use the --no-ff option in this case when merging to main. With this option we would have seen the following graph:

$ git checkout main
Switched to branch 'main'
$ git merge --no-ff feature1
Merge made by the 'ort' strategy.
 t.txt | 1 +
 1 file changed, 1 insertion(+)

$ git log --oneline --graph -5
*   079274c (HEAD -> main) Merge branch 'feature1'
|\
| *   ba06737 (feature1) Merge branch 'main' into feature1
| |\
| |/
|/|
* | 7f7b2f0 M2
| * ab53267 F1
|/
* 5ddd4f7 M1

回复收藏 0 原文

~没有更多了~