blocks|key|561675|text|在这种情况下，你在分支"4.0“上工作，并且必须在"3.1”上进行修复，在提交“3.1”之后，你可以重新基址"4.0“：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|561676|确保您在功能分支4.0上：|561677|git+checkout+4.0|code-block|syntax|javascript|561678|保存当前工作，以便可以检出其他分支：|561679|git+stash++
git+checkout+3.1++|561680|进行编辑并提交：|561681|git+commit+-a+-m+"bug+fix"++
git+checkout+4.0++|561682|取回您的更改：|561683|git+stash+apply++|561684|更改4.0，使其成为“3.1”的当前标题的分支：|561685|git+rebase+"3.1"|561686|entityMap^0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|10|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|11|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|12|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|13|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|14|8|@]|9|@]|A|$G|H]]|$1|M|3|N|5|6|7|15|8|@]|9|@]|A|$]]|$1|O|3|P|5|F|7|16|8|@]|9|@]|A|$G|H]]|$1|Q|3|R|5|6|7|17|8|@]|9|@]|A|$]]|$1|S|3|T|5|F|7|18|8|@]|9|@]|A|$G|H]]|$1|U|3|V|5|6|7|19|8|@]|9|@]|A|$]]|$1|W|3|X|5|F|7|1A|8|@]|9|@]|A|$G|H]]|$1|Y|3|-4|5|6|7|1B|8|@]|9|@]|A|$]]]|Z|$]]

In the case, you are working on branch "4.0" and have to make a fix on "3.1", you may rebase "4.0" after you commit "3.1":

Make sure you are on the feature branch 4.0: 

<pre><code>git checkout 4.0
</code></pre>

Save current work so you can check out other branch: 

<pre><code>git stash 
git checkout 3.1 
</code></pre>

Do editing and commit: 

<pre><code>git commit -a -m "bug fix" 
git checkout 4.0 
</code></pre>

Get back your changes:

<pre><code>git stash apply 
</code></pre>

Change 4.0 so it branches of the current head of "3.1": 

<pre><code>git rebase "3.1"
</code></pre>

blocks|key|561766|text|如果你想获得更高的技术含量，你可以从一个共同的祖先创建修补程序：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|561767|git+merge-base+v3+master
git+checkout+-b+hotfix+<whatever+you+got+from+merge-base>
#+make+your+fix
git+checkout+v3+&&+git+merge+--no-ff+hotfix
git+checkout+master+&&+git+merge+--no-ff+hotfix

++++++++v3--------v3+(hotfixed)
+++++++/+++++++++/
ancestor----hotfix
+++++++\+++++++++\
++++++++master----master+(hotfixed)|code-block|syntax|javascript|561768|--no-ff标志是为了突出显示Git将创建合并提交，将hotfix分支标签保留在热修复提示，而不是将标签拉到v3或master。(您可以省略该标志并获得相同的行为，因为hotfix分支有一个不在master或v3中的提交。更多信息，请访问in+the+docs。)|offset|length|style|CODE|561769|就我个人而言，我认为这有点过头了。我建议使用gahooa:在分支上进行有意义的热修复，然后根据您希望分支之间的关系进行合并或选择。|561770|entityMap|0|LINK|mutability|MUTABLE|url|https://git-scm.com/docs/git-merge#_fast_forward_merge^0|0|0|0|7|S|6|1J|2|1M|6|2D|6|2Q|6|2X|2|3C|B|0|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|X|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|Y|8|@$I|Z|J|10|K|L]|$I|11|J|12|K|L]|$I|13|J|14|K|L]|$I|15|J|16|K|L]|$I|17|J|18|K|L]|$I|19|J|1A|K|L]|$I|1B|J|1C|K|L]]|9|@$I|1D|J|1E|1|1F]]|A|$]]|$1|M|3|N|5|6|7|1G|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|1H|8|@]|9|@]|A|$]]]|P|$Q|$5|R|S|T|A|$U|V]]]]

If you wanted to get super-technical about it, you could create the hotfix from a common ancestor:

<pre><code>git merge-base v3 master
git checkout -b hotfix &lt;whatever you got from merge-base&gt;
# make your fix
git checkout v3 &amp;&amp; git merge --no-ff hotfix
git checkout master &amp;&amp; git merge --no-ff hotfix

 v3--------v3 (hotfixed)
 / /
ancestor----hotfix
 \ \
 master----master (hotfixed)
</code></pre>

The <code>--no-ff</code> flag is there to highlight that Git will create a merge commit, keeping the <code>hotfix</code> branch label at the hotfix tip, instead of pulling the label to <code>v3</code> or <code>master</code>. (You can omit the flag and get the same behavior, since the <code>hotfix</code> branch has one commit that isn't in <code>master</code> or <code>v3</code>. More info <a href="https://git-scm.com/docs/git-merge#_fast_forward_merge" rel="noreferrer">in the docs</a>.)

Personally, I think that's overkill. I'd go with gahooa: make the hotfix on the branch that makes sense, then merge or cherry-pick depending on how you want the branches to relate to each other.

blocks|key|561834|text|我也一直在为这个问题而苦苦挣扎，我认为如果你愿意稍微改变一下你的版本控制策略(也就是脱离Maven鼓励的-SNAPSHOT版本)，这个问题可以通过在主服务器(或者你的开发分支是什么)上使用一个固定的版本(比如快照或0.0.0-快照)来解决。(如果您使用的是Maven，那么快照后缀很重要，因为Maven对待快照版本的工件与其他工件不同。)|type|unstyled|depth|inlineStyleRanges|entityRanges|data|561835|事实上，我认为你应该制定一项政策，只在你的生产分支(你用来构建版本的分支)或那些仅用于发布目的的分支(例如，更改版本号)上更改版本号，并且您永远不会打算将其合并回开发分支。|561836|我还没有真正使用过这个策略，但我只是在考虑它，我想我会开始尝试它。|561837|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

I've been struggling with this question, too, and I think if you're willing to change your versioning strategy a little (i.e., depart from the -SNAPSHOT versions that Maven encourages), this could be solved by using a fixed version (like SNAPSHOT or 0.0.0-SNAPSHOT) on master (or whatever your development branch is). (The SNAPSHOT suffix is important, if you're using Maven, since Maven treats SNAPSHOT-versioned artifacts differently than others.)

In fact, I think you'd want to institute a policy of only ever changing the version number on your production branch (the one from which you build releases) or on branches which are for release purposes only (e.g., changing version numbers) and which you never intend to merge back to the development branch.

I haven't actually used this strategy yet, but was just thinking about it, and I think I'll start trying it.

I've been trying to wrap my head around git branching models. I've been looking at <a href="http://nvie.com/posts/a-successful-git-branching-model/" rel="noreferrer">http://nvie.com/posts/a-successful-git-branching-model/</a> for some ideas and coming from Subversion one thing I was really looking forward to was making a change in a single place and merging it to all the branches that needed it. In Subversion, we ended up doing to much copy of code around.

However I still don't get this completely. Here is a standard type of workflow that I have and it will always come up with conflicts.

<pre><code># create new version branch
git checkout master
git checkout -b v3
vim pom.xml # change branch version to "3.1-SNAPSHOT"
git commit -a
git checkout master
vim pom.xml # change master version to "4.0-SNAPSHOT"
git commit -a
</code></pre>

So the master is at 4.0-SNAPSHOT and the branch is at 3.1-SNAPSHOT.

Not I want to create a hotfix on the branch and move it to the trunk.

<pre><code>git checkout v3
git checkout -b hotfix
vim file.txt # make a bugfix change
git commit -a
git checkout v3
git merge hotfix # this works fine
git checkout master
git merge hotfix # this has a conflict since both branches have changed the version
</code></pre>

I understand why its happening and it makes sense. Is there a better way of doing this?

I read about cherry-pick, which I tested and does work:

<pre><code>git checkout v3
git cherry-pick a518b0b75eaf28868
git checkout master
git cherry-pick a518b0b75eaf28868
</code></pre>

However, that doesn't seem like the "correct" way to handle this. Any suggestions?

Git merging hotfix to multiple branches

服务器

我一直在尝试理解git分支模型。我一直在寻找的一些想法，从Subversion中我真正期待的一件事是在一个地方进行更改，并将其合并到所有需要它的分支中。在Subversion中，我们最终复制了大量的代码。然而，我仍然不完全理解这一点。这是我拥有的标准类型的工作流，它总是会出现冲突。# create new versio...

问Git正在将修补程序合并到多个分支
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Git正在将修补程序合并到多个分支EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Git正在将修补程序合并到多个分支
EN