What is preferable approach to merge changes from develop into master branch?

Question

Master is main branch and is locked from direct merge request.

Develop is branched off master.

Feature1 is branched off Develop branch.

I can pull the code from Feature1 branch to my local GIT and make changes, and commit the code locally.

Now I have two options to integrate changes to develop branch:

1. To bring the code changes from feature1 into develop we can either do merge squash or rebase feature1 into develop locally and then push develop to the server. Merge squash doesn't retain previous feature commit histories. Where as rebase will keep the history.

2. The other way, instead of merging code locally from feature1 into develop, we can push the feature 1 branch to the server and then raise a pull request on the server to merge the code from feature1 branch to develop branch. Here will the commit history from feature1 get stored or ignored when merging to develop branch?

Which is preferable approach?

Answer 1

If you are not the only one working on feature1 , a PR to merge it to develop is preferable.
A rebase would involve a force push, making your colleague having to reset their own feature1 branch.

To keep the history of feature1 , consider a regular merge when accepting the PR, not a " squash and merge ".

For develop to master , you are not the only one integrating features, so a PR is recommended, to merge (not rebase) develop .

Answer 2

Your answer depends on how quickly things are merged into master branch. I am not a huge fan of feature branches because they can be difficult to merge into master if multiple teams are editing the same files for different feature branches.

The way we do branches in my company is we have: production - the current version running in production master - the release candidate is cut from this branch. It's experimental, but we should only merge "working" code. We should never knowingly break master .

And that's it. Our pull requests are against master . People can use feature branches, but you're responsible for the merge conflicts. Each pull request into master requires a JIRA ticket for compliance.

Answer 3

I prefer the first option so everything is conflicted which will be resolved locally and then will push to master.