0

GitFlow: Better PullRequest-Integration (e.g. Bitbucket)

Wolfgang S. 4 years ago updated 4 years ago 1

We would like to have a better integration of Pull Requests for feature-, hotfix- and support-branches.

In our environment these branches could be merged with Pull Request only (push branch and create a pull request).

So e.g. FINISH a feature-branch should not merge it onto local develop branch.

What we would like to have, is some sort of combined process of GitFlow and Pull Requests (e.g. Bitbucket).

But let me first show you our current Development/Release-Process:

We are about 15 developers. Each of them ...

  1. creates a local feature-Branch (either from develop or releasePrepared) for coding and testing,
  2. then PUSH it to Atlassian Bitbucket,
  3. then creates a Pull Request,
  4. another person reviews and merges (on Bitbucket) the feature-branch into the develop-branch (or releasePrepared),
  5. and finally - after beeing merged - deletes the remote feature-branch (see attached picture, but sorry its in german).

While using this workflow process we can take only partial advantage of the implemented GitFlow-Support in SmartGit with "Start Feature", but could not use "Finish Feature" - and have to delete the remaining local feature-branch manually (same for "Start Release").

Maybe an optional (by configuration) GitFlow-Button like "Create Pull Request" which would create a PR on Bitbucket and switch to develop-branch, then delete the obsolete feature-branch. Currently the available "Create Pull Request"-Feature is accessible on the context menu of a branch only in the LOG-Window, and as default for the target branch, is not proposed the base branch, but /develop (but Gitflow config is: PROD/develop)

The workflow process above we have in two shapes one with prefix PROD/ (code which should go into production) and one with ENTW/ (code which should not go into production until the next major release in about a quarter). Thus we are switchinig the GitFlow configuration with a script (to have the appropriate git-environment and the right database during development).


It seems for me that in .git/config at least some of these manually deleted branches were not deleted (in [gitflow]-section).

Maybe we are using a suboptimal workflow process, - if you'll have any better variant we'll appreciate it.

Possibly our workflow is so peculiar that it's not worth to think about SmartGit-Support?


kind regards

Wolfgang