Recently I migrated our codebase from perforce to github. I used git-p4 tool to setup the git repo and branch mappings along with commit history (p4 submit history). I am facing a problem of merging two branches, QA and development, both has x and y number of commits, and x < y. Development was branched out of QA long time back and was never merged (as per to perforce workflow that our team followed).
Now inorder to setup git workflow, I will have to merge development into QA (for QA promotion), However, the result of this merge will be replaying all the commits of development on QA. I don't want this to happen, as this will pollute QA with unwanted development history. I only want to merge newer commits that are on develop.
I tried the following approach.
git merge --squash development (this did not work)
and
git checkout -b qa_cycle_1.0
git cherry-pick commit1 commit2 . . .
open pull request with qa_cycle_1.0 and QA
The second approach works but this include the overhead of cherry picking and things can get convoluted easily while merging hotfixes from QA to dev.
Is there any way to merge these two branches without inheriting commit history of development?. I need to come up with a convention that our team should follow.
If you have the first n commits of dev you do not want to be merged to QA (ie, you want only the latest m commits of dev), you could:
git merge --ours <sha1 of last n commit>: that won't change anything in QA, but record the last of the n commit as being "merged".git merge dev: all the commits since the last merge will be merged.