You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
I am trying to create a pull request with selected commits using latest bitbucket cloud rest API. But it creates a pull request with all commits.
Suppose, I have a branch BXI-01 which has four commits i.e commit1,commit2,commit3 and commit4. How can we create a pull request with commit3 and commit4 only?
"title":"Testing pull request created fourth time. with single commit ",
+1 on this feature please. Just arrived here while wanting to do the same. Would really help in a lot of use cases, with many devs, many branches and many features. Some commits would need to be merged with one main branch and not with others. Also, there are times where the only way we can merge is raising a PR without permission to directly merge to one branch. Also for hotfixes.
Would love this feature. With multiple devs working against a repos, we find it common place to have multiple commits made (for version protection and code protection) that are not ready for merge to stage or prod. When a pull request is created we have no way currently to cherry pick the commits that are ready to deploy. This limitation leads to multiple branches - one per dev that have to be constantly synchronized overly complicating the dev-ops process.
+1 to this feature
At times I have a branch for whole epics, but I work on things that are only "seemingly related" (like separate windows). Unfortunately, those 'things' share common assets like textures, which I have to constantly work on, and a texture don' merge at all.
If I have to create a separate branch for each thing I do and all those share common texture, imagine how merging changes on a texture to all those branches would take.
The issue I have with the above approach is that of traceability. Consider if there are 5 feature branches ['A'..'E'] each merged onto shared-dev-branch. Now if is desired to merge three of them ['A';,'C','E'] from shared-dev-branch to staging-branch.
Six months from now, there is the need to go back and review each of the features where the code originated. The "cherry-pick into a temporary branch" broke that traceability.