如何从不同分支中的特定提交创建分支 [英] How to create the branch from specific commit in different branch

查看:124
本文介绍了如何从不同分支中的特定提交创建分支的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我在master分支中进行了多次提交,然后将它们合并到了dev分支。

我想从dev分支中的特定提交中创建一个分支,最初是在master分支中提交的。



我使用了以下命令:

  git checkout dev 
git分支<分支名称> < commit id>

但是,这会从主分支创建分支,而不是我期望的开发分支。主分支和开发分支中的提交ID相同。
所以,我怎么能区分不同的分支相同的提交ID?



PS:我在github这里做了一个例子 https://github.com/RolandXu/test_for_branch



我使用了以下命令:

  git checkout dev 
git branch test 07aeec983bfc17c25f0b0a7c1d47da8e35df7af8

我期望的是测试分支包含aa.txt bb.txt cc.txt。但是,测试分支只包含aa.txt和cc.txt。它最有可能从主分支创建分支。

如果您使用这种形式分支命令(带起点),它与 HEAD 的位置无关。



你在做什么:

  git checkout dev 
git branch test 07aeec983bfc17c25f0b0a7c1d47da8e35df7af8
HEAD
$ b>
$ b
    到分支 dev


  • 其次,您在提交 07aeec98 。这个提交没有bb.txt(根据你的github回购)。




如果你想开始一个新的分支在你刚刚签出的位置,你可以运行没有开始点的分支:

  git分支测试

或其他已经在一个操作中回答了分支和结帐: p>

  git checkout -b测试






我认为你可能会被 07aeec98 属于分支开发。确实,这个提交是 dev 的祖先,它的更改需要达到 dev 中的最新提交。但是,它们是达到最新的 dev 所需的其他提交,它们不一定在 07aeec98 。
$ b

8480e8ae (您添加了bb.txt)例如不在<$ c的历史记录中$ C> 07aeec98 。如果从> 07aeec98 分支,则不会得到由 8480e8ae 引入的更改。

$ b $换句话说:如果将分支A和分支B合并到分支C中,然后在A的提交上创建一个新分支,则不会得到在B中引入的更改。



同样在这里,您有两个并行分支master和dev,您在dev中合并。从master提交(比合并更早)分支不会为您提供dev的更改。






如果你想永久地将主要新变化集成到你的功能分支中,你应该将 master 合并到它们中继续。但是,这将在您的功能分支中创建合并提交。



如果您尚未发布功能分支,您还可以在更新后的主设备上重新绑定它们: git rebase master featureA 。准备好解决可能发生的冲突。



如果您想要一个工作流程,您可以在没有合并提交的情况下工作于功能分支,并且仍然与主要更新中的更改集成,如下所示:


  • 创建一个<$ c当您需要查看您的功能分支如何与主控中的新更改集成时,将主控功能和特性功能合并在一起时,$ c> dev 在主控提交上分支
  • 分支到 dev



不要提交到 dev 直接使用它,仅用于合并其他分支。



例如,如果您正在使用功能A和B:

  a --- b --- c --- d --- e --- f --- g -master 
\\
\\\\\\\\\\\\××××××××××××××××××××××××××××××××××××××××××××××××××××××××××××××××××××× pre>

将分支合并到 dev 分支中,以检查它们与新主人一起工作:

  a --- b --- c --- d --- e-- -f --- g -master 
\\\
\\\\\\''x'-k'-dev
\\ / /
\ \-x ---------- / -featureB
\ /
\ -j --- k --------- ------ -featureA

您可以继续使用您的功能分支,并保持合并定期将主要和特色分支的新变化转换为 dev

  a --- b --- c --- d --- e --- f --- g --- h --- i ----- -master 
\ \ \ \\ \\
\\\\'''''''''''''''''''''''''''''''''''''''' \\-x ---------- / / -featureB
\ / /
\ -j --- k ----------------- l -------featureA

当需要集成新功能时,合并功能分支(而不是 dev !)进入主人。

I have made several commits in the master branch and then merged them to dev branch.

I want to create a branch from a specific commit in dev branch, which was first committed in master branch.

I used the commands:

git checkout dev
git branch  <branch name> <commit id>

However, this creates the branch from master branch, not the dev branch I expected. The commit id is same in master branch and dev branch. So, how can I distinguish same commit id in different branch?

PS: I made an example in github here https://github.com/RolandXu/test_for_branch

I used the commands:

git checkout dev
git branch test 07aeec983bfc17c25f0b0a7c1d47da8e35df7af8

What I expect is that the test branch contains aa.txt bb.txt cc.txt. However, the test branch only contains aa.txt and cc.txt. It most likely created the branch from the master branch.

解决方案

If you are using this form of the branch command (with start point), it does not matter where your HEAD is.

What you are doing:

git checkout dev
git branch test 07aeec983bfc17c25f0b0a7c1d47da8e35df7af8

  • First, you set your HEAD to the branch dev,

  • Second, you start a new branch on commit 07aeec98. There is no bb.txt at this commit (according to your github repo).

If you want to start a new branch at the location you have just checked out, you can either run branch with no start point:

git branch test

or as other have answered, branch and checkout there in one operation:

git checkout -b test


I think that you might be confused by that fact that 07aeec98 is part of the branch dev. It is true that this commit is an ancestor of dev, its changes are needed to reach the latest commit in dev. However, they are other commits that are needed to reach the latest dev, and these are not necessarily in the history of 07aeec98.

8480e8ae (where you added bb.txt) is for example not in the history of 07aeec98. If you branch from 07aeec98, you won't get the changes introduced by 8480e8ae.

In other words: if you merge branch A and branch B into branch C, then create a new branch on a commit of A, you won't get the changes introduced in B.

Same here, you had two parallel branches master and dev, which you merged in dev. Branching out from a commit of master (older than the merge) won't provide you with the changes of dev.


If you want to permanently integrate new changes from master into your feature branches, you should merge master into them and go on. This will create merge commits in your feature branches, though.

If you have not published your feature branches, you can also rebase them on the updated master: git rebase master featureA. Be prepared to solve possible conflicts.

If you want a workflow where you can work on feature branches free of merge commits and still integrate with newer changes in master, I recommend the following:

  • base every new feature branch on a commit of master
  • create a dev branch on a commit of master
  • when you need to see how your feature branch integrates with new changes in master, merge both master and the feature branch into dev.

Do not commit into dev directly, use it only for merging other branches.

For example, if you are working on feature A and B:

a---b---c---d---e---f---g -master
    \       \
     \       \-x -featureB
      \
       \-j---k -featureA

Merge branches into a dev branch to check if they work well with the new master:

a---b---c---d---e---f---g -master
    \       \            \
     \       \            \--x'---k' -dev
      \       \             /    /   
       \       \-x----------    /    -featureB
        \                      /
         \-j---k--------------- -featureA

You can continue working on your feature branches, and keep merging in new changes from both master and feature branches into dev regularly.

a---b---c---d---e---f---g---h---i----- -master
    \       \            \            \
     \       \            \--x'---k'---i'---l' -dev
      \       \             /    /         /
       \       \-x----------    /         /  -featureB
        \                      /         /  
         \-j---k-----------------l------ -featureA

When it is time to integrate the new features, merge the feature branches (not dev!) into master.

这篇关于如何从不同分支中的特定提交创建分支的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆