I had thought about this problem before when I was using SVN, but I didn’t understand it at the time and I didn’t encounter any bugs.
Now that I am learning Git, I have the same question, so I raised it.
Question:
When merging branches, if there are no conflicts, will the code automatically merged by Git have bugs?
Because the conflicts detected by Git during merging are all editing conflicts, such as whether the two edits are on the same line, and whether the two edits have opposite operations (one adds and one deletes the same code), obviously, Git It does not and cannot care about the logic of the code itself.
So I think you should check the correctness of the code after merging, which is equivalent to verifying after each merge whether the problems solved by the two branches are in an unresolved state after the merge, and whether new bugs have been generated. , then the workload will be too much, right?
I wonder if you would check this in actual use?
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
If you have Baidu, you should see similar information: Although your development is on branch, in order to ensure that it does not deviate too far from the trunk, you need to merge it from trunk to branch frequently.
If a team follows the process, there won’t be much of a problem.
If multiple people edit the same code, Git will report a merge conflict, which needs to be resolved manually. Git has no way of knowing how to handle these codes, which is unavoidable. In actual multi-person collaboration projects, everyone usually develops in modules and tries to avoid changing the same files; update the common modules before changing them.
If no conflicts are reported after the merge, it means that the same code has not been changed much, and there is no need to check the correctness of the merge. As for the merged code that introduces logical bugs, it needs to be reviewed.
Of course you can. A function needs to use three methods a b c. Three people should change those three methods (assuming that none of the three people know that others have changed it); in this case, git will not consider it a conflict; But can you still ensure that this function is still what the three of them want?
No, because there are two situations in git merge. First: in a file, the same piece of code has been modified by two people at the same time, and git merge will report a conflict. Manual merging is required. Second: If two people change different code segments of the same file. git will merge automatically. Whether or not there are bugs is entirely the problem of the person who wrote the code. There are bugs, and there will naturally be bugs after the merger. There are no bugs, and there will be no bugs after the merge. Don't blame others!
Git was shot while I was lying down. I burst into tears and said: I am only responsible for code merging. Bugs are written by people. I will not bear the blame. . . . . .
Nothing is absolute. If there is no conflict and a bug can be merged, it can only be said that you have won the prize
This is not called a bug, it is called a
conflict. Conflict resolution:Use someone else’s version
Use your own version
Manual merge.
A very common way to avoid conflicts is: before modification, first
pullthe local branch to reduce the chance of conflictsWell, git is just a version management tool. If you merge the code and a bug occurs, it is a problem with your project team's own code. It is not git's fault at all. Your problem should be solved by writing test code.
It is possible, it is equivalent to winning a lottery