git-flow feature finish and pull request

[Patrick Baker]

Typically my workflow goes like this:

1. git flow feature start NewWidget
2. .. commits ..
3. git flow feature finish -r -S
4. git push origin

This allows for:

• Multiple commits to be squashed into a single commit before merging the feature into develop.
• Keep history linear
• Rebase before merging

I would like to leverage pull requests in this model, however there are a few problems. Source tree doesnt appear to be able to resolve these either.

1. If a pull request is merged one cant feature finish
2. Manually have to squash commits before pull request
3. Rebase on merge

Does anyone use git-flow with pull requests using Stash? If so, how does your workflow work?

[Rick]

sad to hear this isn't possible.. even after the issue was adressed 5 years ago

[Kim Taylor]

Me too.. Can you successfully use pull requests with git-flow?

This old thread is the only one I've uncovered regarding use of git flow specifically with Stash / Bitbucket server.

I've installed the git flow AVH tools and they make perfect sense while working off in my own clone. But, then how do I engage the rest of the team at the right time?

Example: git flow hotfix finish merges locally into develop (and master) and now I can't push to the central / hosted repo where the develop (and master) branch is protected by required pull requests.

By that point, my local hotfix branch has been merged and deleted so there's no available central branch from which to create a pull request into develop (or master).

It feels like I might have to break my train of thought and instead of using git flow tools from the command line, emulate them by performing the equivalent branching commands in Bitbucket. I hope not?

[Philip Colmer]

It is a problem :). I love the git-flow model but it really doesn't play nicely with pull requests.

The approach we've taken is to use git-flow to create the feature branch but then, when the work is done, commit that branch back to BitBucket and issue a pull request to merge that into the develop branch. This requires the developer to tidy up their own system (by deleting the feature branch once the PR has been approved and marged) but it works.

We're only a small team and we don't really do releases as such so our approach may not scale.

[Filip Stas]

Yes we follow the same and similar way of working as well. We don't finish features, but create PR  and then clean up the local workspaces manually

[Seth]

I'm curious if any other solutions were found for this issue? Can you successfully use pull requests with git-flow?

[Manoj Shetty]

Hi,

One workflow for this problem can be:

1) Master branch is the production ready branch. Only the Team leader has permissions to write or merge on Master branch.

2) Before starting the next Iteration for the Sprint release, you can create a new Release branch 2.0 on the Remote Repo

3) Every developer will checkout from Release 2.0 branch before coding. Then create a new Feature branch based on Release branch.

4) Developer will do coding and commit on Local Repo - Feature branch

5) Developer will push the Local Repo Feature branch to Remote repo Feature branch

6) by this time, Bamboo build will trigger for the Remote - Feature branch - if Build pass then Pull request can be created

7) If build pass, Developer creates the Pull request and assign to Team leader for code review

8) Team leader will do the code review and merge Feature branch to Release branch - later the Bamboo build will trigger on Release branch

9) later the Feature branch will be deleted

10) after all Features are developed and merged, finally when the Release branch is stable and build is also pass.

11) QA team will do all testing on Release branch

12) if all pass on Release branch, Team leader will merge from Release branch to Master branch.

regards

[Manoj Shetty]

Hi,

One workflow for this problem can be:

1) Master branch is the production ready branch. Only the Team leader has permissions to write or merge on Master branch.

2) Before starting the next Iteration for the Sprint release, you can create a new Release branch 2.0 on the Remote Repo

3) Every developer will checkout from Release 2.0 branch before coding. Then create a new Feature branch based on Release branch.

4) Developer will do coding and commit on Local Repo - Feature branch

5) Developer will push the Local Repo Feature branch to Remote repo Feature branch

6) by this time, Bamboo build will trigger for the Remote - Feature branch - if Build pass then Pull request can be created

7) If build pass, Developer creates the Pull request and assign to Team leader for code review

8) Team leader will do the code review and merge Feature branch to Release branch - later the Bamboo build will trigger on Release branch

9) later the Feature branch will be deleted

10) after all Features are developed and merged, finally when the Release branch is stable and build is also pass.

11) QA team will do all testing on Release branch

12) if all pass on Release branch, Team leader will merge from Release branch to Master branch.

regards