0

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?

bunny
  • 1,797
  • 8
  • 29
  • 58
  • Well for me, every branch other than master should be deleted, once it is merged in master. Keep sync your local master to the remote one, whenever you need to implement a feature name it like dev_{featureName}, do your work, create pull request and after successful merge delete the branch. – Bilal Jan 06 '19 at 07:53
  • 1
    What is your branching strategy, is `dev` a long-lived branch? – joran Jan 06 '19 at 08:44
  • Yes, dev is a long-lived branch. – bunny Jan 06 '19 at 23:47

3 Answers3

4

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.

A.H.
  • 63,967
  • 15
  • 92
  • 126
1

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.

Andreas
  • 6,447
  • 2
  • 34
  • 46
0

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

Limor Stotland
  • 88
  • 4
  • I think he would lose the changes (at least from an individual commit perspective) because of the "squashing merge" that he's doing. :-( – John Szakmeister Jan 06 '19 at 10:22