Feature branches with feedbacks in Stash

Szymon Reiter

Hello,

I've started using Gitflow Workflow as specified in https://www.atlassian.com/git/workflows#!workflow-gitflow.
Now I'm having issues with feedbacks and I'm not sure if I'm doing something wrong or is it the way it should be.

I borrowed graph from the link above and it looks like this.

Now suppose that we have two feature branches. First one which ends with commit A and second one which ends with commit B.
Suppose that there are some issues with feature B and it goes to next releases. In meantime there are few similar to A branches which ends merged into develop.
Branch develop has evolved because of my feature branches. That's why at some point my branch B can't be merged into develop.

It seems to me reasonable that pull request which has been opened on my feature branch should be mergeable before review is started.
I also think that developer which maintain branch B should leave it in mergeable state and it should be his responsibility to fix it since he has largest knowledge about implementation.

So there is a question are my assumptions wrong?

If not, there is next question. How can I bring my branch B to mergeable state?

I see two options:
A. merging upstream develop branch into my feature branch B
B. create new fresh version of feature branch B (let's call it B-v2) which base on upstream develop, after that merge branch B into B-v2 and resolve conflicts. (this solution was presented on some blog I've found)

About A option it looks like bad thing to me because in my pull request I have changesets which were merged from develop and has nothing in common with my feature.

About B option it seems to me that Stash was not created for this use case:
* I have to create new branch and merge old one into new one even if conflict is pretty simple
* I have to create new pull request on new branch
* I'm not able to delete old pull request (as stated here)

I would assume that pull request should evolve with feature. But with B option it looks impossible.

So I have that feeling that I'm doing something wrong. How this process should look like? What am I missing?

Balázs Szakmáry

Option A is the right thing to do. Your Feature B branch is "a child of" Develop anyway, so by merging (the current state of) Develop into Feature B, you are "updating" Feature B with all the stuff that has been going on since it was created. (This is also what Stash tells you if you click on "more information" where it says that the PR cannot be merged.)

N.B. In the Diff view of the pull request, the contents of any merge commits do not show up, you only need to review the "real" changes.

If, for whatever reason, you do not want to do this, there is a relatively simple "Option B'":

1. Create a new B-v2 branch.
2. Cherry-pick the commits from Feature B to B-v2 and issue a new PR for that.
3. Optionally delete Feature B. (You have to decline the PR first.)