Reputation: 2310
My goal is that in some point, MASTER (lets say 6.4.3) gets promoted (all stuff goes to a QA branch) to QA, and during this process, I add a four digit to project version, and build it. So, QA advances, producing 6.4.3.1.
This way, I can perform hotfixes on QA branch, and integrate them back to QA (and master, when needed). This will generate a new revision on QA branch, and build lets say 6.4.3.2.
But, time passes, and additions were made to master, and master now is 6.4.9.
So, I need to promote it again to QA, and this must generated 6.4.9.1 package. BUT all QA changes need to be overwrited by master stuff, and not merged. All that changes were relevant only to 6.4.3.x
All attempts I did resulted in merged operations on pom.xml. I tried merging and rebase, and also strategies like ours and theirs without any luck.
What I really need is a not-ugly-way of go to master branch, copy -R everything to a /tmp folder, and switch back to QA branch, cp -R from /tmp folder to it, and perform a git add . Then newer files will naturally overwrite old ones.
By doing this, I will end have all new changes from master overwriting old QA changes, that I dont need anymore, but still want to have it on history.
Tks Marco
ADDED 2014-08-27:
pom.xml on master:
<version>1.2.4</version>
<dependency>[6.0.0,)</dependency>
pom.xml on qa:
<version>1.2.3.1</version>
<dependency>6.0.3</dependency>
After the process, I need, on QA:
<version>1.2.4.1</version>
<dependency>6.0.5</dependency>
The script to generate 1.2.4.1 is working, and the mvn versions:resolve-ranges is working too. Thats why I cant work with already changed files on QA. They need to be replaced with current master changes, so I can make the necessary changes to it.
Upvotes: 1
Views: 1653
Reputation: 28981
Don't do it. Use merges, see the: http://nvie.com/posts/a-successful-git-branching-model/ . If you want a change in QA, but do not put it back into master, you could merge and then revert it. Makes history more clear.
But if you really wish, use git merge -s ours master
into the qa branch.
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.
† You actually should not discard qa changes, as it could be hotfixes/bugfixes tested and accepted by QA and of course should be merged back to master, otherwise same bugs will appear in the next QA, not nice. So normally you should not use -s ours
.
Exactly the same thing but more difficult and history graph looks worse, however looks as "your way":
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.
Upvotes: 2
Reputation: 2310
This is the final solution I got, which met perfectly my needs, merging both solutions presented. Tks a lot.
Final git lola:
* 782db24 (HEAD, master) 1.2.5
| * d2572c8 (qa) 1.2.4.1
| * 12d4348 Merge branch 'master' into qa
| |\
| |/
|/|
* | 1884a7c release 1.2.4
Commands:
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"
Thank both of you guys.
Upvotes: 0
Reputation: 48418
First, checkout the QA branch. Then, run git read-tree -um
commit
. This will effectively "reset" your working tree to the given commit without moving any branch pointers or checking out any commits. After this, you can run git commit
to commit these changes to the QA branch.
More info: git-read-tree(1) Manual Page
Upvotes: 0