Popular posts

Ok, but I fail to see why the dev/stable branch wouldn't be deploy-able though? why can't the merge confilcts/bugs all be done by doing the merge locally and test locally before pushing to the main branch?

I'm really struggling to see a benefit. Apologies to all if I seem daft, it's just not clicked yet.

Hipkiss Assume you merged your feature branch with dev and got some merge conflicts to fix. Meanwhile, you encountered a bug in production that has to be fixed and deployed immediately. How would you do that? You have to first fix the existing merge conflicts in dev branch in order to deploy to fix. So, essentially emergency fixes can't go live because the dev branch is now unstable (even if it's local).

Does this help? Feel free to ask more questions.

Sandeep Panda In response to that situation I would either:

1 - stash the WIP feature/dev branch merge and address the issue in the origin branch and push, applying that change to merge as well (if poss).

2 - Ask another member of the team to fix the issue and push.

My thought process:

1 - The merge and conflicts are being handled locally.

2 - Because the conflicts are being handled locally it means other developers within the team can still alter the origin if req, such as would be the case in your example.

3 - If I were the only one working on the project and in your example situation, I would stash the merge changes, make my alterations to the origin dev branch and then go back to continuing with the merge conflicts.

4 - Regardless of either method used, you would still need to complete the merge conflict (either before or after the bug fix) and then merge the dev branch, that now has new changes/the bug fix, with the resolved dev/feature merge from the first instance. Therefore I am suggesting that pulling the dev/stable branch into the feature branch and then back to the dev branch adds an additional redundant step.

I hope that clears up my train of thought!