0

the team I work with doesn't accept the fact that the master branch should be merged into develop in order to align develop with master's hot-fixes/bug-fixes.

They are scared that somehow when they merge master (our stable production branch) into develop (the branch with all the feature-branch branches merged into which are not yet deployed into production), ahead work made on develop which is yet to test could be lost.

And this happened several times (not with me though) that someone of our team told us "I merged master into develop and it overridden the ahead changes made on develop by X (another developer)".

So, I guess that maybe someone is using git not in the right way, as I didn't experience this problem when I merge master into develop, somehow bringing develop to an old version without the new stuff being tested which was there before the merge.

Any thoughts and ideas on why this could happen? What do you think could be the problem we are sometimes facing when we merge master into develop?

I know that master should be merged back into develop as soon as there's a hot-fix/bug-fix, otherwise develop won't have this fix. My colleagues keep arguing that this could lead to the above mentioned problem. Who is right?

But, logically, if you merge master into develop, it's the same as merging master into your feature-branch-1 and then merge this branch feature-branch-1 into develop (you are just bringing the changes made on master to develop through a third branch, in this case feature-branch-1). What do you think?

Thanks for the attention!

EDIT: I am still investigating, please, even if I accept an answer, tell me what do you think, I would like to acquire as much opinions as possible regarding this fact.

tonix
  • 5,862
  • 10
  • 61
  • 119
  • Actually, in `git flow`, you don't merge `master` back into `develop`. Hotfixes on master are usually `cherry-pick`ed back into develop. Not that a merge should cause the problems you described, but you usually don't want to pollute your `develop` branch with all those `merge develop into master`-commits... – kowsky Apr 11 '18 at 10:56
  • I didn't understand your last part `Not that a merge should cause the problems you described, but you usually don't want to pollute your develop branch with all those merge develop into master-commits...`, could you make an example? – tonix Apr 11 '18 at 11:01
  • @kowsky gitflow, [as it is described](http://nvie.com/posts/a-successful-git-branching-model/#hotfix-branches), prescribes merging of hotfixes. Anyway, if you have cherry-picked anything between branches, you should avoid merging them, otherwise you get conflicts in place of the picked code. – max630 Apr 11 '18 at 11:04
  • Oh, you're right @max630. I wasn't aware of that, as a merge from `master` back to `develop` seemed somewhat unnatural. Cherry picking hotfixes into develop, however, never caused conflicts in future merges from `develop` to `master`. @tonix: What I meant was that it should be possible to merge from `master` to `develop` without problems, we just prefer cherry-picking because of aesthetic reasons so that we will never have `merge branch develop into master` commits in the history of our develop branch. – kowsky Apr 11 '18 at 11:13
  • OK, so if you say `we just prefer cherry-picking because of aesthetic reasons so that we will never have` it means that merging from `master` to `develop` (writing the hotfix on master insteac of a `hotfix-branch-*`) is effectively the same as forking a new `hotfix-branch-*` from `master`, do the hotfix there and then merge into `develop` , right? – tonix Apr 11 '18 at 11:52

1 Answers1

2

As there is real case to investigate, you can re-create every merge situation. Check out the parent commit from develop, merge the parent commit from master. Then see if you have same result as is in the history.

--A--C (develop)
    /
--B+ (master)

For the history above the commands would be:

$ git checkout -B test_merge A
$ git merge -m "testing merge C" B
$ git diff C

Note that even if merge ended up with conflict, you should be able to run diff straight away, to evaluate the conflict resolution, or try to resolve it yourself first and then compare with recorded version.

My assumption that people who complain about that may be using some -X(ours|theirs) flags, or GUI conflict resolver which encourage "pick a side" in one click. This is incorrect thing to do then there are independent changes on both sides (and if you do it properly you should have only independent changes).

Also incorrect resolution can be remembered by rerere, watch out for line like "Resolved '***' using previous resolution"

But, logically, if you merge master into develop, it's the same as merging master into your feature-branch-1 and then merge this branch feature-branch-1 into develop (you are just bringing the changes made on master to develop through a third branch, in this case feature-branch-1). What do you think?

I agree. There is no difference. This is all a particular case of cascading workflow (there is opinionated description by the link, but it has a nice picture)

max630
  • 7,348
  • 2
  • 24
  • 49
  • Thank you! Could you please clarify how can I check the history to see what did wrong with which merge? What are the commands I have to do and what should I see when I find a change which is overridden by an older one on `develop`? – tonix Apr 11 '18 at 12:14
  • added to answer – max630 Apr 11 '18 at 12:38
  • When I do it, I see some deleted files: `Changes not staged for commit: ...` `deleted: some/file.php` `deleted: some/otherfilefile.php ...` What does it mean then? Those files were still deleted on commit `A` – tonix Apr 11 '18 at 18:43
  • I think you should ask it as another question, with thorough details: what is in `A`, what is in `B`, what is in their merge base, what you see when you merge, does it differ from `C`, are there any other changes between the commits which could affect it by lousy rename detection. – max630 Apr 11 '18 at 21:25
  • You are right, I guess I have to investigate further, I will ask my colleague further information too! And keep posting any update. – tonix Apr 12 '18 at 22:58