What are the dangers of accepting a merge from a branch with commits behind?

Question

What are the dangers of accepting a merge from a branch with commits behind?

Navigation

#1 by (2 votes)
#2 by (0 votes)

5

Sometimes when I make a merge request in a project, it appears that there are commits behind , I understand that this happens due to the fact that at the time of creating my branch , based on the branch where I will create the merge request then, there were some commits that were created later and I did not update my < strong> branch .

What I tried to exemplify is the following scenario:

My question is, what are the dangers of accepting the merge of my branch even if there is commits behind ?

Sometimes these 'commits behind' are in files other than the ones I've changed, so much so that it does not conflict when creating the merge request.

If I merge, even if the commit behind tags do not affect the code I've moved, I run the risk of rewriting the commit behind tags >?

git

asked by anonymous 16.10.2018 / 20:55

2 answers

How to insert records through cursor? Doubt with relationship One to Many

score 2 · Answer 1

It's a good practice to pull the parent branch from which you want to open the merge request. In this case, "Master". Home In theory you have no problem opening a merge request if there is no conflict, but if you have, git will not merge automatically and you will need to do the manual merge by resolving the conflicts. Home However, one problem that may occur is that your code may not work right with the additions made in Master, and then you will only know after the merge. If the merge occurs automatically, it will be more difficult to detect the problem. Home Therefore, it is always recommended that you pull and test the changes before requesting the merge. So you ensure that your addition to the code will not break anything, and nothing in the code that is in Master will break what you did.

score 0 · Answer 2

My question is, what are the dangers of accepting the merge of my branch even if there are commits behind?

The only problem would be the conflict between code and you need to correct it manually, testing at the end is necessary.

In practice you should have the branch develop and in it you will merge all other branches and only then merge the master (because here is the end result of the cycle and can not have errors or conflicts)