Feature branches with feedbacks in Stash

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?

1 answer

1 accepted

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.)

I don't know why I was strongly convinced that changes from merge show up in PR. It seems I was wrong. Now option A doesn't look so bad to me. I will give it a try. Thanks

Suggest an answer

Log in or Join to answer
Community showcase
Piotr Plewa
Published Dec 27, 2017 in Bitbucket

Recipe: Deploying AWS Lambda functions with Bitbucket Pipelines

Bitbucket Pipelines helps me manage and automate a number of serverless deployments to AWS Lambda and this is how I do it. I'm building Node.js Lambda functions using node-lambda&nbsp...

716 views 0 4
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot