GIT:如何用Master覆盖QA分支，保存QA分支的历史？
我的目标是，在某个时候，MASTER (比方说6.4.3)被提升到QA分支(所有东西都会转到QA分支)，在这个过程中，我为项目版本添加一个四位数，然后构建它。因此，QA取得了进展，生产了6.4.3.1。
这样，我就可以在QA分支上执行修补程序，并将它们集成回QA (并在需要时掌握它们)。这将在QA分支上生成一个新的修订版，并构建6.4.3.2。
但是，时间的流逝，和增加的主人，现在是6.4.9。
因此，我需要再次向QA推广它，这必须生成6.4.9.1包。但是，所有的QA更改都需要被主程序过度编写，而不是合并。所有这些变化只与6.4.3.x有关。
我所做的所有尝试都导致了pom.xml上的合并操作。我尝试过合并和重新定位，也尝试了像我们和他们这样的策略，但没有任何运气。
我真正需要的是一种不让人讨厌的方式:转到主分支，将-R所有内容复制到/tmp文件夹，然后切换回QA分支，从/tmp文件夹切换到cp -R，并执行git。那么较新的文件将自然覆盖旧的文件。
这样做，我将结束所有新的变化，从大师覆盖旧的QA变化，我不再需要，但仍然希望它在历史上。
马可
加上2014-08-27：
主机上的pom.xml：
<version>1.2.4</version>
<dependency>[6.0.0,)</dependency>qa上的pom.xml：
<version>1.2.3.1</version>
<dependency>6.0.3</dependency>在这个过程之后，我需要，在QA上：
<version>1.2.4.1</version>
<dependency>6.0.5</dependency>生成1.2.4.1的脚本正在工作，mvn版本:解析-范围也在工作。这就是为什么我不能在QA上处理已经更改的文件。它们需要用当前的主更改来替换，这样我就可以对其进行必要的更改。
回答 3
Stack Overflow用户
发布于 2014-08-27 12:57:03
这是我得到的最后一个解决方案，它很好地满足了我的需求，合并了这两个解决方案。很多Tks。
最后的吉特·洛拉：
* 782db24 (HEAD, master) 1.2.5
| * d2572c8 (qa) 1.2.4.1
| * 12d4348 Merge branch 'master' into qa
| |\
| |/
|/|
* | 1884a7c release 1.2.4命令：
git checkout qa
git merge -s ours master #(will store this on history, w/o conflicts)
git read-tree -um master #(will replace current merged files with master)
vi pom.xml #(I manually edited to make it 1.2.4.1)
git add .
git commit . -m "1.2.4.1"
git checkout master
vi pom.xml #(new release, 1.2.5)
git add .
git commit . -m "1.2.5"谢谢你们俩。
Stack Overflow用户
发布于 2014-08-26 22:02:10
不要这样做。使用合并，请参阅：http://nvie.com/posts/a-successful-git-branching-model/。如果您希望在QA中进行更改，但不要将其放回master中，则可以合并并恢复它。让历史变得更清楚。
但是如果您真的愿意的话，可以在qa分支中使用git merge -s ours master。
git checkout master
git merge -s ours origin/qa #discards all qa changes †
vi pom.xml #(I manually edited to make it 1.2.4.1)
git add .
git commit . -m "1.2.4.1"
# make sure it works, passes all tests, etc and ready to go for QA.
git push origin master:qa #yes, you don't even need to flip branches locally
vi pom.xml #(new release, 1.2.5)
git add .
git commit . -m "1.2.5"
# continue master development.†您实际上不应该放弃QA更改，因为它可能是qa测试和接受的修补程序，当然应该合并回主，否则在下一个QA中会出现相同的bug，而不是很好。因此，通常您不应该使用-s ours。
同样的事情，但难度更大，历史图表看起来更糟，然而，看起来像“你的方式”：
git checkout master
git merge -s ours qa #discards all qa changes
git checkout qa
git merge master # it does fast-forward in fact
vi pom.xml #(I manually edited to make it 1.2.4.1)
git add .
git commit . -m "1.2.4.1" # committing into `qa` branch
# make sure it works, passes all tests, etc and ready to go for QA.
git checkout master
vi pom.xml #(new release, 1.2.5)
git add .
git commit . -m "1.2.5" # committing into `master`
# continue master development.Stack Overflow用户
发布于 2014-08-26 21:16:02
首先，查看QA分支。然后运行git read-tree -umcommit。这将有效地“重置”您的工作树到给定的提交，而不移动任何分支指针或签出任何提交。之后，您可以运行git commit将这些更改提交到QA分支。
更多信息：git-读树(1)手册页
https://stackoverflow.com/questions/25515100
复制相似问题
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号