CODEWITHSUNDEEP
gitgit-merge
bunny
bunny

Reputation: 2037

best git practice with dev and master in remote

Remotely, I have two branches: dev and master.

I implemented 3 features(Feature A, B, C) and have local branch for each them. Then I merge these 3 features into dev branch one by one. Some day, I want to release the my changes, so I merge dev to master using squash merge. Now the remote master has Feature A, B and C.

Then, I implemented a Feature D and merge from local Feature D branch to dev. I merge the dev to master by sending a pull request. However, I found that the commits of Feature A, B, C are also showing in this pull request. It is very confusing, but I found the answer here to explain it: Github "Squash and Merge" - subsequent pull request showing all previous changes Which mentions the best practice is to delete a branch after it is merged. However, I cannot delete the dev branch. I would like to know what is the best practice in my case has two remote branch? Is it reasonable for me to merge dev with Feature D into master by ignoring the duplicate commits in pull request?

Upvotes: 0

Views: 612

Answers (3)

Andreas
Andreas

Reputation: 6475

Squash merge is not a good strategy between two long-lived branches that need to be kept in sync. Best option would be to merge master into dev, fix the merge conflicts and the merge dev into master

git checkout dev
git merge master
# Fix merge conflicts and commit, probably nothing appears as changed
git checkout master
git merge dev --no-ff # or use git merge dev --ff if you don't want a separate merge commit

Then your long-lived branches should be in sync again. Doing it the other way around is probably not so good since that would add a lot of commits under master.

Upvotes: 1

A.H.
A.H.

Reputation: 66263

You have feature-branches, a dev branch and a master branch. So it seems your workflow is quite like Git-Flow -- A successful Git branching model -- apart from the dev vs develop mismatch and no release branches.

Gitflow and similar branching models transport changes between develop and master with real merges -- not with squash merges in as in your case. Git sees a squash merge just as a new commit -- it does not track the information that you combined two lines of work (master and develop). A real merge does exactly this tracking. If you use a real merge then git can deduce that A, B and C have already been merged and leave them out in the pull request for D.

Upvotes: 4

Limor Stotland
Limor Stotland

Reputation: 88

why can't you delete the dev branch? because you afraid of losing the changes you did? if so you can use git reset --soft shelve them, delete dev and create a new one and then unshelve them. if this is not the case maybe trying to rebase the dev with master using the -i flag

Upvotes: 0

Related Questions