Workflow for pushing code for review with a Cherry pick that is still in review
I’m a little confused by all the stuff I’m reading online, so perhaps I can get a clearer answer by explaining what I’d like to do.
Here’s what I have:
– Commit A has some API updates I and other people need.
– Commit A is still in review, so it hasn’t been merged to the master branch. Thus I cannot do a git fetch/merge/pull to get those updates just yet.
What we want to do is get that code, even though it’s still in review, and then continue our work that’s dependent on it. I tried cherry-picking, and then working as I need to. There’s no problem until I decide I’m ready to commit and push my code for review.
I see two options:
Do not commit my code yet, just let it sit in a stash. Wait until Commit A is merged. Then I have to somehow undo my cherry-pick since Cherry-picking creates a new commit. Then I do a git fetch/merge/pull, unstash my code, commit my changes, and submit my code.
Is there a way to submit my code and simply have it dependent on Commit A getting merged? I can’t simply push my code with the cherry-pick, I get an error saying that the cherry-picked code hasn’t been changed.
- How would I do either of the above?
- Is one option more advisable than the other?
- Is there a different method from the above I should do instead? If so, what?
One Solution collect form web for “Workflow for pushing code for review with a Cherry pick that is still in review”
If I remember correctly (it’s been a year), I believe if you do (1) (cherry pick, stash it, and wait until the review goes through), if you pull the now merged code, then pop the stash, then rebase it (assuming you now have two different branches) on top of the new merged code, it should keep the changes that you have made, which you can then commit.
You have to be careful not to lose the cherry-picked code (make sure you stash it, because otherwise if you change branches you might lose your code).
The issue might be if something was changed during the code review and you have an old version of “Commit A.” When you try to put your changes on top of it (the new merged code) you might have merge-conflicts (depending on how you rebase). I recommend getting GitExtensions to visually see how the code branches when you do things like stashing then pulling.
I would recommend testing the method I suggested above on a separate branch, and understand how it works first before trying it on actual code you are developing.