2

I have 3 Branches. 1) master 2) dev :- current developement 3) release :- at a time we stop developing from dev branch, create this branch and only do regression bugs in this branch. In the mean time dev branch will be worked for all future development.

Now we merge the release branch to master. And then try to merge master to dev.

When merging master to dev, this is what i m doing. 1) git checkout master 2) git pull 3) git checkout dev 4) create new branch from dev and call it merge-master-to-dev 5) git checkout merge-master-to-dev 6) git merge master

when i do this, I see no conflicts. so looks like all the files/commits are merged property from master to merge-master-to-dev. But when i look at some files in the code, i can see that one or more commits are missing. Never has seen this happening before so any idea what i am doing wrong?

Vivek Patel
  • 349
  • 2
  • 4
  • 21
  • If two versions of a given file are merged, it can happen that content will "disappear" in Git. But, I usually have seen this happen when there are bad workflows, e.g. both branches modified the same methods in different ways. – Tim Biegeleisen Oct 04 '18 at 04:25
  • the changes in dev branch file is a completely new method. but the changes that are coming from master for that file, is updating existing method. so really confusing. – Vivek Patel Oct 04 '18 at 04:30
  • I'm a bit confused by the structure of your branches. Are 'dev' and 'release' both branched off of master? – Greg H Oct 04 '18 at 04:33
  • master is like master. We never make changes to that branch as like feature. dev started as off master, then we do developement there like features and bug fixes. then we make a release branch off dev so we can do testing for our releases. Then we fix regression bugs in the release branch and cont working in dev branch for all other future features. Then we will merge release to master, and then merge master back to dev. That way all our reg. bug fixes done in release branch comes over to dev. – Vivek Patel Oct 04 '18 at 04:36
  • OK I'm not sure what you mean by that, but I would recommend reading https://nvie.com/posts/a-successful-git-branching-model/. Is your branching structure similar? – Greg H Oct 04 '18 at 04:38
  • @GregH i updated my answer. I even tried merging that release branch directly back to dev but its doing the same. its overwriting my commits/files on dev branch. And yes our branching is similar to what is in that link – Vivek Patel Oct 04 '18 at 04:42
  • OK, any reason you don't merge release down into dev? – Greg H Oct 04 '18 at 06:09
  • you need to git push after the merge – Dimitris Oct 04 '18 at 07:26
  • @GregH i tried merging release to dev as well. Same result. – Vivek Patel Oct 04 '18 at 15:29
  • @Dimitris i know that i have to push, but when i see the branch locally, i can see that it does not have changes from both branches. Rather release branch completely overwrites dev branch for all the files on that commit in dev – Vivek Patel Oct 04 '18 at 15:30
  • @VivekPatel I just suggested it since you had so thoroughly described the rest of the git steps that you took. I think it would be a good idea, to post a picture of your git network, I think if you visualise it, it will be much easier to identify the problem. – Dimitris Oct 08 '18 at 10:57
  • @Dimitris turns out a commit B was made in the dev branch but when we moved to Release, the same commit B was rolled back, and when we merge Release back to DEV, for whatever reason, that commit A was gone during the merge process. I think we narrowed that down. Thanks for all your help. – Vivek Patel Oct 09 '18 at 15:35

1 Answers1

0

turns out a commit B was made in the dev branch but:

  • when we moved to Release, the same commit B was rolled back, and
  • when we merge Release back to DEV, for whatever reason, that commit A was gone during the merge process

"for whatever reason" being a merge doing its job to report modification of the source branch (here a commit rollback in Release) to the destination branch (dev)

To avoid those merges, you could consider an alternative workflow: the gitworkflow (one word), where the dev branch is simply recreated after a release, and feature branches are merged in.

Key part:

The "public" and "next" (aka 'devel') branches are never merged to master. They are "transient" or "ephemeral", always deleted/recreated.
Only feature branches are merged to the lifecycle branches (public, next, master). That means at any time you can chose to drop a feature between one stage of the development lifecycle and the next.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250