We have a scenario where we'd like to use two branches in our git workflow, otherwise known as
The current flow is as follows:
feat-branch- this branch will be based off of
- Make your changes in
feat-branch, then finally commit your changes, and push them upstream to the remote
- Finally, the goal is you will eventually make two Pull Requests (via GitHub). One will be:
develop <- feat branchand the other will be
master <- feat branch
This methodology works perfectly fine for merging things into the master branch since the feature branch is already branching off of the master branch (aside from having to
git pull origin master every now and then when you are out of date - but this is expected (I personally like to rebase my feature branches as well)).
However, the idea is you will be making a Pull Request to
develop first (before you even make a secondary Pull Request to merge to
Merging to the
develop branch becomes dicey at this point because each contributor is effectively making the same exact PR to both develop and master, which is creating different merge commit hashes in each respective branch with the same changes.
However, since everyone is branching off of master, this means those merge commits that end up in master eventually get merged back into the develop branch over time... this causes PRs to have erroneous differences being displayed which essentially say the same changes are being made by another person.
I'm guessing this is a mix of how commit hashes work in conjunction with the fact that every merge commit that is created after a Pull Request is merged into master ends up being included in a PR to the develop branch.
At this point I'm kind of just looking for maybe some sort of general direction or ideas regarding resolution, whether it be an entirely different way to approach the 2 branch model or something different altogether.