J'avais déjà pensé à ce problème lorsque j'utilisais SVN, mais je ne l'ai pas compris à l'époque et je n'ai jamais rencontré de bug.
Maintenant que j'apprends Git, j'ai la même question, alors je l'ai posée.
Question :
Lors de la fusion de branches, s'il n'y a pas de conflits, le code automatiquement fusionné par Git aura-t-il des bugs ?
Parce que les conflits détectés par Git lors de la fusion sont tous des conflits d'édition, comme si les deux modifications sont sur la même ligne, et si les deux modifications ont des opérations opposées (on ajoute et on supprime le même code), évidemment, Git ne le fait pas Vous ne pouvez pas non plus vous soucier de la logique du code lui-même.
Je pense donc que vous devriez vérifier l'exactitude du code après la fusion, ce qui équivaut à vérifier après chaque fusion si les problèmes résolus par les deux branches sont dans un état non résolu après la fusion, et si de nouveaux bugs ont été générés. ça ne demande pas beaucoup de travail ?
Je me demande si vous voudriez vérifier cela en utilisation réelle ?
Si vous avez Baidu, vous devriez voir des informations similaires : bien que votre développement soit sur une branche, afin de vous assurer qu'il ne s'écarte pas trop du tronc, vous devez le fusionner fréquemment de tronc en branche.
Si une équipe suit le processus, il n’y aura pas beaucoup de problème.
Si plusieurs personnes modifient le même code, Git signalera un conflit de fusion, qui doit être résolu manuellement. Git n'a aucun moyen de savoir comment gérer ces codes, ce qui est inévitable. Dans les projets de collaboration multi-personnes réels, tout le monde développe généralement par modules et essaie d'éviter de modifier les mêmes fichiers ; mettez à jour les modules communs avant de les modifier.
Si aucun conflit n'est signalé après la fusion, cela signifie que le même code n'a pas beaucoup changé et qu'il n'est pas nécessaire de vérifier l'exactitude de la fusion. Quant au code fusionné qui introduit des bugs logiques, il est à revoir.
Bien sûr que vous pouvez. Une fonction doit utiliser trois méthodes a b c. Trois personnes doivent modifier ces trois méthodes (en supposant qu'aucune des trois personnes ne sache que d'autres l'ont modifiée dans ce cas, git ne considérera pas cela comme un conflit) ; ; Mais pouvez-vous toujours garantir que cette fonction est toujours ce qu'ils veulent tous les trois ?
Non, car il y a deux situations dans git merge. Premièrement : dans un fichier, le même morceau de code a été modifié par deux personnes en même temps, et git merge signalera un conflit. Une fusion manuelle est requise. Deuxièmement : si deux personnes modifient des segments de code différents du même fichier. git fusionnera automatiquement. Qu'il y ait ou non des bugs est entièrement le problème de la personne qui a écrit le code. Il y a des bugs, et il y aura naturellement des bugs après la fusion. Il n'y a pas de bugs, et il n'y aura pas de bugs après la fusion. Ne blâmez pas les autres !
Git a été abattu alors que j'étais allongé. J'ai fondu en larmes et j'ai dit : je suis uniquement responsable de la fusion de code. Les bugs sont écrits par des gens, je n'en porterai pas la responsabilité. . . . . .
Rien n'est absolu. S'il n'y a pas de conflit et qu'un bug peut être fusionné, on peut seulement dire que vous avez gagné le prix
.Cela ne s'appelle pas un bug, cela s'appelle
冲突
. Résolution des conflits :Utiliser la version de quelqu'un d'autre
Utilisez votre propre version
Fusion manuelle.
Une manière très courante d'éviter les conflits est la suivante : avant la modification, commencez par
pull
brancher localement pour réduire les risques de conflitsEh bien, git n'est qu'un outil de gestion de versions. Si vous fusionnez le code et qu'un bug se produit, c'est un problème avec le propre code de votre équipe de projet. Ce n'est pas du tout la faute de git. Votre problème devrait être résolu en écrivant du code de test.
C'est possible, cela équivaut à gagner à la loterie